Rails - Feb 2006 - Basics - help with models &controllers...

I have looked at many rails apps source code from the web and it seems 
there is no  best practice when designing the database schema and 
models.

For example surely it is recommended to include your foreign keys and 
constraints at the database level? Some people just rely on the 
activerecord associations, and don''t bother even placing a field for
the
foreign key in the tables?

I fail to see how you can develop a proper application without having 
these items mapped to the database.

I have been trying to get my schema sorted now for a month and still 
don''t know what to do for the best. 
http://www.spectrais.com/images/0.png

For some unknown reason I can''t seem to do the following:

customer1 = Client.create(@params[:client])
then customer1.User.create(@params[:user])




-- 
Posted via http://www.ruby-forum.com/.

James Whittaker wrote:
> I have looked at many rails apps source code from the web and it seems 
> there is no  best practice when designing the database schema and 
> models.
I''m not sure that''s actually the case. Database best-practices
are
database best-practices. This, IMO, has nothing to do with Ruby, Rails 
or Rails model classes.
> For example surely it is recommended to include your foreign keys and 
> constraints at the database level? Some people just rely on the 
> activerecord associations, and don''t bother even placing a field
for the
> foreign key in the tables?
It''s not only recommended, it''s required. Whether you are
using a
database that enforces foreign key constraints or not, is another 
question. But without the foreign key columns in the necessary tables 
none of the Rails associations function, at all.
> I fail to see how you can develop a proper application without having 
> these items mapped to the database.
Heh... that''s because you can''t develop a "proper",
or even a
functioning application, that relies on relations between tables, 
without foreign key columns. You have no relations without those columns...
> I have been trying to get my schema sorted now for a month and still 
> don''t know what to do for the best. 
> http://www.spectrais.com/images/0.png
> 
> For some unknown reason I can''t seem to do the following:
> 
> customer1 = Client.create(@params[:client])
> then customer1.User.create(@params[:user])
Yes. That''s because your second line needs to read:

customer1.user.create(@params[:user])

You need to use the name of the association (ruby is case sensitive) to 
reference the related objects, not the name of the parent class of the 
related object. If you wanted to create a stand-alone User object, then 
you would use "User.create", just like you did with your stand-alone 
Client object in the first statement.

-Brian

DHH doesn''t believe in db constraints...
http://www.loudthinking.com/arc/000516.html

Not saying that I agree, but he has been pretty vocal about it and a lot of
people in the rails community follow his lead.

b


James Whittaker wrote:
> I have looked at many rails apps source code from the web and it seems 
> there is no  best practice when designing the database schema and 
> models.
> 
> For example surely it is recommended to include your foreign keys and 
> constraints at the database level? Some people just rely on the 
> activerecord associations, and don''t bother even placing a field
for the
> foreign key in the tables?
> 
> I fail to see how you can develop a proper application without having 
> these items mapped to the database.
> 
> I have been trying to get my schema sorted now for a month and still 
> don''t know what to do for the best. 
> http://www.spectrais.com/images/0.png
> 
> For some unknown reason I can''t seem to do the following:
> 
> customer1 = Client.create(@params[:client])
> then customer1.User.create(@params[:user])
> 
> 
> 
>

Ben Munat wrote:
> DHH doesn''t believe in db constraints... 
> http://www.loudthinking.com/arc/000516.html
I''m not sure that simple statement is a fair representation of his
position, but
I''m not going to try and speak for DHH. However, being against db
cleverness
doesn''t mean you don''t support the notion of your DMBS
managing the physical
relationships between your tables, with the application code managing the 
logical relationships.
> Not saying that I agree, but he has been pretty vocal about it and a lot 
> of people in the rails community follow his lead.
I''m not following his lead, I just happen to be on the same page as
him... I
want my database to manage (and store) my data. All other things having to do 
with my data will take place in my application code, not in some shoe-horned in 
procedural language that offers me little beyond making my DBMS chew more RAM. 
RAM might be cheap, but it''s far from infinite, and I''d much
rather devote that
RAM to my app code.

-Brian