Hello. I must confess that I am rather new at this. During my courses, I was taught to place an auto increment as an id field in my tables, when in need to.
However, recently, I heard someone comment that this is to be completely avoided. But I do not understand why. Perhaps anon could point me in the right direction?
>>10,11
No shit. (Warning: suspicious use of specifier 'conversely'.)
>>12
I could circuit the Earth without having someone need an SQL database. 99.98% might think they need one until they see the DBA rates, then they will listen to reason when you offer a better alternative solution. (Example: No one using MySQL needs SQL. If they did, they wouldn't be using MySQL.)
>>7
Natural keys are elegant solutions only on homework assignments.
In real life the requirements change halfway through the project, and they end up causing you more work while providing no actual benefit.
As a bonus the insertion order is very often useful.
>>7 Surrogate keys are a symptom of bad design.
Really? Because I can't think of any better solutions for implementing Enterprise-grade applications such as Shiichan, MOTHERFUCKER.
At work we had a very difficult time because the databases were modelled in an elegant relational way. Basically, the primary key to our most important table lost its semantical value (due to unpredictable circumstances). We had millions of records. Changing it was nearly impossible. We had to add an extra column and change the way hundreds of applications worked.
There's something SQL people have a hard time to understand: data changes.
>>29
I've only worked on a few databases, but each one gave me the impression that the best primary key is a semantically empty primary key. When you've got to maintain this database for over 10 years, three managers, two application changes, etc., every single decision you make wrt semantics will be invalidated eventually.
>>37
In 12 years of doing what ever it is they pay me for I've noticed that people try to stuff everything into a DB even when it clearly violates the K.I.S.S. principle.
DBs are overly complex and generally a cluster fuck to implement and maintain.
Like the old saying if all you have is a hammer (DB in this case) the whole world looks like a nail.
Mind you there are perfectly valid implementations, like myspace and facebook's over 9000 million users, but unless you there is no possible other solution a DB is major overkill.