SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Site Related Forums
 Article Discussion
 Article: Identity and Primary Keys
 New Topic  Reply to Topic
 Printer Friendly
Previous Page | Next Page
Author Previous Topic Topic Next Topic
Page: of 8

nr
SQLTeam MVY

United Kingdom
12543 Posts

Posted - 12/09/2002 :  09:20:20  Show Profile  Visit nr's Homepage  Reply with Quote
quote:

(continued from previous...)

This absurd notion that a PK solely defines a unique entity, which is being perpetuated in this thread, has got to stop. If you remember one thing, remember this: a PK is used to build relationships. Period. Nothing more, nothing less. Don't forget it. To meet that end, it must be unique, but DOES NOT IN ANY WAY define what makes a logical entity unique. If anybody tries to tell you that, they are a moron. If you just define a PK and move on, your system is BROKEN, human-readable PK or not. YOU, the developer, must take additional steps to define and enforce what combination of attributes define a unique entity, based on what your business rules and/or human logic require. THAT is what you are paid by the hour for, not for wasting my money pondering what column or columns you should use for a f'ing PK.



Hmm - wonder what the difference between a primary key and a candidate key is.
Agree with the bit about entities (if you mean business entities) PKs are much lower level than that.
Disagree with
>> a PK is used to build relationships. Period. Nothing more, nothing less.
A PK is the item identifies a record in a table as opposed to a unique index which just enforces a constraint (and represents a candidate key).

