Table Structure Advice

Поиск
Список
Период
Сортировка
От
Тема Table Structure Advice
Дата
Msg-id 20051213231005.66653.qmail@web33304.mail.mud.yahoo.com
обсуждение исходный текст
Ответы Re: Table Structure Advice  (<operationsengineer1@yahoo.com>)
Список pgsql-novice
this is a tough day...

i have two sets of related information...

contract numbers and job numbers.

typically a job number will relate to either a
contract or a parent job number.  i'll get to an
atypical situation in a bit - which complicates the
issue even more.

think along the lines of...

contract 1
-job 1
-job 2
--job 10
--job 11
---job 20
-job 4

job 20 roll up under job 11, job 10,11 roll up under
job 2, etc.

my current line of thinking tells me to lay out my
table t_job_number similar to the following:

t_job_number
job_number_id
fkey_contract_id
fkey_job_number_id
etc...

i would then just leave one of the two blank after
filling in the other with the appropriate value in the
appropriate column.

i would then use my queries and php to manipulate the
data.

however, i'm feeling a bit uneasy that this might not
be the optimal solution.

i definitely appreciate any input as to whether this
is the best there is or if i'm out to lunch on my
table design.

to complicate matters further, not only can multiple
job numbers be use per contract (customer orders
multiple items to create their "setup"), but multiple
contracts can be associated with a job number.  for
example, 10 widgets are "built to stock" as part of
job 1 and assigned to the special "build to stock"
contract id.

at some future point, 6 of job 1's widgets get
assigned to contract 1 and 4 of job 1's widgets may
get assigned to contract 5.  iow, i have the same job
number associated with two different contracts - 1 and
5.

this business rule because i only have one job number
entry and then link each serial number to its
appropriate job number.

off the top of my head, i'm thinking i might be able
to "split" a job number (create a second job number
with the same number) if this special case occurs, but
that sounds very ugly with a high likelihood of traps
down the road.

i guess i could store the actual job number in the
serial number table...  or denormalize (eliminate the
job number table and just store the job number for
each individual serial number in the serial number
table).

i'm not very happy with anything i've been able to
develop based on the current business rules.

as the learning curve ramps up...

again, any advice is appreciated.

tia...

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

В списке pgsql-novice по дате отправления:

Предыдущее
От: Daniel Hertz
Дата:
Сообщение: Multi-row update w. plpgsql
Следующее
От:
Дата:
Сообщение: Re: Table Structure Advice