Re: Dynamic column specification in table update
From: Louis Davidson (dr_dontspamme_sql_at_hotmail.com)
Date: 10/11/04
- Next message: Simon Kissane: "Re: Can't get xp_hello sample to work"
- Previous message: Louis Davidson: "Re: Dynamic column specification in table update"
- In reply to: Zach Wells: "Re: Dynamic column specification in table update"
- Next in thread: Anith Sen: "Re: Dynamic column specification in table update"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 10 Oct 2004 21:10:35 -0500
It is OK, but not perfectly OK. Say two John Smiths from Fort Winston,
Wyoming apply for a job at your company. How do you tell them apart? How
you would tell them apart would be your key. Plain and simple. Relatively
unlikely, yep. But still something that you should consider when building
objects.
Do I think that a random value shouldn't be A key, obviously not. But you
need to be able to tell two objects apart somehow, without guessing . So
you keep adding data to your natural key until the probablility of
duplication is tolerable. And there are cases ( and this might be one of
them ) where no natural key exists (certainly not contained in the same
table), and you simply live with a key that is not natural, like asssigning
an applicant number and giving that to your applicants. Think of the case
where you call the IRS and you don't have your account number. They can
find you from your other information, like name and address or name and
phone number, but it is not always so easy.
Either way, I totally wouldn't use identities as the only unique key,
because they are so inflexible. Mistakes get made, gaps get left, not to
mention that there are ironic, wierd, and offensive number patterns that
arise that you may not want to pass out ( For example, say you are a
Christian church organization, we wouldn't want to give a member number 666.
That would so freak them out.)
-- ---------------------------------------------------------------------------- Louis Davidson - drsql@hotmail.com SQL Server MVP Compass Technology Management - www.compass.net Pro SQL Server 2000 Database Design - http://www.apress.com/book/bookDisplay.html?bID=266 Note: Please reply to the newsgroups only unless you are interested in consulting services. All other replies may be ignored :) "Zach Wells" <none@by.com> wrote in message news:O%23hMloZrEHA.3464@TK2MSFTNGP14.phx.gbl... > Ok then, I'll pose this question to you, once that I've often thrown up > at Joe while he's on one of his "the data always makes the key" rants. > What would you use as the primary key in a database that stores people > that could become employees? Keep in mind, the "theory" is that your > primary key should be made up from your data. > > My position is, in cases like this, it is perfectly OK to use some > random value as your primary key. There simply is no data-centric values > that you can use to make a reliable primary key when dealing with > people. This is a case where the theory takes a backseat to real world > requirements. > > Zach > > Louis Davidson wrote: > >>It is possible to be too far on the theory side of things. > > > > > > I disagree here in principle. No one ever says, "wow, this car drives > > great, but I think they designed it too well" or "I wish they hadn't > > studied physics so deeply when building this bridge" or "I'm sad they wasted > > time studying Bernoulli's silly ideas when they built this plane I am > > trusting my life with." > > > > The only excuses tend to fall along the lines of laziness or ignorance. I > > personally use the laziness excuse when I don't do as good a job on a design > > as I know how or have time for. Most every programmer is lazy at one time > > or another, but ignorance is intolerable, because we have such good places > > to learn from. Even still, a great deal of the ignorance I deal with is > > from someone else making me do a less than adequate job, or dealing with > > poorly designed third party tools. > > > > The reality is that the theories we hold can be different to many degrees. > > And if your theory of a proper database system is that all data should be > > encapsulated in a single table, then you are cheating yourself if you use > > two tables (three will get you flogged I imagine.) The beauty of our > > profession is that we are not bound by immutable spiritual or religious laws > > that if broken makes our Creator displeased. Fortunately, computing theory > > is a mutable. If you come up with a bettor theory that works follow it, and > > share it. That is how we got relational theory. > > > > On the other hand, what usually happens is that while people know that > > theory is a good thing, well, maybe not it this case. If I just do it a > > little, it will be ok, just this once. No one will know..... > >
- Next message: Simon Kissane: "Re: Can't get xp_hello sample to work"
- Previous message: Louis Davidson: "Re: Dynamic column specification in table update"
- In reply to: Zach Wells: "Re: Dynamic column specification in table update"
- Next in thread: Anith Sen: "Re: Dynamic column specification in table update"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
