I really liked the article.

In object oriented language context and supposing that you are going to map every table/entity to a class, would you still propose the same?

2. Camel Case might be better?
3. using just ‘id’ everywhere might be appealing.

Any comment on that?

Thank you.

How awesome is that?

this looks like it was created by a laid off VB programmer that moved on to pursue a career in physical database design.

What’s the L doing in cNameL ?

regards, Roland

(this lovely notation is enforced where I work, and those columns names are not made up)…

(heh. it seems we really do disagree Anyway, it’s fun and interesting to hear your point of view. Comments here to clarify mine – not to bash yours)

“Isn’t this a common enough kind of join that it’d be handy to have some shorthand”

Well, it means in a certain way that you are prepared to say: “of these 2 foreign keys from table A to table B, I think this one here is special enough to give its foreign key column the same name as the pk column of the parent table.”

“it conveys no meaning except for the fact that it’s by convention a primary key”

Yes. But in a way, that is exactly why I like it better than _id. Let me explain. Suppose I see a table called foo, having a name and a description and also the much dreaded id columns. Then I look at it as:

“name in foo, that must be the name of one foo instance, description in foo, that must describe the name of one foo instance, id – darn, that must be the surrogate key that identifies one foo instance”

In your naming scheme, the table would be called “foos” rather than “foo”, and the surrogate primary key would be called “foo_id”. When I look at that I’d say:

“name in foos, that is the name of one foo instance, description: description of one foo instance, foo_id that’s the foo_id of one foo instance – oh no, that must be the name of the id of one foo instance”

So to me, adding “foo” as a prefix is just redundant – to me it’s understood that the foo.id is the id of a foo just like foo.name is the name of a foo.

“I don’t think it’s necessary to prefix all columns, because they’re not nearly as likely to collide. But if every table names its primary key the same thing, they are certain to collide.”

Well, “…not as nearly…” means you’d be needing qualified columns in your queries at least some of the time. I argued in my previous comment that practically, there is not so much difference in prefixing the columns in the table def as compared to qualifying them in the query itself (which is what I prefer). Like I said, it’s almost never the id columns that collide in SELECT lists – I am more interested in the non-id columns there than in the id columns (but it doesn’t matter anyway because I always use qualified columns)

“Nor do I advocate always using the table name as a prefix in the primary key column’s name. ”

Well, that would depend on your table naming schema – plural or singular. To me, the plural doesn’t convey any information – its understood the table contains a multiple of <table-name> instances, so all the plural does is lengthen the identifiers. Add in the fact that I can’t easily mechanically derive the plural from the singular, it’s a pretty obvious choice to me – If i have the choice I stick with singular, even if that means living on the edge and defying any ISO standard or Celko book.

“I just helped a user today who had defined a many-to-many table as follows:”

Heh, I recall we discussed this earlier. Actually, this is exactly what I do, and for a reason. In an evolving schema, it’s not uncommon for a many to many relationship to gain attributes of its own, or even at some point to grow children of its own (at which point it apparently was more than just a relationship – apparently it was actually an entity of itself) Rather than adding the surrogate id later on, I do so up front. Having an extra id typically doesn’t hurt in case you really do have a pure intersection table (there may be exceptions if you are dealing with really, really large data sets).

“unfortunately, your syntax is not currently part of the SQL standard nor is it implemented in any SQL parser”

True. The ppl at the standards committee were too busy inventing NATURAL joins too listen to me :p

“it assumes that the storage engine supports named DRI constraints”

Not necessarily. It’s enough for the server to remember all metadata, and use it. It does not actually have to enfore it to look up how to expand this syntax into regular conditions.

regards,

Roland

But unfortunately, your syntax is not currently part of the SQL standard nor is it implemented in any SQL parser, as far as I know. And it assumes that the storage engine supports named DRI constraints.

You can also omit the column name in a foreign key declaration if the columns have the same name. It’s no big deal, it’s just a small convenience.

Another reason to eschew the ever-present “id” column is that it conveys no meaning except for the fact that it’s by convention a primary key. Using a more descriptive column name helps readability. In cases where the primary key is a natural key instead of a pseudokey, you should name the column to describe its contents.

I don’t think it’s necessary to prefix all columns, because they’re not nearly as likely to collide. But if every table names its primary key the same thing, they are certain to collide.

Nor do I advocate always using the table name as a prefix in the primary key column’s name. For one thing, it shouldn’t be plural (e.g. Categories.category_id is preferable to Categories.categories_id). It also doesn’t need to be based exactly on table name in all cases.

Anyway, all I meant to say is that “id” isn’t a good choice. Frameworks (like Rails) that insist that every table must have a pseudokey named “id” should be considered harmful!

I just helped a user today who had defined a many-to-many table as follows:

CREATE TABLE (
id INTEGER AUTO_INCREMENT PRIMARY KEY,
article_id INTEGER REFERENCES Articles(id),
keyword_id INTEGER REFERENCES Keywords(id)
);

Ouch!

So, I meant:

FROM fk_table PARENT(<fk-constraint-name>) IN pk_table

FROM pk_table CHILDREN(<fk-constraint-name>) IN fk_table

and

GROUP BY KEY(<table-name>)

GROUP BY [UNIQUE | FOREIGN] KEY(<table-name>, <constraint name>)

“one should not call the primary key in every table “id””
…
“it also neatly avoids some column name collisions in join queries”

Well, to some extent I agree: by definition, prefixing columns lessens the number of possible collisions. However, for me in practice, collisions don’t pose any problem to me as I always use table aliases and qualified columns anyway. I’m aware you could argue that that’s a chicken-egg situation (”I’m forced to using them, that’s why I use them”), but I think there is another issue at hand here.

Let me put it this way: suppose I would prefix the primary key column with the table name, and make them like %table_name%_id. Now, this will allow me to SELECT primary key columns from several tables, and they won’t collide. However, I usually find I don’t want to select those – meaningless, surrogate – primary key columns. What I do want to select a good deal more often are names, dates, descriptions, and codes.

So I guess my question is, why make such a special case out of primary key columns? If you are determined to prevent these name collisions, shouldn’t you be prefixing *all* columns? For example, all those columns called “name” and “status” and “description” etc. ? It seems to me you should either prefix none of them, or all of them.

And, if you decide to prefix all your columns, is that really practically different from what I do? I prefix all my columns too – I just happen to prefix them with table qualifiers.

I can think of just one reason why you would want to use prefixed primary key columns. If you are fond of the “named columns join” (the one with USING) then it’s convenient to give foreign key columns the same name as their corresponding primary key column. However, this then forces you to write similar joins over distinct foreign keys between the same two tables using different methods: one using the named columns join (for the one foreign key that could be named using the same name as the primary key) and one with the regular explicit qualified join (with ON). I understand that many people like the named columns join despite this, but I really dislike having to solve the exact same problem with two different syntaxes.

The only ‘fancy’ join method that would make sense to me is one that would allow you to somehow use the foreign key constraint name – something like:

FROM fk_table PARENT() IN pk_table

and

FROM pk_table CHILDREN() IN fk_table

that method would work for any imaginable foreign key without the need for special naming schemes, and it would also be resilient to any structural changes to the key.

Once we’d have the possibility to refer to entire constraints, why not allow references to them for other clauses too, like:

GROUP BY KEY()

or

GROUP BY KEY(, )

(PS1: the syntax is not important, the concept of using key names to denote a set of columns is the main thing)

(PS2: not trolling just offering food for thought – this is one of those topics where I don’t wish to pretend there’s one right way)