Joakim Hove wrote: > > > Hello, > > thanks for the tip: > >> It is usually not a good idea to give business meaning to a primary key >> in a relational database. The literature is full of reasons against it. > > I had a nagging feeling this might be the case. Do you have any links > to "Best practice" om these questions - I am a database freshman.
There are cases for and against but in general the best rule is don't do it. As soon as you invest meaning in a pk you give up one complete degree of flexibility. Imagine if you decide to rework your database schema one day to add some new-fangled feature. That would likely require a dump and data-tweak on reload. You would find it difficult to guarantee the same pk. Don't do it if the primary key becomes a visible part of your data for users. For example, you might get away with bending the rule and use a pk as a delivery docket number because such a document is fairly short-lived. I wouldn't do it. As a rule. Mike > > Thanks - Joakim > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
