Re: How do I get this query to work?
- From: "Ed Prochak" <ed.prochak@xxxxxxxxxxxxxxxxxx>
- Date: 14 Jul 2005 12:14:10 -0700
Noel wrote:
> On 12 Jul 2005 16:35:35 -0700, "--CELKO--" <jcelko212@xxxxxxxxxxxxx>
> wrote:
>
> >Amazing how you do not have to refer to industry standards, or even do
> >even minimal research! Gee, what a waste of time it was to create VIN,
> >ISBN, UPC, etc. codes! Of course it has no data integrity, but boy it
> >was quick!
>
> Where such agreed standards exist and are truly international in
> nature, it makes sense to use them. However, I have seen, more than
> once or twice, you touting SSN as a 'standard' for identifying an
> individual, or D&B numbers as a way of identifying a business, while
> blithely ignoring the downsides to such an approach, and failing to
> respond to posts that point out these downsides.
>
> For instance, the SSN approach for identifying individuals may be
> workable provided that you or the business you are working for are
> certain never to do business outside the borders of the U.S. Using
> D&B numbers to identify businesses is fine if you only want to do
> business with those who have D&B numbers. I have encountered too many
> businesses who adopt such rigid approaches to their own detriment. My
> attempts to get a mobile phone SIM card in Italy were complicated by
> the fact that certain mobile providers there insist on a 'codice
> fiscale' ostensibly 'because the computer system requires it'. In
> doing so they are throwing away business from foreigners who do not
> possess this magic number. This is a classic case of the business
> working for the database rather than the database working for the
> business, as it should be.
Are you arguing that you would create and autoID field for a person
table for the payroll system of a US based company?
Using SSN in that case is appropriate (even though it is a pseudo key
itself but that's a higher level discussion), even if they 'can be made
up or stolen'.
I think your real issue is with well designed DB that conforms to
poorly thought out business policies. You might still run into your
'codice fiscale' rule if they were using a paper account form. IOW, the
example is one of a poor businees rule, NOT a poor DB design.
>
> Even if they are satisfied to limit their business in this way, and
> the 'codice fiscale' may seem to conform to your notion of an
> 'industry standard' method of identifying individuals, it is a
> dangerous choice, as it is possible for two individuals with similar
> names born in the same 'commune' on the same day to have the same
> number. Ditto with SSNs. They can be made up or stolen, and even
> those who have a legitimate number may not be too happy to part with
> it.
>
> >Since autoincrement numbers cannot be validated or verified in the data
> >model, you would NEVER use them in an RDBMS. They are exposed physical
> >locators, usually an attmept to mimic the record numbers from a file
> >model.
>
> They are not usually an attempt to mimic record numbers, but to
> provide a unique identifier where no such identifiers exist.
> Practically every modern RDBMS has an auto-increment numbering system,
> so your claim that you would *never* use them in an RDBMS rings
> hollow. My only beef with the surrogate-key approach is that it is
> normally implemented without any sort of check digit mechanism.
And a check digit mechanism will do NOTHING to resolve the made up or
stolen number issue. In fact creating your own customer number falls
into the same trap. It is best to use some combination of attributes to
uniquely identify a person. In fact even DNA as a single ID doesn't
work, but a combination of fingerprint and DNA might be the nearly
perfect person ID. I don't see how you can expect any single number to
work as a PK for a person consistantly. (note your idea of a check
digit is actually also a combined key: number and check)
But for other things, ID fields are often used just like record numbers
for other entities in the databse. Look at some of the questions asked
of the DB. If they aren't used that way, why not have an auto ID
generator use a sequence of random numbers? would you object to that?
Why?
Ed
.
- Follow-Ups:
- Re: How do I get this query to work?
- From: AK
- Re: How do I get this query to work?
- From: Gene Wirchenko
- Re: How do I get this query to work?
- Prev by Date: Re: The right database for the job?
- Next by Date: Re: Basic SQL
- Previous by thread: Which results do you want?
- Next by thread: Re: How do I get this query to work?
- Index(es):
Relevant Pages
|
