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.htmlI''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