Jerry Schwartz wrote:
> If all you want to do is to restrict a field to certain values, and aren't
> concerned with cascading operations, is a set more efficient than a foreign
> key?
>
> Regards,
>
> Jerry Schwartz
> The Infoshop by Global Information Incorporated
> 195 Farmington Ave.
> Farming
> >> If all you want to do is to restrict a field to certain values, and
> >aren't
> >> concerned with cascading operations, is a set more efficient than a
> >foreign
> >> key?
> >
> >A Set or Enum?
> >
> >I can understand "enum"s, but sets are evil.
> >
> [JS] Why is that? I've been using sets, b
>-Original Message-
>From: Martijn Tonies [mailto:[EMAIL PROTECTED]
>Sent: Monday, November 17, 2008 12:13 PM
>To: 'mysql'
>Subject: Re: normalised designs: customer database
>
>
>
>> If all you want to do is to restrict a field to certain values,
> If all you want to do is to restrict a field to certain values, and aren't
> concerned with cascading operations, is a set more efficient than a
foreign
> key?
A Set or Enum?
I can understand "enum"s, but sets are evil.
Martijn Tonies
Database Workbench Lite for MySQL - FREE developer tool f
If all you want to do is to restrict a field to certain values, and aren't
concerned with cascading operations, is a set more efficient than a foreign
key?
Regards,
Jerry Schwartz
The Infoshop by Global Information Incorporated
195 Farmington Ave.
Farmington, CT 06032
860.674.8796 / FAX: 860.6
> >> I may just have had an insight over my morning coffee.
> >> How about turning things around and adding a FK -to the customers
table-
> >> on each of the customer type tables (companies, people, charities, etc)
?
> >>
> >> The customers table would have no idea if a customer is corporate or
>
>>> >The notion of a "variant record" exists in many programming languages.
>>> >Typically you have a selector to indicate which variant it is. There
is
>>> >nothing at all wrong with using the same sort of construct in a
database
>>> >table.
>>> >http://en.wikipedia.org/wiki/Variant_record
>
Jujitsu Lizard wrote:
> On Sat, Nov 15, 2008 at 3:54 AM, metastable <[EMAIL PROTECTED]
>
>> wrote:
>>
>
>
>
>> I may just have had an insight over my morning coffee.
>> How about turning things around and adding a FK -to the customers table-
>> on each of the customer type tables (compan
On Sat, Nov 15, 2008 at 3:54 AM, metastable <[EMAIL PROTECTED]
> wrote:
> I may just have had an insight over my morning coffee.
> How about turning things around and adding a FK -to the customers table-
> on each of the customer type tables (companies, people, charities, etc) ?
>
> The customers
Martijn Tonies wrote:
>> >The notion of a "variant record" exists in many programming languages.
>> >Typically you have a selector to indicate which variant it is. There is
>> >nothing at all wrong with using the same sort of construct in a database
>> >table.
>> >http://en.wikipedia.org/wiki/
Jujitsu Lizard wrote:
> On Fri, Nov 14, 2008 at 1:39 PM, Martijn Tonies <[EMAIL PROTECTED]>wrote:
>
>
>>> >The notion of a "variant record" exists in many programming languages.
>>> >Typically you have a selector to indicate which variant it is. There is
>>> >nothing at all wrong with using t
On Fri, Nov 14, 2008 at 1:39 PM, Martijn Tonies <[EMAIL PROTECTED]>wrote:
> > >The notion of a "variant record" exists in many programming languages.
> > >Typically you have a selector to indicate which variant it is. There is
> > >nothing at all wrong with using the same sort of construct in a
Hi everybody,
What about simply storing a main user for each company? So each company
has a main user that has the basics about the company ( generic address,
email, phone). I would think you'd want to store that information
anyways. So the customer table always links to a user. That user cou
> >The notion of a "variant record" exists in many programming languages.
> >Typically you have a selector to indicate which variant it is. There is
> >nothing at all wrong with using the same sort of construct in a database
> >table.
> >http://en.wikipedia.org/wiki/Variant_record
>
> In O-O d
Jujitsu Lizard wrote:
>The notion of a "variant record" exists in many programming languages.
>Typically you have a selector to indicate which variant it is. There is
>nothing at all wrong with using the same sort of construct in a database
>table.
>http://en.wikipedia.org/wiki/Variant_record
In
On Fri, Nov 14, 2008 at 10:45 AM, Martijn Tonies <[EMAIL PROTECTED]>wrote:
>
> > > This is where it gets nasty. A customer may be a human being or a
> > > company. I see different approaches here:
> > > 1) keep customer tables separate, based on which type of customer it is
> > > 2) create the cus
> >> I wouldn't try to arbitrarily normalise the database for SQL
> >> efficiency.
> >> In a real-life situation, it's more important that the database
> >> design
> >> reflects your actual workflow and business requirements. Having a
> >> field
> >> that's empty 50% or more of the time is far less
> 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
> >>>
> >> ente
Mr. Shawn H. Corey wrote:
> On Fri, 2008-11-14 at 14:30 +, Mark Goodge wrote:
>
>> I wouldn't try to arbitrarily normalise the database for SQL
>> efficiency.
>> In a real-life situation, it's more important that the database
>> design
>> reflects your actual workflow and business requirem
US Data Export wrote:
>> -Original Message-
>> From: Martijn Tonies [mailto:[EMAIL PROTECTED]
>> Sent: Friday, November 14, 2008 10:44 AM
>> To: 'mysql'
>> Subject: Re: normalised designs: customer database
>>
>>
>>>>
>-Original Message-
>From: Martijn Tonies [mailto:[EMAIL PROTECTED]
>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
>>
> > This is where it gets nasty. A customer may be a human being or a
> > company. I see different approaches here:
> > 1) keep customer tables separate, based on which type of customer it is
> > 2) create the customer table with a column specifying if we're dealing
> > with a human being or a com
> >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 routin
On Fri, Nov 14, 2008 at 8:49 AM, metastable <[EMAIL PROTECTED]
> wrote:
>
> This is where it gets nasty. A customer may be a human being or a
> company. I see different approaches here:
> 1) keep customer tables separate, based on which type of customer it is
> 2) create the customer table with a
>-Original Message-
>From: metastable [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 14, 2008 8:49 AM
>To: mysql
>Subject: normalised designs: customer database
>
[JS] My first suggestion, and I am entirely sincere, is that you use either
an off the shelf solution or a
On Fri, 2008-11-14 at 14:30 +, Mark Goodge wrote:
> I wouldn't try to arbitrarily normalise the database for SQL
> efficiency.
> In a real-life situation, it's more important that the database
> design
> reflects your actual workflow and business requirements. Having a
> field
> that's empty
metastable wrote:
Hello all,
I have a question that's been bugging me for quite some time.
Let's say we have a small business that has both private and corporate
customers.
We want to store contact and address data about these customers, as well
as invoicing data. Off course, only companies ha
Hello all,
I have a question that's been bugging me for quite some time.
Let's say we have a small business that has both private and corporate
customers.
We want to store contact and address data about these customers, as well
as invoicing data. Off course, only companies have VAT numbers.
When
28 matches
Mail list logo
