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
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 ri
> >> 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
>>
>>
3) create the customer table with a FK for people and a FK for
>-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
> > 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 an external service.
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
19 matches
Mail list logo
