-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/27/06 14:34, Scott Ribe wrote:
>> ...*most especially* when they are the only unique key.
>
> There are usually other keys which should be unique, and this should
> certainly be reflected in the db design. On the other hand, designers should
> not strive to find and enforce combinations that won't actually necessarily
> be unique, such as the above-cited example of first 5 letters of last name +
> last 4 of SSN. (There are certainly more than 10,000 Smiths in the US. In
> fact: there will be more than 10,000 Smiths in each of most of the 50
> states!)
Just because your (bank?) creates a lame username, doesn't mean that
there shouldn't be one.
>> If I base a master sales table on account_number and date/time, then
>> every CPA in the country will descend on me with calculators
>> sharpened if I decide to update the SALE_DATE column.
>
> But if the company is sold/merged, it is likely that accounts will get new
> account numbers, and even possible that account numbers will not be unique
> across the union of the (formerly) two companies' accounts thus absolutely
> requiring account number changes. This is exactly the kind of thing I'm
> talking about, and why I think account # + date/time would be a lousy
> primary key. It's fine to treat it as a key, but certainly not the primary.
OK, let's use a synthetic key on the sales master table. In fact,
*both* companies have a synthetic key on their sales master tables.
OMG, conflicting/overlapping synthetic keys!!!!!
- --
Ron Johnson, Jr.
Jefferson LA USA
Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFa1AUS9HxQb37XmcRAt0fAJsFPJfjMUEv+2E2XELq6Av6ZFZ98gCfXnkf
sJeeyjr3Bq2T9N5Sd0ca7SY=
=vedL
-----END PGP SIGNATURE-----
