@mikeh: I’ve done that before, actually! I had a table for key values, with columns something like pk_name, value, chunk_size, max_value, then a singleton SequenceManager that would claim PKs from the table in “chunk_size” chunks, dole them out as needed, send email warnings if we were approaching the max_value, and reset the sequence back to 1 when it hit the max.

In retrospect, though, I wouldn’t recommend it. The design was simple; implementing the code was trickier, and we did have some subtle bugs show up — that singleton object that doles out the IDs needed to be threadsafe but couldn’t lock out *all* PK requests when it needed to claim a new chunk for just one stack (welcome to concurrency tricks). Now cluster the app servers, so each server has its *own* SequenceManager, and they have to play nicely even when refreshing at the same time….

The biggest problem is reimplementing all of the features of sequences that are nowadays very likely built into the database already. That project was working with DB2400; I don’t remember what it had (and possibly didn’t know at the time…). But at least in Oracle, this is *all* stuff the sequence can do for you (even pre-claiming chunks of N at a time) so getting a new PK is really going to be extremely fast… very unlikely to be near the top of performance hotspots, and thus not a candidate for a bunch of complex custom code.

I think only four. That’s better than the average legacy code base, but could be better, I think.

I prefer non-space names, underscore-enriched, no warts or prefixes, no concern for plural v. singular in table names (be consistent only), totally agree with Rob on #6, and I don’t particularly like guids for IDs.

Scary to agree so much.

As for table prefixes, leave them out. They limit your ability to turn tables into views and vice-versa if your requirement later change. Then for linking tables I usually use something like CustomersAddressesMap.

“The name of a table should describe one row of the table.”

So, a table of customers would be called ‘customer’, a crosswalk table between customers and companies would be ‘customer_company’, and one where each row was a matrix of companies would be “companies”. In practice, I’ve only ever found singular table rows, however.

WRT your second point — what were the reasons for using the GUID PK in the first place? It sounds like you had two separate primary keys in that situation (one as the “real” PK, one to operate as a readable identifier and foreign key), which would be confusing, so I imagine there were reasons for needing them both.

The prefix argument I still don’t buy. Are there good reasons for sharing a single database schema for multiple applications? You can always leave them in the same database instance for reasons of simple backups, perhaps shared data, etc.; just put them in different schemas, then (you can still hit both schemas from one DB connection, but they won’t be stepping on each others toes)… that also makes it easier to move them to separate servers later as they grow, which seems more likely than that you’d be adding more applications to a single schema. And If I want to import tables from another database, well, I’d tweak the incoming data however I needed to make it consistent with the “home” schema. There’s some minor extra work involved in renaming the tables, columns, etc. to match the existing standards, but it’s a rare enough situation that I wouldn’t worry about it.

@ME: Yes, programming languages like you mentioned are case-sensitive; but SQL by default and historically is not… you can select * from CUSTOMER or SELECT * fRom custoMER and it’ll work either way.

I believe there’s support nowadays for using case-sensitive table names in most databases, but it seems to be problematic (partly because of the history of case-insensitivity affects tool assumptions).

So you can do it, but it’s not the “norm” and I am arguing that it isn’t worth the trouble.

Yes the DB may be case sensitive, so you have to write SQL in the correct case by following the naming convention.

People not following a convention is not an argument against the convention.

I agree with all your points; just I tend to use “id” rather than “tablename_id”, and as I do a fair bit of Rails work I tend to use pluralized forms nowadays – Rails has a reasonably comprehensive singular plural form function to do all the hard work. Makes you wonder why they bothered, but oh well.

http://svn.rubyonrails.org/rails/trunk/activesupport/lib/active_support/inflections.rb

I see your point about the readability of GUIDs. However, I think there is benefit to using GUIDs for certain PKs. I’ve successfully used GUID as the pk and a sequence as a surrogate key (populated with a trigger) and had the surrogate key as the foreign key elsewhere.

For table names, it makes sense to ALWAYS use a prefix – sometimes you have tables from another app migrated into yours – it helps to easily distinguish between table sets then. I always use a TLA – 2 letters identifying the application and one for sub module. So for a bulletin board app, table prefixes may be BBS for system tables, BBU for user tables, BBM for message tables, etc.

But that’s only values, not table or column names.

Can you give an example of where that could be a problem? I done a few projects using MySQL, but I’ve never heard of this issue before.

It, ah, perhaps limits your options a bit, but it certainly resolves the issue!

On the other hand, another argument for plural (beyond what you mentioned): some databases have administrative tables with names that you perhaps shouldn’t duplicate in your own schema, like “user” and “privilege”. THOSE are singular (in Oracle at least, which is what I’m thinking of), so if you have a table for your users and your own role/privilege setup in the database, using plural tablenames there’s no possible confusion.

The more important point with this one is consistency, since there’s no significant cost or risk either way — if I’m working on a database designed by someone else with plural names, I definitely follow that convention with any new tables.