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 databases. I
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
private, it
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:
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 enums, but sets are evil.
Martijn Tonies
Database Workbench Lite for MySQL - FREE developer tool for
-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, and
aren't
concerned with cascading operations
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 enums, but sets are evil.
[JS] Why is that? I've been using sets, but I could use enums. Set
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.
Farmington, CT
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 (companies, people,
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/Variant_record
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 table
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
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
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 50%
-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 an external service. I
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 column
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,
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 company
3)
-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
companies, and decide on the customer type
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
3) create the customer table with a FK for people and a FK for
companies, and decide
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 requirements.
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
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 of a problem than
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 customer table
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 O-O
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 databases. I
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
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
database
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 the same sort of
28 matches
Mail list logo
