One real-world example:
RBOC changes an area code for certain prefixes.
If you haven't decomposed the phone number into separate fields,
e.g. your phone number is a single field ala
"<country code>-<area code>-<local number>" you have a really
interesting job ahead of you to accomplish the update.
Especially if you are a telecom provider and your rates vary
by the NPA-NXX (area code-prefix). The "area code-prefix" are
foreign keys into your rate tables.
\\|//
(@ @)
-------oOO---(_)---OOo--------
| |
| Fred Dinkler |
| SVP Technology |
| DFII Atlanta |
| Office: 01.770.596.1443 |
| |
------------------------------
|__|__|
|| ||
ooO Ooo
-----Original Message-----
From: Ken Sommers [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 11:58 PM
To: Michael Bacarella; pak
Cc: [EMAIL PROTECTED]
Subject: Re: Referential Integrity
Please give some examples of 'bad' design where a "foreign key" would have
to be changed..
ken
----- Original Message -----
From: "Michael Bacarella" <[EMAIL PROTECTED]>
To: "pak" <[EMAIL PROTECTED]>
Cc: "Ken Sommers" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 8:53 PM
Subject: Re: Referential Integrity
> On Wed, Jul 11, 2001 at 01:31:15PM +1000, pak wrote:
>
> > So is MySQL not suitable for large corporate database ?
>
> That depends more on what you feel is suitable, rather than
> someone else trying to tell you objectively what is suitable.
>
> You can argue for and against the use of foreign keys and both
> sides are pretty convincing. The deciding factor is ultimately
> what you will be comfortable with.
>
> My story:
>
> With properly designed applications and tables, I do not feel
> at a disadvantage without foreign keys-- and I'm glad to be able
> to squeeze every ounce of performance possible from our systems
> (since they're taxed quite heavily).
>
> On systems that I've designed that are terrible, I wish I had
> referential integrity. :)
>
> This is not to say that I wouldn't mind the feature, but it's
> absolutely not stopping me from enjoying MySQL.
>
> -MB
>
> > | If the user is entering what is supposed to be a primary key value,
> > | make sure it is a valid key before sticking it in any where, If it's a
> > bogus
> > | key .tell the user to try again.
> > |
> > | If user wants you to delete rows from a primary table (customer)that
have
> > | "foreign keys"( cust ID in Orders)that are still pointing to
> > | something.(related table)..tell the user that this customer still has
> > | orders( yes you'll have to check yourself),,and deleting all those
orders
> > | would make the accountants and IRS really mad. and you can;t delete
the
> > | customer without deleting all the orders,,and tell them further more
> > ,,that
> > | deleting primary keys is bad practice anyway..should just set the
active
> > | flag to "NO"..cuz you still want all the history involved with that
> > customer
> > | around.. and further more,..IF a few years down the line that customer
has
> > | been inactive for a buncha years kill him or her then. and all the
related
> > | orders .but only after the history files have been summarized and
tucked
> > | away.
> > |
> > | User wants to change a primary key value,,just don't do it..:) too
much
> > | work..OR tell 'em it will cost 'em.
> > |
> > | have fun,
> > | Ken
>
> > | ----- Original Message -----
> > | From: "pak" <[EMAIL PROTECTED]>
> > | To: <[EMAIL PROTECTED]>
> > | Sent: Tuesday, July 10, 2001 7:17 PM
> > | Subject: Referential Integrity
>
> > | > MySQL does not support RI, anyone has good suggestion that do this
in
> > the
> > | > program ?
> > | > As this would be a nightmare if I have 50 detail tables to update
> > | > programmatically.
>
> --
> Michael Bacarella <[EMAIL PROTECTED]>
> Technical Staff / System Development,
> New York Connect.Net, Ltd.
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
