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 in the
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
Hi,
Suppose a simple query:
SELECT
client_name as name
FROM
clients
WHERE
client_id = $client_id
Using JDBC 5.0.8 it returns column name as name, that it's the
expected for me.
Using JDBC 5.1.7 it returns column name as client_name, although I
have asked for an alias.
Is it
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
19 matches
Mail list logo
