Re: Database design question - Isolated, unrelated tables
From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 25 Jun 2007 22:46:07 GMT
Message-ID: <PAXfi.62439$1i1.17841_at_pd7urf3no>
>> Erland Sommarskog wrote:
>>
>>> (nyathancha_at_hotmail.com) writes:
>>>
>>>> I have a question regarding best practices in database design. In a
>>>> relational database, is it wise/necessary to sometimes create tables
>>>> that are not related to other tables through a foreign Key
>>>> relationship or does this always indicate some sort of underlying
>>>> design flaw. Something that requires a re evaluation of the problem
>>>> domain?
>>>
>>>
>>> ...
>>> In the end what matters a lot is how this data is going to be used. ...
>>
>>
>>
>> Good point. (Also, WHETHER it is ever going to be used. Once or
>> twice I've had the strongest feeling possible that such an "audit
>> trail" requirement wasn't thought out and then saw its sponsors
>> quickly retreat when it turned out to be not only inoperable, but
>> unused! The "requirements" I remember were sort of an equivalent to
>> an non-computerized system where somebody decides to hire one auditor
>> for every employee, including the auditors.) Don't know much about
>> temporal db, so I won't mention that possibility and i'll just shut up
>> for now.
>>
>> p
Date: Mon, 25 Jun 2007 22:46:07 GMT
Message-ID: <PAXfi.62439$1i1.17841_at_pd7urf3no>
paul c wrote:
> paul c wrote: >
>> Erland Sommarskog wrote:
>>
>>> (nyathancha_at_hotmail.com) writes:
>>>
>>>> I have a question regarding best practices in database design. In a
>>>> relational database, is it wise/necessary to sometimes create tables
>>>> that are not related to other tables through a foreign Key
>>>> relationship or does this always indicate some sort of underlying
>>>> design flaw. Something that requires a re evaluation of the problem
>>>> domain?
>>>
>>>
>>> ...
>>> In the end what matters a lot is how this data is going to be used. ...
>>
>>
>>
>> Good point. (Also, WHETHER it is ever going to be used. Once or
>> twice I've had the strongest feeling possible that such an "audit
>> trail" requirement wasn't thought out and then saw its sponsors
>> quickly retreat when it turned out to be not only inoperable, but
>> unused! The "requirements" I remember were sort of an equivalent to
>> an non-computerized system where somebody decides to hire one auditor
>> for every employee, including the auditors.) Don't know much about
>> temporal db, so I won't mention that possibility and i'll just shut up
>> for now.
>>
>> p
> > > forgot to mention that one answer to a supposed blanket requirement for > a complete audit trail is to offer to send all db logs to the audit > department! (if the transaction theorists were on top of their game, > they'd realize that such would include userids'.) > > p
oh, sorry, i forgot that i'd said i would shut up. truly, that was all i wanted to say about application audit trails.
p Received on Tue Jun 26 2007 - 00:46:07 CEST