[Rails] Re: Stack overflow problem

[Eric Anderson]

Steven Critchfield wrote:
> I think it is a bad idea to have a column be the same name as the table.
> So trying to fix the code may not be the best choice. 

Hmm.. I feel the exact opposite. It seems perfectly natural to have a 
field named after the object it is storing. If you are referencing an 
account object in the user object I would expect the field to be named 
account.

The only exception to this may be in the case where you have something 
like an employee who has a boss. The boss is also an employee, but you 
may name the field "boss" to make the type of relationship more apparent.

I find the whole "<field_name>_id" to be a bit annoying. The idea is to 
encode information about what type of data it is storing in the name 
itself. But it is obvious you are storing a relationship when the type 
is an INT and there is another table in the database named "accounts". 
Plus you get into a case of where do you stop encoding information. I 
have seen some designs where they encode the table name in the field so 
it is apparent in joins. I have also seen designs where the referenced 
object type is encoded in the name. So if you keep this information 
encoding up you end up with variables named like 
"user_account_Account_id" or "employee_boss_Employee_id". Somehow people 
think this encoding of information is more legible than just "account". 
This is the same argument I have against the Hungarian notation that is 
so popular on Microsoft platforms. Why have "lpszFile" instead of just 
"file"?

Obviously all this is style and preference and nobody is really "right". 
But the documentation clearly implies that the :foreign_key option will 
allow you to use any field name you want. To be consistent it should 
allow using the attribute name as the foreign key name.

> On a constructive note though, as I also am dealing with trying to use
> the same database and data for more than one project at a time and it
> was designed without rails in mind, I have been learning how to get
> around the problem.

I agree that good view support can also help with this situation. Of 
course this also means that your application is tied to one database 
platform. To me it seems that rails should support a default design out 
of the box, but through options allow someone to specify a slightly 
different design. Working with legacy databases is important and if we 
can support 90% of them through the use of simple options such as 
:foreign_key, table_prefix, table_suffix, and the like then it will make 
rails that much more successful.

Also the other problem I see with using views besides the loss of 
platform independence is that you now have more maintenance costs. Every 
time you want to change the database you might need to also update the 
views to account for this change.

As always TIMTOWTDI and the creation of views is a very option when the 
database design is just too different from the design rails expects.

Thanks for the suggestions,

Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://one.textdrive.com/pipermail/rails/attachments/20050108/dc69dd42/signature.bin