TomThomson (1/28/2015)

---

Eric M Russell (1/27/2015)

---

andrew gothard (1/27/2015)

---

Eric M Russell (1/21/2015)

---

ProductID, ProductId, and product_id are all respectable options, so long as it's done consistently.

However, I would take issue with ID by itself, on every table. Anytime I see that, I have low expectations for how the rest of the database is designed.

Even worse. GUID as a column on every table ...

Regardless of datatype, I don't want to see a column names having no contextual prefix, meaning just "ID" by itself, on any table, and much less on every table.

As for GUIDs, it's a natural fit for the XML document world, where data is exchanged globally, but there is no centralized global mechanism for obtaining unique and sequential identifiers. However, in the relational database world, I rarely see a strong and compelling argument for having primary or surrogate keys as type GUID. Even in an environment that uses federated databases or merge replication, simple integer based identity columns or sequences can be seeded within a different rage on each server.

Integer doesn't always work - 2**32 is quite a small number; but identity types can cover a much larger range, as they aren't restricted to integer, and the only imaginable justification for using a GUID is that (if you pick the right generation GUID spec) you may be globally, not just locally, unique.

I've known systems where the ID of an X was X_ID everywhere except the X table, where it was just ID. I really didn't see any problem with that, clearly ID as a column name in any join was going to need a prefix, but it didn't seem (to me anyway) to introduce any real problem (in fact it encouraged people to provide table alisases and use them in the select list, exactly the opposite of a problem). But anything I designed myself called it X_ID even in the X table, so maybe I agree with you even though a different approach is workable and in some ways useful.

Edit: I forgot to say: Anything that's a natural fit for the XML world must of course be hopelessly wrong for the relational world.