List:General Discussion« Previous MessageNext Message »
From:metastable Date:November 14 2008 4:02pm
Subject:Re: normalised designs: customer database
View as plain text  
US Data Export wrote:
>> -----Original Message-----
>> From: Martijn Tonies [mailto:m.tonies@stripped]
>> Sent: Friday, November 14, 2008 10:44 AM
>> To: 'mysql'
>> Subject: Re: normalised designs: customer database
>>
>>     
>>>> 3) create the customer table with a FK for people and a FK for
>>>> companies, and decide on the customer type in the application based
>>>>         
>> on
>>     
>>>> the presence of that key
>>>>
>>>>         
>>> [JS] I'm not sure why you need a foreign key. Surely you won't be
>>>       
>> entering
>>     
>>> customers using the MySQL CLI client on a routine basis, so your user
>>> interface could (and should) be responsible for checking the data.
>>>       
>> Ehm, no, if it's possible, put the constraints -on the database- ...
>> Never
>> ever rely on the application alone to enforce data consistency.
>>
>>     
> [JS] I understand your point, but in real life that can lead to a user
> seeing ugly, incomprehensible error messages.
>
> What I do, in many cases, is provide a dropdown whose values are populated
> from a table of possible values. I suppose you could use that same table to
> enforce foreign key constraints as well, but isn't the effect the same?
>
>
>
>
>
>   
In any event, all data and constraints will be checked in the
application, prior to inserting/updating the database.
It would however be nice to have the db error out in case the
application misses something. It's an awful lot of trouble to weed out
badly inserted or updated records in case of mistakes.
On top of that, the application is only under my control until I become
a millionaire and hire a monkey to code it for me.

Stijn
/

/
Thread
normalised designs: customer databasemetastable14 Nov
  • Re: normalised designs: customer databaseMark Goodge14 Nov
    • Re: normalised designs: customer databaseMr. Shawn H. Corey14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
  • RE: normalised designs: customer databaseJerry Schwartz14 Nov
  • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • RE: normalised designs: customer databaseUS Data Export14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
      • Re: normalised designs: customer databasePeter Brawley14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
    • Re: normalised designs: customer databasemetastable15 Nov
      • Re: normalised designs: customer databaseJujitsu Lizard15 Nov
        • Re: normalised designs: customer databasemetastable16 Nov
          • RE: normalised designs: customer databaseJerry Schwartz17 Nov
            • Re: normalised designs: customer databasemetastable17 Nov
  • Re: normalised designs: customer databaseBill newton14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
    • RE: normalised designs: customer databaseUS Data Export17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov