Comments on: The power of a good SQL naming convention http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/ Stay curious! Thu, 09 Feb 2012 09:56:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Links 010 - Nagios, Cheat, Sheets, Incident, Handling, Kurzanleitung, Sheet, Commands - NETWAYS Blog http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/#comment-17362 Links 010 - Nagios, Cheat, Sheets, Incident, Handling, Kurzanleitung, Sheet, Commands - NETWAYS Blog Fri, 04 Dec 2009 13:04:13 +0000 http://www.xaprb.com/blog/?p=73#comment-17362 [...] The power of a good SQL naming convention [...] [...] The power of a good SQL naming convention [...]

]]> By: Joe Devon http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/#comment-15892 Joe Devon Sat, 21 Feb 2009 21:37:56 +0000 http://www.xaprb.com/blog/?p=73#comment-15892 I've used this naming convention with good success. In most cases it really makes things much clearer. But something that I'd clarify is the underscore vs. camelCase naming convention and make a rule for how to name the crossref table. Where it can get tricky is an example like this: Table1 = photo Table2 = photo_album Using Robert's idea, the cross ref would be either Table3 = photo_photo_album or Table3 = photo_album_photo ...pretty confusing... Personally I like Robert's method, but I'd only use underscores for xref tables and camelCase for multiple words...and try to stick to single word table names where possible. I’ve used this naming convention with good success. In most cases it really makes things much clearer.

But something that I’d clarify is the underscore vs. camelCase naming convention and make a rule for how to name the crossref table.

Where it can get tricky is an example like this:
Table1 = photo
Table2 = photo_album
Using Robert’s idea, the cross ref would be either
Table3 = photo_photo_album
or
Table3 = photo_album_photo
…pretty confusing…

Personally I like Robert’s method, but I’d only use underscores for xref tables and camelCase for multiple words…and try to stick to single word table names where possible.

]]> By: alan http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/#comment-15372 alan Mon, 10 Nov 2008 03:55:06 +0000 http://www.xaprb.com/blog/?p=73#comment-15372 Seriously, table.id leads to "a lot more code" ? Not only is it a lot less code, it actually makes sense (DRY with meaning). Likewise, FKs should be table.foreign_id . Also, keeping everything lowcase (e.g. table, sequence, pk) is good for maximizing ORM compatibility. Seriously, table.id leads to “a lot more code” ? Not only is it a lot less code, it actually makes sense (DRY with meaning). Likewise, FKs should be table.foreign_id . Also, keeping everything lowcase (e.g. table, sequence, pk) is good for maximizing ORM compatibility.

]]> By: esger http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/#comment-15363 esger Fri, 07 Nov 2008 14:18:00 +0000 http://www.xaprb.com/blog/?p=73#comment-15363 Spaces, underscores, camelCase, are all nice but you quickly run into problems if non native speakers have to use these. There is always the doubt where these delimiters have or don't have to go. Though the example of possible confusion leaving them out is valid, the chance of running in to it when naming tables is low more so since the names are not arbitrary but in context. naming pk and fk basically the same is interesting. (we use id as pk and tablenameid as fk) but it seems to me that it is the argument of the amount of code to be written that is driving your naming convention and that consistency is only your second concern. With the right tools, the amount of code should not be a concern and automated code generation systems should be insensitive to the naming scheme or absence thereof. Spaces, underscores, camelCase, are all nice but you quickly run into problems if non native speakers have to use these. There is always the doubt where these delimiters have or don’t have to go. Though the example of possible confusion leaving them out is valid, the chance of running in to it when naming tables is low more so since the names are not arbitrary but in context.

naming pk and fk basically the same is interesting. (we use id as pk and tablenameid as fk) but it seems to me that it is the argument of the amount of code to be written that is driving your naming convention and that consistency is only your second concern. With the right tools, the amount of code should not be a concern and automated code generation systems should be insensitive to the naming scheme or absence thereof.

]]> By: Artículos destacados de Octubre | cambrico.net http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/#comment-15359 Artículos destacados de Octubre | cambrico.net Fri, 07 Nov 2008 09:30:40 +0000 http://www.xaprb.com/blog/?p=73#comment-15359 [...] para realizar una buena convención de nombres para los objetos de una base de datos, en Xaprb (en [...] [...] para realizar una buena convención de nombres para los objetos de una base de datos, en Xaprb (en [...]

]]>