>> The fool that wrote this article is trying to convince you to break the 1st, 2nd, and 3rd forms of normalization. One entity's PK is another's FK (if not, you shouldn't be using an RDBMS).

Just noticed that - You would find it very difficult to complete a datbase structure if you followed that advice, you could never have a highest level entity as you would have to create something higher to reference the PK. If the highest level wasn't self referencing (directly or indirectly) you would have to create redundant tables with copies of the data to make it so.

I just love comments that ridicule others.
Almost tempted to read the article.

==========================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy.

Edited by - nr on 12/09/2002 09:30:31
Go to Top of Page

jsmith8858
Dr. Cross Join

USA
7423 Posts

Posted - 12/09/2002 :  09:25:02  Show Profile  Visit jsmith8858's Homepage  Reply with Quote
Wow, what re-opened this can of worms?

I think of it this way:

Start with the data you want to store in your table. Examine it. Does a primary key come "naturally" from the data?

If yes, go ahead and use it.

If no, decide for yourself: Is the key of this table very important -- does it have to follow a certain convention, will be used in sorting, etc.

If yes, come up with your own method to create them (i.e., a formula, prompt the user, etc)

If no, doublecheck one last time (is there a field you can add, etc), and if not, use an IDENTITY field.

Is it really much more complicated than that? (I do tend to over-simplify things ... )

- Jeff
Go to Top of Page

AjarnMark
SQL Slashing Gunting Master

USA
3246 Posts

Posted - 12/09/2002 :  16:45:33  Show Profile  Visit AjarnMark's Homepage  Reply with Quote
Well, BT, you certainly have proven that you know how to write offensively and in a controlling tone. But you seem to have forgotten the basics of communication which include the fact that you are a total rookie here on this site (grand total of 2 posts so far) and have not proven yourself to have any real knowledge. And yet you start out by attacking one of the top veterans of the site. This suggests that you are not at all knowledgeable (nor emotionally mature) but rather you are simply attempting to be a bully. You have no grounds with which to speak here in such a domineering voice. Fortunately for you, Rob seems to have merely brushed you away like an irritating gnat.

So, the next time you decide to spout off such "wise" words as:
quote:
the wisdom of the sages who've been there, done that, got the scars to prove it.
you might want to show a few credentials (or scars) other than the fact that you've gained such worldly wisdom by the grand ol' age of 35. Oh, and you are a "Director", which I cannot tell you just how impressed I am by titles. You seem to have forgotten to indicate which company thought so incredibly highly of you to call you a director. Is it by any chance your own company? Hey, I'm the President of my company. Big Deal.

If you've got the guts to stick around and prove yourself worthy by posting some actually helpful information, we might be more interested in what you have to say. But for now, your tirade reads as nothing more than a childish attempt to get attention. OK, you got attention, now go sit in the corner until you can learn some manners.

------------------------------------------------------
The more you know, the more you know you don't know.
Go to Top of Page

rrb
SQLTeam Poet Laureate

Australia
1479 Posts

Posted - 12/09/2002 :  17:35:07  Show Profile  Reply with Quote
Wow - OK so you all made me read the article.

As someone who hasn't made their mind up yet (prolly not clever enough) I do find all the arguments interesting, but my experience leads me to both approaches, depending on the application.

Maybe it's because I'm a pragmatist, but maybe it's also because I haven't read Pt II and Pt III yet...

--
I hope that when I die someone will say of me "That guy sure owed me a lot of money"
Go to Top of Page

JohnDeere
Posting Yak Master

USA
191 Posts

Posted - 12/09/2002 :  18:05:37  Show Profile  Reply with Quote
I think that as others have said you have to evaluate on a case by case basis. It would be nice if one approach was always superior, but that is just not true. We have adopted a standard of surrogate keys because it simplified issues in data warehouse design and load and the tradeoffs have been worth it so far. Pick what will provide the best overall solution for you.

My $0.02 worth anyway.

Lance Harra
Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/15/2002 :  23:45:53  Show Profile  Visit quazibubble's Homepage  Reply with Quote
To anyone thinking that "natural keys" is a good idea, and think the article's author is an intelligent, respected, experienced technical leader, and the liberal tards who are offended by my ad hominem arguments:

Promote your moral ambiguity to someone who cares. You sensitive types like Doug G proclaiming that "we should challenge each other's ideas in a positive loving way, not say bad hurtful things to each other" should be shot. The article's author is a moron, period. There is no ambiguity. The fact that clowns like AjarnMark thinks he is a "top veteran" only shows how dangerous his post really is, polluting the weak minds of those who just want to follow someone great, not think for themselves.

Jokers such as jsmith8858 wasting hours with a rediculous "process" to find a "natural key" should be shot too. That's the only way I could be sure not to have to deal with your designs that will box me into a corner, break, and waste money. No telling what other foolery you subscribe to. (Homeopathy? Alien abduction? UFOs? Magnetic healing? Get out of my sight.)

As far as what company I work for, what special kind of stupid does it take to think I would reveal that? (Apparently AjarnMark's type of stupid, who has his whole freakin' life for all to see, as if anyone at SQLTeam.com--or anywhere--would care. Be sure to go to his website, where he says he apparently likes waverunners and pictures of Lear jets. Oh, and his website is a skunkworks for "web ideas"...apparently they have been pretty slow in coming. And SQLTeam listed as a hobby twice? Someone has a LITTLE too much free time...Nice Miami Vice getup, too.)

RE: Director position: Don't believe me folks. I don't believe any information about anyone posted on the internet. You shouldn't trust that I'm 35 either. The fact is, I usually just enter anything when signing up for sites that require a login. The less information I broadcast to the entire world, the better. But a little common sense may be in order. Say, AjarnMark, do you know how many Director-level positions there are in the world? More than you can count. It takes no special talent to get promoted to director (but much more talent than arguing for "natural" keys). But then again, you do believe in an invisible man who lives in the sky, knows when you're naughty and nice, and will make you live forever. At any rate, a moment's reflection might reveal that small companies typically do not have directors. The smallest have a President, and grunts. Bigger ones add CxO positoins. Then EVPs, SVPs, and VPs. Typically, only large companies have Directors. "Director" is just not a flashy enough title, and is among the last positions companies create as they grow.

(continued...)

Go to Top of Page

Merkin
Funky Drop Bear Fearing SQL Dude!

Australia
4970 Posts

Posted - 12/16/2002 :  00:01:31  Show Profile  Visit Merkin's Homepage  Reply with Quote
Dude, I think you might need to up your medication.

You have made it pretty clear you don't agree with the article. We get it.

Do you want to stay here and discuss SQL Server, or just get into name calling ?

If it is the latter, I suggest you go and get some anger management therapy and come back when you learn to play nice with others.

Damian

Edited by - Merkin on 12/16/2002 00:05:45
Go to Top of Page

rrb
SQLTeam Poet Laureate

Australia
1479 Posts

Posted - 12/16/2002 :  00:23:15  Show Profile  Reply with Quote
quote:
Jokers such as jsmith8858 wasting hours with a rediculous "process" to find a "natural key" should be shot too.


since we're being picky - I'd like to point out that your spelling SUX


--
I hope that when I die someone will say of me "That guy sure owed me a lot of money"
Go to Top of Page

nr
SQLTeam MVY

United Kingdom
12543 Posts

Posted - 12/16/2002 :  05:37:02  Show Profile  Visit nr's Homepage  Reply with Quote
>> To anyone thinking that "natural keys" is a good idea, and think the article's author is an intelligent, respected, experienced technical leader, and the liberal tards who are offended by my ad hominem arguments:

Experience, intelligence, respect, ...
None of these should be an excuse for blind acceptance of a theory (beware the inquisition and Bell Laboratories).

Haven't read the article but

>> Jokers such as jsmith8858 wasting hours with a rediculous "process" to find a "natural key" should be shot too.

>> That's the only way I could be sure not to have to deal with your designs that will box me into a corner, break, and waste money.

>> No telling what other foolery you subscribe to. (Homeopathy? Alien abduction? UFOs? Magnetic healing? Get out of my sight.)

Blind rejection of a theory isn't much better. Would be nice to see a reasoned argument or at least some evidence of thought or understanding here.

>> The less information I broadcast to the entire world, the better. (Internet)
Couldn't agree more - who/what you are shouldn't have any bearing on the argument.

==========================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy.
Go to Top of Page

Page47
Flowing Fount of Yak Knowledge

USA
2878 Posts

Posted - 12/16/2002 :  07:59:45  Show Profile  Reply with Quote
quote:
The fool that wrote this article is trying to convince you to break the 1st, 2nd, and 3rd forms of normalization. One entity's PK is another's FK (if not, you shouldn't be using an RDBMS). An FK that is actually a descriptive attribute of some other entity creates repeating groups, redundant data, and directly describes something other than the primary entity.


quazibubble, could you please give an example of how using a natural key creates "repeating groups, redundant data, and directly describes something other than the primary entity"?

Jay White
{0}
Go to Top of Page

Onamuji
Aged Yak Warrior

USA
504 Posts

Posted - 12/16/2002 :  08:09:40  Show Profile  Visit Onamuji's Homepage  Send Onamuji an AOL message  Reply with Quote
it sounds like he got his "director" position because he can write mean stories ... sounds like some people at my company ... they bash one method so much that everyone praises them because they are so convincingly mean! plus they have no idea about the other methods they are bashing ... they are just afraid of learning something new... or they are just lazy and its easier to slam what you don't know ...

Go to Top of Page

nr
SQLTeam MVY

United Kingdom
12543 Posts

Posted - 12/16/2002 :  08:59:26  Show Profile  Visit nr's Homepage  Reply with Quote
quote:

they bash one method so much that everyone praises them because they are so convincingly mean! plus they have no idea about the other methods they are bashing ... they are just afraid of learning something new... or they are just lazy and its easier to slam what you don't know ...



And what's wrong with that?

(Caught me out).

==========================================
Cursors are useful if you don't know sql.
DTS can be used in a similar way.
Beer is not cold and it isn't fizzy.
Go to Top of Page

jsmith8858
Dr. Cross Join

USA
7423 Posts

Posted - 12/16/2002 :  10:49:59  Show Profile  Visit jsmith8858's Homepage  Reply with Quote
quote:

Jokers such as jsmith8858 wasting hours with a rediculous "process" to find a "natural key" should be shot too. That's the only way I could be sure not to have to deal with your designs that will box me into a corner, break, and waste money. No telling what other foolery you subscribe to. (Homeopathy? Alien abduction? UFOs? Magnetic healing? Get out of my sight.)



Sorry it took so long to get back to everyone. It took me all weekend to run my complex process to determine the primary key for a table of US States. Also, there was an Alien Abudction conference this weekend so that took some of my time.

Wow. What a post. Someone desperately wants some attention.

Quazibubble -- We look forward to reading some nice articles and solutions to our problems here so you can demonstrate your superior intelligence to all of us.

- Jeff
Go to Top of Page

tkizer
Almighty SQL Goddess

USA
37129 Posts

Posted - 12/16/2002 :  17:52:57  Show Profile  Visit tkizer's Homepage  Reply with Quote
quote:

Sorry it took so long to get back to everyone. It took me all weekend to run my complex process to determine the primary key for a table of US States.



ROTFLMAO!!!

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:17:28  Show Profile  Visit quazibubble's Homepage  Reply with Quote
I'm at home sick today, so let's just set this thing straight. If any holdouts to "natural key" dogma read this, and consider it without their blinders on, I guarantee there will not be a single holdout when the dust settles. I will then welcome you to the light side of the force, not ridicule you the absurd, dogmatic beliefs held in your squandered past.

You will see the theories compared and dissected. Proof will be clearly provided with practical, real-world demonstrative application. You will understand the math behind the theory, and why it makes the real-world application work.

But first, to respond to some comments: To [nr] who states "Would be nice to see a reasoned argument or at least some evidence of thought or understanding here"...see my first two posts in this thread on 12/8. But I'll make the case crystal clear this time.

To [Page47] who asks "could you please give an example of how using a natural key creates 'repeating groups, redundant data, and directly describes something other than the primary entity'". I already did earlier, but since you apparently aren't too quick, I'll do it again. Here's a record set representing a employees, with a reference to superiors, using your beloved "natural keys":

ID, Name, DOB, Boss ID, Boss DOB
"321-45-9874", "Bob Smith", "5/3/1962", "123-54-4789", "1/1/1934"
"322-45-9874", "Julie Smith", "1/1/1999", "123-54-4789", "1/1/1934"
"123-54-4789", "Boss D. Man", "1/1/1934", "000-00-0001", "1/1/0001"

[Page47], I'll let you get out your "Normalized Design 101" and figure out for yourself why this violates the first 3 (most important) forms of normalization. I will not argue this point further with you in particular, seeing as you work for a company I wouldn't hire if I had a gun to my head--not only for your ridiculous, self-righteous, esoteric, coffee-shop wanna-be "philosophy" page, but because it's clear from your other posts that you simply don't get it, and tend to just blindly parrot the same ridiculous drivel over and over, without offering any compelling logic or practical, real-world proof to support it.

I'm now officially done embarrassing any specific person, nobody need worry any more. Anything more I say that sounds like personal attacks are, I assure you, tongue-in-cheek.

[jsmith8858] who wrote "It took me all weekend to run my complex process to determine the primary key for a table of US States. Also, there was an Alien Abduction conference...". For the first time while visiting this site, I am actually laughing. Finally, someone with a healthy sense of perspective and humor. It gives me the energy to explain, once and for all, why the concept of "natural keys" is ridiculous folly of the inexperienced mind, and results in nothing but headaches for the future architects, administrators, and programmers of your system. (Plus, I'm home sick and have nothing better to do.)

(continued...)

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:27:03  Show Profile  Visit quazibubble's Homepage  Reply with Quote
OK folks, now for the REAL NITTY GRITTY. Do not proceed unless you are emotionally prepared to have your frightened, dogmatic grip on "natural keys" broken forever. I've read lots of boasting of credentials on this topic, reverence for false prophets, and endless--ever so endless--reinventing of the wheel. It's time to Stop The Madness™.

First rule: Your "credentials" are good for exactly two things: Jack, and Squat. (Mine are good for the same things.) So leave them at the doorstep. I don't care if you are a CIO, a 90-year old logician, or the President of Iceland. Just like in the real world, "what have you done for me lately".

Second rule: The word "natural key" is stricken from our vocabulary. "Natural" is a loaded word pre-imbued with meanings of wholesome goodness. But there is nothing natural, wholesome, or good about the concept of a "natural key" to the cold heart of an RDBMS just trying to represent relational data. From here on, we'll refer to them as "UNKs", pronounced like it looks, an acronym for "un-natural keys".


We'll start with a review of previously proposed candidates for UNKs, and what's wrong with them:

1) SSN: Not guaranteed to be unique if there was ever a typo in your system or the government's. Also, human data entry typos are quite common, so be sure to design your system to not fall to it's knees on every cascading update. And contrary to the wisdom of the teeming masses, no one, not even employees, are obligated by law to give you their SSN, for tax purposes or otherwise (granted few people will hire you without one). Furthermore, are you prepared to prohibit entering a record without a SSN? Would your business users be happy with that decision?

2) Phone number: PNs are recycled by telcos. Typos are common. People don't like giving out their phone numbers. Typos, number changes, and cascading updates. Required fields. What if the schema changes years from now and phone numbers are stored in a child entity? I could go on.

3) Anything using birth date as part of formula: very highly likely does not add significantly to uniqueness, therefore just makes it longer unnecessarily. Typos and cascading updates. Required fields. Etc.

