Re: Systematically determine DRI problem(s)
- From: "NickName" <dadada@xxxxxxxx>
- Date: 12 Sep 2005 14:25:25 -0700
Erland,
Homer sometimes nodds. We miscommunicated.
"the original designer probably meant to link them via customer_ID"
was meant to say, this or any other such db is inherited from some one
else.
Don
Erland Sommarskog wrote:
> NickName (dadada@xxxxxxxx) writes:
> > Well, if we have only a few or a dozen tables, it won't require tons
> > of effort to find data problem for the given situation (database), but
> > again, let's say, this db has over 200 tables, checking them by hand
> > would seem to be like doing things like Homo Sappiens, I don't mean to
> > be lazy, so, how would you systematically at least programmatically
> > identify the DRI problems?
>
> I'm afraid that the only answer I give, is the one you don't want to
> hear: do it right from the beginning.
>
> And if you didn't do it right from the beginning, you have a nightmare
> now to sort out. You can of course set up a unique constraint on the
> customer name (just temporarily) and then an FK from accounts to see
> what happens, but since it's likely to fail, it's not that useful. You
> will have to write SELECTs for all relations you want to check.
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@xxxxxxxxxxxxx
>
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
.
- References:
- Systematically determine DRI problem(s)
- From: NickName
- Re: Systematically determine DRI problem(s)
- From: Erland Sommarskog
- Systematically determine DRI problem(s)
- Prev by Date: Re: Systematically determine DRI problem(s)
- Next by Date: Re: Any SELECT Statement Gurus Out There?
- Previous by thread: Re: Systematically determine DRI problem(s)
- Index(es):
Relevant Pages
|
