Is Rails a good place to start for a newb to the database world ??
I need to make a database that is searchable with multiple filters that
can be turned on and off at a moments notice kinda like java xhtml
dynamic loading…
I have not worked with php or mysql much more than basic scripts running
and website defaults. so I am new to the racket and want to pick
something that is robust and fast to implement and learn…
If so , what would be a good book to snag from the book store ??
Rails is a great place to start. First, I would advise that you make or
watch a tuto. Then, you make some experiments. Then, if you decide to go
with rails, you should consider buying the very affordable book agile
development with rails:
http://pragmaticprogrammer.com/titles/rails/index.html
Some excellent tutos and the webcasts are listed at
Regards,
Nicolas
Stephen B. wrote:
In terms of databases, Rails abstracts the database to a certain degree
but it also ‘encourages’ good data modeling. You’ll pick up a lot of
good database design practices as you learn Rails.
I don’t think so.
Rails encourages to use some common bad practices, which are wide-spread
in providing access to SQL-DBMS from OOP languages.
Good data modeling is a general off-Rails topic, go and read some
C.J.Date’s books 
I don’t think so.
Rails encourages to use some common bad practices, which are wide-spread
in providing access to SQL-DBMS from OOP languages.
Good data modeling is a general off-Rails topic, go and read some
C.J.Date’s books
Can you describe some of these bad practices?
Charlie B.
Programmer
Castle Branch Inc.
Well i think you could say that’s a matter of context and taste. Sure,
as a top-boy DBM you’d probably cry at some of the things that are done
in Rails apps. I have a background in quite rigid database design and
when i started Rails i did sometimes think ‘yeah but shouldn’t i be
doing this or that?’ At the end of the day, most of it didn’t matter in
the context of pretty much every web app i write.
Rails encourages sensible naming conventions, normalization and correct
relationship management - what more do you need in a web app? :0)
Steve
I think Rails is a great place to start with web development - it kicks
you off some great ‘best practices’ that most of us take years to come
to :0) It’s also very easy to get started, but at the same time
powerful enough to keep up as your abilities and needs grow.
In terms of databases, Rails abstracts the database to a certain degree
but it also ‘encourages’ good data modeling. You’ll pick up a lot of
good database design practices as you learn Rails.
As for books, the ‘Agile’ book comes highly recommended:
http://www.pragmaticprogrammer.com/titles/rails/index.html. The 1st
edition is in the shops but if you can, i’d get the PDF version as it’s
more up-to-date. Plus, you’ll get updates for free :0)
Best thing to do is get the book, download rails and start playing -
you’ll suprised how easy it all is :0)
Steve
Charlie B. wrote:
I don’t think so.
Rails encourages to use some common bad practices, which are wide-spread
in providing access to SQL-DBMS from OOP languages.Can you describe some of these bad practices?
Ok, this is Rails way for DB conventions, to name a few:
)Sure, I can be totally dumb, but sticking from the newb start with such
a conventions can lead later to major headaches in more complex apps
than 15-minute blog
There are reasons when to follow these conventions would be good, but
there are also reasons when you just must avoid such practices.
The knowledge to choose the right solution (which may contradict
someone’s opinion ) is totally off Rails.
P.S. I can’t remember, if all design desicions made by DHH for
ActiveRecord have ever been summarized, though partially discussed
several times over the net.
Ok, this is Rails way for DB conventions, to name a few:
- autoinc ID column for tables
What’s wrong with this? I was using this way before I started using
rails?
- STI for model class inheritance (IMHO, table inheritance is, uhm, not
a good thing at all, and STI is damn ugly workaround for speed)
I have never used this once in the 30+ web apps I’ve created.
- no composite keys
Your are correct. This is truely needed if we are going to be able to
use rails with legacy databases!
- put all constraints(validations, foreign keys, triggers) in
application (ruby code in ActiveRecord descendants), and none in
I’m not convinced that triggers are a good thing when stored in the
database. It forces the programmer to remember what happens for certain
events. It also forces them into using another programming language. I
truly love having these “triggers” in the application.
Charlie B.
http://www.recentrambles.com
- STI for model class inheritance (IMHO, table inheritance is, uhm, not
a good thing at all, and STI is damn ugly workaround for speed)I have never used this once in the 30+ web apps I’ve created.
And it’s not as if DHH just pulled STI as the default out of thin air:
http://wrath.rubyonrails.org/pipermail/rails/2004-December/000839.html
Hmm… Well my focus is an upgrade from Filemaker… Since it has hit one
to many bottle necks for me in it’s weird design… Plus I like clean
code whenever I can get it…
I will watch some tutorials and see what comes of it… Thank you all 
Most of this is probably not as important as you think it is. Yeah,
constraints are in the application - but why is that a problem? If it
is a problem, you can always add those constraints in the db yourself
Anyway - this has all been hashed out before :0)
At the end of the day, there are a lot of developers out there who have
developed web applications for years and are happy with the conventions
set in Rails. Sure there are things to be improved on, but i personally
like the way things are and the way they’re going.
As such a shall continue to recommend Rails and it’s conventions :0)
Steve
When asked for a good place to start, try to focus on what the person
asking
knows: not much. My opinon is that rails ensures excellent practices,
especially auto inc and constraints in the code. You can start straight
away, and learn within a few hours because the setup of the environment
is
lighting fast.
When you become fluent, you improve, read, and start having your own
opinion. But I think it’s much better to strat with a solid framework
that
ensures at least some excellent (you would say honorable) practices,
than
with a .net framework that will leave you wondering what the hell is
going
on with you ado connection, why you cannot connect with firefox, and why
your data table tkaes 20 min to display.
Now, if you’re talking about engineering the backend server of citybank,
Rails practices are certainely aguables. But it’s not where one should
start
Charlie B. wrote:
Ok, this is Rails way for DB conventions, to name a few:
- autoinc ID column for tables
What’s wrong with this? I was using this way before I started using
rails?
It becomes very wrong if all your tables have such a primary key for
only reason – it is by Rails convention
- put all constraints(validations, foreign keys, triggers) in
application (ruby code in ActiveRecord descendants), and none inI’m not convinced that triggers are a good thing when stored in the
database. It forces the programmer to remember what happens for certain
events. It also forces them into using another programming language. I
truly love having these “triggers” in the application.
Hm, writing an app that talks to RDBMS w/o any knowledge of SQL and
procedural SQL extension for your production database server? Are you
kidding? Developers inevitably must know this “another language” well,
it is like requirement to be familiar with XHTML, CSS, JS, XML/XSLT etc.
in web development ( besides, e.g in Postgres you can write stored proc
and triggers in PL/Ruby ).
And after all I don’t see much logical difference between “CREATE
TRIGGER … AFTER UPDATE ON A …” and “class A < ActiveRecord::Base;
def after_save; … end ; end”
To make a summary: Rails conventions are best suited for Rails framework
and allow you to make common tasks in no time.
They aren’t really that bad, but blindly making them your habits is
unacceptable. That’s what I consider bad, so don’t recommend them as
good database practices
P.S. sorry for flooding
P.S. sorry for flooding
trip dragon wrote:
Is Rails a good place to start for a newb to the database world ??
I need to make a database that is searchable with multiple filters that
can be turned on and off at a moments notice kinda like java xhtml
dynamic loading…I have not worked with php or mysql much more than basic scripts running
and website defaults. so I am new to the racket and want to pick
something that is robust and fast to implement and learn…If so , what would be a good book to snag from the book store ??
Yes I think it’s an excellent place to start. Learning Rails was my
first foray into MySQL, but I’ve got my second app up and running using
the sometimes feared has_and_belongs_to_many associations (don’t worry
about knowing that yet).
I’d programmed before, but mostly in actionscript and javascript, and
hadn’t touched any lines of SQL. I think what makes Rails good for a
noob is that you can get something worthwhile up and running and then
examine it from the top down. For me anyway this worked out to be a
better learning method than starting with ‘hello world’ in other
languages I tried and got frustrated with slow progress.
Don’t get me wrong, sometimes I’ve wanted to bang my head against a wall
using rails too. Once I got off the scaffolds it wasn’t such a bright
picture. But slowly and more patiently I am learning enough that I feel
I can take on more with every app.
These people sure help, and so do the ones on IRC.
Jason
http://www.pfosphene.com
On 5/30/06, dseverin [email protected] wrote:
It becomes very wrong if all your tables have such a primary key for
only reason – it is by Rails convention
Every table should have a single, primary key that has no intelligible
context. It may not be “convention”, but it’s experience. 
When
you have to rearchitect a many million-line VFP application because
SSN was not allowed anymore (it was the primary key in many user
tables) you will understand. Save yourself time and your clients
money.
Just because the scientists and authors say it, doesn’t mean it is so…
procedural SQL extension for your production database server? Are you
kidding?
Everyone knows that a developer must know SQL to be decent at what they
do. That wasn’t what I was implying and it wasn’t what I said. I have
never used a trigger or stored procedure, and I have never seen a time
when it would have been beneficial for me either. Setting constraints
in your database is good at the individual field level. I think the
database should do only what it’s best at…retrieving and storing data.
Writing code the database to use seems a little weird to me. Maybe
that’s because I’ve always used MySql. It’s just my personal
preference. I see that you disagree with me on that. I think most of
the world is also divided on the issue.
Charlie B.
Programmer
Castle Branch Inc.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs