问题
I need to create a database design where bar or event owners (admin-table because they own a profile) send alerts to users.
I want to create an "ALERT" table but have a hard time deciding what primary key to use.
I thought adding a composite key containing at least admin_ID (PFK), user_ID (PFK) and I thought to add Date and Time stamp to the primary key to indicate that many alerts (notifications) can be sent by an admin, but only 1 at a certain point in time.
However, from this thread: Timestamp as part of composite primary key?, I learned that I shouldn't use the timestamp.
By the way, it has not been decided what DB software we will use at this point.
I sometimes have the tendency to quickly move to an autoincrement key. I have never noticed problems with that (in Access), however from what I read, this may not always be the most meaningful thing to do, therefore I ask the question to professionals.
I only have one chance to do this the right way to make the back end fundamentally right.
What are your thoughts on this?
回答1:
Your going to get a lot of heated debate over the issue of what to use for a PK. A purist will tell you that you should never use an auto-increment key (assuming SQL SERVER). Someone who's been in the real trenches will tell you they are perfectly fine as a PK (in most cases) and have some real advantages.
I won't try to persuade you one way or the other. But I will tell you my experience. I have been developing software for 25 years and have been using an RDBMS for much of that time (mostly SQL Server). Personally, I find auto-increment PKs invaluable and 99.99% of the time would never consider using anything else. Why?
- SQL Server generates them and, therefore, handles all concurrency issues.
- They are small in size and, therefore, lookups on these keys are very fast.
- You can easily refer to a particular row in a table by its Id value. This may not sound like a big deal, but it can sure come in handy. For example, I cannot tell you how many times I've asked a co-developer to take a look at a row in a table with key value 12345. A simple thing, but very useful.
- FKs that reference a PK in a table will be the same type, and, therefore, also small and fast, and easy to work with.
- Little or no fragmentation of the index, especially if the PK is a clustered index (in SQL Server).
There can be one big disadvantage with this sort of PK. If you ever have to merge rows from one database to another, you have the potential of running into PK value collisions. However, there are ways to work around this as well. Also, of course, an auto-increment value will have no true meaning. But that's ok. Its purpose is to provide uniqueness.
Is this a perfect solution. Nope. And others will disagree with the use of them. However, they have worked very well for me, for most high-end, and business critical, projects.
回答2:
you have always the option to use UUID ( http://en.wikipedia.org/wiki/Universally_unique_identifier ) for your database primary keys.
All major programming languages have a support for it and IMO it is one choice, probably though not the best because it suffers from low efficiency .
回答3:
- There is nothing wrong with composite primary keys per se
- There is a problem if any of a PK's components is NULLable
- ... such as when any of the components also functions as a FK to another table (or "domain")
来源：https://stackoverflow.com/questions/12387695/composite-primary-keys-in-databases