4) Network login: Can be recycled, not unique across domains, company mergers can cause problems, etc. Typos, name changes, and cascading updates. Required fields. Etc.

5) Email address: Do I really need to go on?

(continued...)

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:27:42  Show Profile  Visit quazibubble's Homepage  Reply with Quote
6) Timestamps: Getting closer to a useful system key (because it's not dependent on human input that meaningfully describes the entity, and is closer to an arbitrary system-generated value), but wastes alot of space in order to simultaneously gain probability of uniqueness (through high-resolution) and the ability to use the system for more than a few days or months. If your resolution is the millisecond, you must realize that every millisecond that passes without a record insert is causing your PK attribute to be wider than necessary. As time marches on, uncaring of your key design, you permanently lose all those unused discreet millisecond values (unless you develop a costly and unwieldy algorithm to freeze the clock when the system is idle--in which case it ceases to be based on time, and becomes more like...an autonumbered Identity!). Furthermore, what if two clients submit simultaneously? Or their clocks are off and create the same values? Or, if the stamp is obtained at the multiprocessor database level (as it should be), what if two inserts straddle the same millisecond? What if a merge or replication contains the same values?

The argument for the UNK is not limited to solitary columns. I've heard arguments for multiple-column foreign keys, and synthetic combinations. As I will explain later, any combination of UNKs will break the system, sooner or later. You may be long gone by the time that happens, blissfully unaware of the chaos you've left in your wake, and not learning from your mistakes. Database merges, unanticipated needs for replication in the future, the removal of fields for privacy purposes or new company policies--any one of these (and more that you could think of ahead of time) can and will break a system that is built on user-meaningful "natural" keys.

And here's the hilarious paradox for UNKers: The more effort you expend to combat these challenges and insure uniqueness across many unforeseen possibilities, and isolation from variable business rules--the less meaningful the key becomes to humans, and the more it looks like system glue working under the covers.

In other words, the better you get at designing your keys to protecting your client/boss' investment, the less they look like UNKs!

(continued...)

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:29:03  Show Profile  Visit quazibubble's Homepage  Reply with Quote
Other drawbacks to "natural keys", aka UNKs:

* Decreased uniqueness "density", equating to increased column width. If UNKs are synthetically derived from multiple fields, they will be unnecessarily long, as they will combine many elements of data that are not particularly unique for their length. The result? You don't get much uniqueness "bang" for your column width "buck". (It should be noted that this is true for multi-column unique constraints as well, but in a fully normalized design, those are not driving any relationships.) Furthermore, any meaningful typical string elements waste alot of capacity by only using the characters 0-9, A-Z, and a-z (plus the odd space and punctuation). Each byte of column width therefore wastes and additional 193 possible values (or 65,474 if you use an nchar or nvarchar in a primary key for some unholy reason). A ten-character UNK using those human-readable characters wastes 71,708,904,873,278,937,061,249 potential discreet values. That's pretty expensive. It's even worse when you concatenate numeric digits into a string UNK (such as the digits from a date/time stamp, birthdate, or SSN): you are wasting 254 possible values per byte. (You do the math on that one.) All of those wasted values simply mean your key must be larger to accommodate enough unique instances of your entity. By comparison, autonumber fields such as SQL Server's Identity (however flawed in concept and limited to 4,294,967,296 unique values it may be), still gives you the most uniqueness bang for the column width buck. It is literally impossible to do better: the field is unique to the smallest possible resolution of a binary computer: the bit position. (Don't mistake that simple mathematical fact as my advocacy of the Identity column.)

* UNK advocates may argue that you can perform a hash on a synthetic UNK. This would make it more efficient by increasing the resolution per column width, but invalidates the primary reasons for an UNK in the first place: meaningful, "natural" human readable keys. Hashes cannot be reversed. Furthermore, as you shrink the resulting hash relative to the original string size, you increase the odds of getting duplicates (anywhere between "highly unlikely" and "mathematical certainty").

* Let's not even discuss multi-column UNKs in too much detail. Anyone advocating this has obviously never tried to maintain or enhance a system built with multi-column foreign keys created by some newbie Access programmer. A multi-column key, by definition, would have to contain every attribute that makes the entity unique, which is god-awfully expensive on join performance, I/O, and application maintenance. It makes an application virtually impossible to extend, alter, or enhance. Fortunately we don't have to do this for the sake of uniqueness. Entities can and must have their uniqueness defined by constraints (if you are not using secondary unique constraints that don't involve the PK, and don't involve more than one column on child entities, your design is broken).

(continued...)

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:29:59  Show Profile  Visit quazibubble's Homepage  Reply with Quote
* UNKs place relational integrity and the very fabric of your ER design at the mercy of business rules, Dilbert-esque management misdecisions, external regulation, reorgs, name changes, and typos by customer service monkeys. Who would welcome that kind of headache? Why do a handful of people cling to the dogma that this insanity is actually a logical way to operate? All of those artificially created nightmares vanish by simply using a transparent, meaningless, system-generated key whose only purpose is to put the "R" back in your "ER", as originally intended by the RDBMS fathers.

* UNK advocates love to point out how the auto-numbering Identity concept is broken, as if it somehow invalidates normalized design. But it's a straw man argument, and knowing sleight of hand. Don't be fooled. The autonumbering Identity concept has problems, no doubt about it. (Problems such as supporting replication, merging, and a providing a limited number of unique values for a heavy transactional systems.) However, the autonumbering Identity feature is completely independent of the principles of data normalization, which axiomatically insist on using arbitrary, system-generated keys to transparently drive the relational glue behind the scenes. Although highly appropriate in some specific cases, the Identity column is definitely overused as an "easy way out". Despite it's problems, it should be admired for it's perfect "uniqueness density".

* UNK-pundits may argue away the problems of user-entry error, name changes, and cascading updates, by declaring that once an UNK is generated for an entity, it remains static even though the attributes it was originally derived from may change. However convenient, this would again invalidate the purported benefits of an UNK (such as not needing to do joins--a pathetically flawed argument to begin with, which I've already exposed as such in my first two posts).

* UNKs make global localization more difficult. Your coveted "natural key" is stuck in English, for example. Smooth move, ex-lax.

* UNKers operate in fantasy land. They'd like you to think you'll have access to great "natural" fields such as required SSN, DL, etc. But the business often has other plans, and helping you on your UNK quest is generally not part of their agenda. And unfortunately for you, they are the ones giving YOU the requirements, not the other way around.

* Last but not least, or all: do not forget that primary and foreign keys exist for one reason only: to model entity relationships. That's all, there is no other reason. As such, they are simply visible artifacts of the relational model we use--the glue driving ERs. They have no other relevance. Trying to make them relevant is monumentally stupid, unnecessary, and a waste of resources now and in the future.

(continued...)

Go to Top of Page

quazibubble
Starting Member

USA
25 Posts

Posted - 12/16/2002 :  23:30:34  Show Profile  Visit quazibubble's Homepage  Reply with Quote
Now to walk you through the evolution of thought, which I've seen slowly unfold on multiple independent occasions. Most experienced architects have already been down that path of thought and experiment. However, I'll take you on a rapid guided tour. You can tip me later.

First, let's gather some business requirements to build an example around. These are straightforward requirements handed to us by the consulting agency that interviewed many department heads, SMEs, and power users:

* All customers have a Customer ID that we give them when they become a customer. Whether or not this is meaningful to the customer or to us does not matter; it is below the threshold of detail in our requirements. (Translation: You are free to use an UNK.)

* FYI, the basic business model is catalog mail-order shopping.

* We collect phone number, address, height, weight, shoe size, SSN and DL. So that the system is not completely infuriating to low-paid CSRs fielding customer calls, as few fields as possible should be "required".

* To avoid artificially narrowing our market base, we do not assume our customers have a DL, a SSN, a passport, or have even been vaccinated. They may be new illegal immigrants for all we care.

* Although most customers will be prepared with their Customer ID when calling in repeat orders, we do not require them to have it. As long as a CSR can use their intrinsic human fuzzy logic to whittle the correct customer out of a small set of queried results, that is fine. We don't want to force the customer to choose between finding their Customer ID or not getting customer service.

* One person may have more than one customer record--for example, if they have changed companies, live in seasonal homes, etc.

* If a customer cancels and later comes back, they get a new Customer ID. This requirement was given to us by Bob from Account Temps.

(continued...)

Go to Top of Page
Page: of 8 Previous Topic Topic Next Topic  
Previous Page | Next Page
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.23 seconds. Powered By: Snitz Forums 2000