[eluser]webthink[/eluser]
When I say aesthetics I'm not just talking about nice looking column names. I'm talking about names that are intuitive and describe the data actually being stored.
Consider the following example
A user's birth city. simply naming the column city_id while, it follows the convention, does nothing to describe the data actually being stored, The only thing it does describe is the table it references. Much more intuitive would be birth_city_id ... Add to this the further issue of the possibility of needing to add another foreign key for city of residence... residence_city_id would make sense and describe the data perfectly witout interfering with birth_city_id
Convention doesn't actually have to be abandoned it could simply be expanded.
instead of the current
table_id the convention could be
descriptor_table_id
In the example above birth_city_id fits nicely into that and has the advantage of telling me both the content of the field and the table to which it is a foreign key.
My returned object might then look something like:
first_name
last_name
birth_city_id
birth_city_name //comes from cities table
In my account manager example I would have account_manager_user_id
In my messages example I would have sender_user_id and recipient_user_id.
Of course in a lot of cases table_id is all that's necessary so any changes I make will allow that to remain.
Once I modify AR to handle these more descriptive foreign key names the only issue left will be to get it to do more than one join to the same table where appropriate such as in the messages example.
