On Tue, 9 Jan 2007 09:13:35 -0600
"Aaron Bono" <[EMAIL PROTECTED]> wrote:
> On 1/9/07, D'Arcy J.M. Cain wrote:
> >company <===> address <===> detail
>
> This approach implies that the address defines the relationship between a
> company and the detail (the other departments/offices). I can
On 1/9/07, D'Arcy J.M. Cain wrote:
On Mon, 8 Jan 2007 17:07:56 -0600
Curtis Scheer <[EMAIL PROTECTED]> wrote:
> -> Is there a difference between an address for the customer detail and
an
> address for the customer?
>
> Not really an address is an address, it's a matter of specify an address
for
On Mon, 8 Jan 2007 17:07:56 -0600
Curtis Scheer <[EMAIL PROTECTED]> wrote:
> -> Is there a difference between an address for the customer detail and an
> address for the customer?
>
> Not really an address is an address, it's a matter of specify an address for
> the customer master record which b
[mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 4:43 PM
To: pgsql-sql@postgresql.org
Subject: Fwd: [SQL] Table relationships
-- Forwarded message --
From: Aaron Bono <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
Date: Jan 8, 2007 4:42 PM
Subject: Re:
-- Forwarded message --
From: Aaron Bono <[EMAIL PROTECTED]>
Date: Jan 8, 2007 4:42 PM
Subject: Re: [SQL] Table relationships
To: Curtis Scheer <[EMAIL PROTECTED]>
On 1/8/07, Curtis Scheer <[EMAIL PROTECTED]> wrote:
I'm having trouble determining the be
I'm having trouble determining the best way to implement the following
scenario for a customer database.
Given the following tables what is the best way to link an address table to
both the "Master" and the "Detail" tables. Basically there can be many
addresses for each customermaster record an
Thanks for the help.
From: Aaron Bono
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006
2:44 PM
To: A. Kretschmer
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] Table
Relationships
On 10/31/06, A. Kretschmer
<[EMAIL PROTECTED]>
wrote:
am Tu
On 10/31/06, A. Kretschmer <[EMAIL PROTECTED]> wrote:
am Tue, dem 31.10.2006, um 21:08:24 +0100 mailte A. Kretschmer folgendes:> am Tue, dem 31.10.2006, um 13:32:59 -0600 mailte Aaron Bono folgendes:> > I would go further by adding a type table like this:
> >> > operation_type (> > operation_
am Tue, dem 31.10.2006, um 21:08:24 +0100 mailte A. Kretschmer folgendes:
> am Tue, dem 31.10.2006, um 13:32:59 -0600 mailte Aaron Bono folgendes:
> > I would go further by adding a type table like this:
> >
> > operation_type (
> > operation_type_id bigserial (PK),
>
> You are sure, that y
am Tue, dem 31.10.2006, um 13:32:59 -0600 mailte Aaron Bono folgendes:
> I would go further by adding a type table like this:
>
> operation_type (
> operation_type_id bigserial (PK),
You are sure, that you need bigserial?
> This gives you the flexibility to add more operation types in the
On 10/31/06, A. Kretschmer <[EMAIL PROTECTED]> wrote:
am Tue, dem 31.10.2006, um 11:15:26 -0600 mailte Curtis Scheer folgendes:> Given the following two tables:>> CREATE TABLE public.task> (> taskid int4 NOT NULL DEFAULT nextval('task_taskid_seq'::regclass),
> description varchar,> CONSTRAIN
am Tue, dem 31.10.2006, um 11:15:26 -0600 mailte Curtis Scheer folgendes:
> Given the following two tables:
>
> CREATE TABLE public.task
> (
> taskid int4 NOT NULL DEFAULT nextval('task_taskid_seq'::regclass),
> description varchar,
> CONSTRAINT pk_taskid PRIMARY KEY (taskid)
> )
>
> publi
Given the following two tables:
CREATE TABLE public.task
(
taskid int4 NOT NULL DEFAULT
nextval('task_taskid_seq'::regclass),
description varchar,
CONSTRAINT pk_taskid PRIMARY KEY (taskid)
)
public.users
(
userid int4 NOT NULL,
username varchar,
CONSTRAINT pk_us
13 matches
Mail list logo
