Tuesday, January 06. 2009SQL Coding Standards To Each His Own Part IIPrinter FriendlyTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
In regards to the table.id argument, why not consider semantics? table.id is semantic. table.table_id is just plain redundant and insulting to coding intelligence.
Why do the extra work for no explicit benefit? Note how you guys state, "Field names should be prefixed with their tables." You might as well go on to say, "... and id columns should also be prefixed with their tables." Read that back to yourselves and let your mind wobble. Thanks for helping to push non beneficial "standards" to make my day-to-day tasks more of a pain in the ass.
Alan,
First of all these are just opinions and part of the point of this article is that standards are not quite as cut and dry as some people think. Josh I'm sure feels strongly about his style just as much as we feel strongly about our style. The 2 problems I see with id is 1) You always have to alias it in the SELECT because who wants to see id in a multi join output when you can't see the tables that are being joined. In many cases we need to output the primary key for example if the query is a view to be joined later with other things and if you are going to have to alias to a meaningful name, you might as well do it in the table. 2) Its just distracting to see all fields named the same unless they mean the same thing (yah we can argue an id is an id, but an id is not always an integer so why should it always have the same name and that's a whole other argument as to whether we should always use surrogate keys). first_name is a first_name and always means the same thing okay I get it. When you are using short aliasing of tables its especially annoying. PO.id is just not quite as useful to see as PO.post_id. In Josh' model its not quite as bad since he always spells out the table name. So I guess in Josh's model it works if you never need to output the primary key in the query.
Hi. Just a small nitpick.
Not once did you mention the word "column", but used the word "field" 8 times. Columns are not fields. Here is a great explanation: http://www.developersdex.com/gurus/articles/118.asp Regards.
RDL,
I'll have to think about this a bit more. You are probably right. Rereading Celko's paper I could read it a couple of ways. The way I have always understood it, a column defines the whole set of data of a specific slot (column) in a table. A field defines a specific element of data that lives in a specific row in a specific column. So when I think of writing SQL statements -- I think of them as fields, because I am not selecting the whole column 0 table (I am only selecting a set of fields that live in a column). But yes I am selecting from columns so perhaps I should call it columns. So when I am defining a table structure I think columns. When I am selecting data, I think fields. The other reason I just assume not bother talking about columns is we do a lot of financial consulting and when you start talking columns - the first crazy thought that pops into finance peoples minds is (Ah so a database is a spreadsheet - we have columns too). I just assume not get into that mindset of thinking of databases as spreadsheets even though they both have columns and I have partaken in the guilty pleasure of simulating spreadsheet behavior in databases :)
Really, Very nice Information for the SQL Programmers and very important features should take care always.
Ajaykumar Sinha SQl Expert India |
Entry's LinksQuicksearchCalendar
Categories
Blog Administration |