Table Structure for Parts and Products...(long)

[brett valjalo]

Hey Gang!

SORRY ABOUT THE LENGTH!

Nice to see some of the same faces around this place from way back
when ... Whatta buncha CDMA addicts some o' y'all are ;)

Don't get me wrong, I understand, believe me! Took me a lot of
therapy, various 12-step programmes, interventions by loved ones, etc,
but I finally managed to excavate, er, extricate myself from the
vicious CDMA cycle - you know, one day at a time :)

Anyways, can anyone point me to a good example of a
'parts/product/inventory' database? A good example of what I need is
something like what one might use to run a "custom-built computer"
store (although my needs are nothing like that, the concept is the
same). A store where an ATI Radeon 9800Pro might be both a
stand-alone, boxed item on the shelf (at one price) OR part of three
different PC pre-built products (in an unboxed version, at a different
price than the boxed version) that I build onsite. Despite the
differences, I would still be able to easily figure out how many
Radeon 9800Pro's I've sold even though there might be multiple SKU's
for it, depending on the different products I use it in.

I think I've heard this referred to as a certain type of DB around
here, I want to say a 'bill of lading' db but I think that's wrong, I
think the term might actually have 'manifest' in the name. Hopefully
you guys (or gals, or somebody) know what I'm talking about here.

So, like, as a 'product' of MINE(the store owner), a 9800Pro might be
at numerous levels of 'building hierarchy' - it can be a stand-alone
piece as Product A, #1 of 3 pieces in Product B, or #4 of 6 pieces in
Product C, and yet still be trackable as a distinct entity when I need
to order new parts or count inventory. And I'd like the composition
of my multi-part products to be reflected somehow in my data/data
structure, so that I could figure out how many Product C's I could
make at a given moment based on whatever is the limiting factor in
terms of what parts I have in stock at that moment.

Oh, and I'd like the structure to allow for indefinite 'complexity' in
terms of product construction hierarchy. What I mean by this, is that
if I suddenly decide I want to not only stock prebuilt Radeon
9800Pro's, but also to grab the individual parts so I could build a
9800Pro MYSELF (and use THAT exactly like it were a prebuilt one-even
though it's actually a product I built on-site). See what I mean by
'indefinite complexity'?
Anybody know where to find a good sample of this type of DB? I'm
CERTAIN that this kinda thing has been constructed many many many
times - like, say, at a auto manafacturing plant. Don't wnat to have
to reinvent the wheel, ya know!?!

TVMIA,
brett

[Mike MacSween]

BOM (Bill of Materials) maybe?

If you do a search for it, possibly combined with (dare I say it) 'Celko'
you'll get plenty results.

It's yer actual classic recursive structure innit? Nested sets, adjacency
list, materialised paths seem to be the 3 techniques. Oh yeah and MV
databases might be another. Somebody here really likes those. I think it's
Albert Kallal.

Sounds complicated. Are you really going to start making video cards
yourself? (If that's what a Radeon Pro is)

Cheers, Mike

"brett valjalo" <bv******@sfhp.org> wrote in message
news:1f*************************@posting.google.co m...

Hey Gang!

SORRY ABOUT THE LENGTH!

Nice to see some of the same faces around this place from way back
when ... Whatta buncha CDMA addicts some o' y'all are ;)

Don't get me wrong, I understand, believe me! Took me a lot of
therapy, various 12-step programmes, interventions by loved ones, etc,
but I finally managed to excavate, er, extricate myself from the
vicious CDMA cycle - you know, one day at a time :)

Anyways, can anyone point me to a good example of a
'parts/product/inventory' database? A good example of what I need is
something like what one might use to run a "custom-built computer"
store (although my needs are nothing like that, the concept is the
same). A store where an ATI Radeon 9800Pro might be both a
stand-alone, boxed item on the shelf (at one price) OR part of three
different PC pre-built products (in an unboxed version, at a different
price than the boxed version) that I build onsite. Despite the
differences, I would still be able to easily figure out how many
Radeon 9800Pro's I've sold even though there might be multiple SKU's
for it, depending on the different products I use it in.

I think I've heard this referred to as a certain type of DB around
here, I want to say a 'bill of lading' db but I think that's wrong, I
think the term might actually have 'manifest' in the name. Hopefully
you guys (or gals, or somebody) know what I'm talking about here.

So, like, as a 'product' of MINE(the store owner), a 9800Pro might be
at numerous levels of 'building hierarchy' - it can be a stand-alone
piece as Product A, #1 of 3 pieces in Product B, or #4 of 6 pieces in
Product C, and yet still be trackable as a distinct entity when I need
to order new parts or count inventory. And I'd like the composition
of my multi-part products to be reflected somehow in my data/data
structure, so that I could figure out how many Product C's I could
make at a given moment based on whatever is the limiting factor in
terms of what parts I have in stock at that moment.

Oh, and I'd like the structure to allow for indefinite 'complexity' in
terms of product construction hierarchy. What I mean by this, is that
if I suddenly decide I want to not only stock prebuilt Radeon
9800Pro's, but also to grab the individual parts so I could build a
9800Pro MYSELF (and use THAT exactly like it were a prebuilt one-even
though it's actually a product I built on-site). See what I mean by
'indefinite complexity'?
Anybody know where to find a good sample of this type of DB? I'm
CERTAIN that this kinda thing has been constructed many many many
times - like, say, at a auto manafacturing plant. Don't wnat to have
to reinvent the wheel, ya know!?!

TVMIA,
brett

[brett valjalo]

Alright, I'll search for ol' Joe then. Should've thought of that,
after all who among us doesn't own "Sql for Smarties", eh?

Recursive Structure, you say? Sounds about right.

Actually, no, video cards have nothing to do with it. In my actual
case, I'm dealing with people not product, but the concept is
basically the same. I guess I might've used the example of a
'complicated personnel org chart', cause that's really a lot closer to
what I need, but I just remember this 'type' of DB being discussed
around here under a certain rubric (still unknown to me) pertaining to
manufacturing/inventory, and I just thought I could look at a
functioning one of those for ideas.

The real scenario is this - I work for a city-funded health plan which
provides coverage to those without the means to pay for it themselves.
Up until recently, we could survive with a data structure wherein
PARENTS went in one table, and their children went in another table,
and the children were our actual members (this program was/is called
"Healthy Kids"), and the parents were the ones with the mailing
address and who provided the necessary financial data to determine
eligibility. We needed totally different data for each, for totally
different uses, in other words.

And this worked fine ... until our new Healthy Young Adults program
came across my desk. NOW, you see (god this is a nightmare because
this is a live system with thousands of members and dozens of
employees using the system everyday, accessing it via both Access
(.adp) and ASP.NET, but oh WELL!) the PARENTS can suddenly occupy the
role of both member AND parent, because under this new program, if the
parents are between 18 and 24, with an eligible 'healthy kid' as
progeny, THEY can now be members of 'Healthy Young Adults', which is
nearly identical, but not quite, whilst their kids are, obviously,
still part of HK. So, under many scenarios, the parents need to be
counted just like their kids (such as for 'counting members'), but in
other cases, they must be handled differently. For example, we need
the financial data for THEM, whereas for a regualar HK member (0-18
y.o.), we get the financials for their Parents to determine
eligibility.

SO, bottom-line, what we have here is a serious wrench thrown in our
'hierarchy', and hence our data structure is no longer really
suitable. I need some ideas on how to make the whole thing a lot more
flexible. I'm sure the first step is to start tracking 'people' as
simply people (via a people table, instead of parent table/children
table) and build out from there. But there is A LOT riding on the
decision we make at this point, and I'm pushing hard to get us in a
situation where this problem COULD NOT happen again, because we have a
data structure that would allow for indefinite complexity (like you
would need if you were a car manufacturer, for example) in terms of
the family structure and who lives where and who's responsible
financially and who is eligible because of whatever relationship they
have with whomever.

See what I'm saying?

Thanks for anyone who can help. You will be helping thousands of
underprivileged 18-24 y.o. people in San Francisco receive possibly
life-saving medical care - if that's any incentive to you to help me
out :)

Peace,
Brett V.

"Mike MacSween" <mi************************@btinternet.com> wrote in message news:<41*********************@news.aaisp.net.uk>.. .

BOM (Bill of Materials) maybe?

If you do a search for it, possibly combined with (dare I say it) 'Celko'
you'll get plenty results.

It's yer actual classic recursive structure innit? Nested sets, adjacency
list, materialised paths seem to be the 3 techniques. Oh yeah and MV
databases might be another. Somebody here really likes those. I think it's
Albert Kallal.

Sounds complicated. Are you really going to start making video cards
yourself? (If that's what a Radeon Pro is)

Cheers, Mike

"brett valjalo" <bv******@sfhp.org> wrote in message
news:1f*************************@posting.google.co m...

Hey Gang!

SORRY ABOUT THE LENGTH!

Nice to see some of the same faces around this place from way back
when ... Whatta buncha CDMA addicts some o' y'all are ;)

Don't get me wrong, I understand, believe me! Took me a lot of
therapy, various 12-step programmes, interventions by loved ones, etc,
but I finally managed to excavate, er, extricate myself from the
vicious CDMA cycle - you know, one day at a time :)

Anyways, can anyone point me to a good example of a
'parts/product/inventory' database? A good example of what I need is
something like what one might use to run a "custom-built computer"
store (although my needs are nothing like that, the concept is the
same). A store where an ATI Radeon 9800Pro might be both a
stand-alone, boxed item on the shelf (at one price) OR part of three
different PC pre-built products (in an unboxed version, at a different
price than the boxed version) that I build onsite. Despite the
differences, I would still be able to easily figure out how many
Radeon 9800Pro's I've sold even though there might be multiple SKU's
for it, depending on the different products I use it in.

I think I've heard this referred to as a certain type of DB around
here, I want to say a 'bill of lading' db but I think that's wrong, I
think the term might actually have 'manifest' in the name. Hopefully
you guys (or gals, or somebody) know what I'm talking about here.

So, like, as a 'product' of MINE(the store owner), a 9800Pro might be
at numerous levels of 'building hierarchy' - it can be a stand-alone
piece as Product A, #1 of 3 pieces in Product B, or #4 of 6 pieces in
Product C, and yet still be trackable as a distinct entity when I need
to order new parts or count inventory. And I'd like the composition
of my multi-part products to be reflected somehow in my data/data
structure, so that I could figure out how many Product C's I could
make at a given moment based on whatever is the limiting factor in
terms of what parts I have in stock at that moment.

Oh, and I'd like the structure to allow for indefinite 'complexity' in
terms of product construction hierarchy. What I mean by this, is that
if I suddenly decide I want to not only stock prebuilt Radeon
9800Pro's, but also to grab the individual parts so I could build a
9800Pro MYSELF (and use THAT exactly like it were a prebuilt one-even
though it's actually a product I built on-site). See what I mean by
'indefinite complexity'?
Anybody know where to find a good sample of this type of DB? I'm
CERTAIN that this kinda thing has been constructed many many many
times - like, say, at a auto manafacturing plant. Don't wnat to have
to reinvent the wheel, ya know!?!

TVMIA,
brett

[brett valjalo]

As an aside, Mike, it's pretty funny: I did the search you suggest,
and what a very odd thing I found... I gave somebody else the exact
same advice you just gave me, a couple of years ago, right here on
this very group! Check it out, if you do the search for BOM and Celko
on google groups, there I am, saying the same damn thing you just told
me! Too friggin funny!

Boy, I gotta lay off the sauce one of these days - the brain cells are
definitely taking a beating!

Did you already know this was the case (meaning you already saw my old
post and you were directing me to it because you thought I'd look it
up and see what a ret*rd I am - which would be something I'd do to
somebody as well ;), or is this just a strange coincidence - you just
happened to direct me to BOM and Celko, just like I did with Rob back
in early 2002?

Hilarious...

peace,
brett
"Mike MacSween" <mi************************@btinternet.com> wrote in message news:<41*********************@news.aaisp.net.uk>.. .

BOM (Bill of Materials) maybe?

If you do a search for it, possibly combined with (dare I say it) 'Celko'
you'll get plenty results.

It's yer actual classic recursive structure innit? Nested sets, adjacency
list, materialised paths seem to be the 3 techniques. Oh yeah and MV
databases might be another. Somebody here really likes those. I think it's
Albert Kallal.

Sounds complicated. Are you really going to start making video cards
yourself? (If that's what a Radeon Pro is)

Cheers, Mike

"brett valjalo" <bv******@sfhp.org> wrote in message
news:1f*************************@posting.google.co m...

Hey Gang!

SORRY ABOUT THE LENGTH!

Nice to see some of the same faces around this place from way back
when ... Whatta buncha CDMA addicts some o' y'all are ;)

Don't get me wrong, I understand, believe me! Took me a lot of
therapy, various 12-step programmes, interventions by loved ones, etc,
but I finally managed to excavate, er, extricate myself from the
vicious CDMA cycle - you know, one day at a time :)

Anyways, can anyone point me to a good example of a
'parts/product/inventory' database? A good example of what I need is
something like what one might use to run a "custom-built computer"
store (although my needs are nothing like that, the concept is the
same). A store where an ATI Radeon 9800Pro might be both a
stand-alone, boxed item on the shelf (at one price) OR part of three
different PC pre-built products (in an unboxed version, at a different
price than the boxed version) that I build onsite. Despite the
differences, I would still be able to easily figure out how many
Radeon 9800Pro's I've sold even though there might be multiple SKU's
for it, depending on the different products I use it in.

I think I've heard this referred to as a certain type of DB around
here, I want to say a 'bill of lading' db but I think that's wrong, I
think the term might actually have 'manifest' in the name. Hopefully
you guys (or gals, or somebody) know what I'm talking about here.

So, like, as a 'product' of MINE(the store owner), a 9800Pro might be
at numerous levels of 'building hierarchy' - it can be a stand-alone
piece as Product A, #1 of 3 pieces in Product B, or #4 of 6 pieces in
Product C, and yet still be trackable as a distinct entity when I need
to order new parts or count inventory. And I'd like the composition
of my multi-part products to be reflected somehow in my data/data
structure, so that I could figure out how many Product C's I could
make at a given moment based on whatever is the limiting factor in
terms of what parts I have in stock at that moment.

Oh, and I'd like the structure to allow for indefinite 'complexity' in
terms of product construction hierarchy. What I mean by this, is that
if I suddenly decide I want to not only stock prebuilt Radeon
9800Pro's, but also to grab the individual parts so I could build a
9800Pro MYSELF (and use THAT exactly like it were a prebuilt one-even
though it's actually a product I built on-site). See what I mean by
'indefinite complexity'?
Anybody know where to find a good sample of this type of DB? I'm
CERTAIN that this kinda thing has been constructed many many many
times - like, say, at a auto manafacturing plant. Don't wnat to have
to reinvent the wheel, ya know!?!

TVMIA,
brett

[brett valjalo]

As an aside, Mike, it's pretty funny: I did the search you suggest,
and what a very odd thing I found... I gave somebody else the exact
same advice you just gave me, a couple of years ago, right here on
this very group! Check it out, if you do the search for BOM and Celko
on google groups, there I am, saying the same damn thing you just told
me! Too friggin funny!

Boy, I gotta lay off the sauce one of these days - the brain cells are
definitely taking a beating!

Did you already know this was the case (meaning you already saw my old
post and you were directing me to it because you thought I'd look it
up and see what a ret*rd I am - which would be something I'd do to
somebody as well ;), or is this just a strange coincidence - you just
happened to direct me to BOM and Celko, just like I did with Rob back
in early 2002?

Hilarious...

peace,
brett
"Mike MacSween" <mi************************@btinternet.com> wrote in message news:<41*********************@news.aaisp.net.uk>.. .

BOM (Bill of Materials) maybe?

If you do a search for it, possibly combined with (dare I say it) 'Celko'
you'll get plenty results.

It's yer actual classic recursive structure innit? Nested sets, adjacency
list, materialised paths seem to be the 3 techniques. Oh yeah and MV
databases might be another. Somebody here really likes those. I think it's
Albert Kallal.

Sounds complicated. Are you really going to start making video cards
yourself? (If that's what a Radeon Pro is)

Cheers, Mike

"brett valjalo" <bv******@sfhp.org> wrote in message
news:1f*************************@posting.google.co m...

Hey Gang!

SORRY ABOUT THE LENGTH!

Nice to see some of the same faces around this place from way back
when ... Whatta buncha CDMA addicts some o' y'all are ;)

Don't get me wrong, I understand, believe me! Took me a lot of
therapy, various 12-step programmes, interventions by loved ones, etc,
but I finally managed to excavate, er, extricate myself from the
vicious CDMA cycle - you know, one day at a time :)

Anyways, can anyone point me to a good example of a
'parts/product/inventory' database? A good example of what I need is
something like what one might use to run a "custom-built computer"
store (although my needs are nothing like that, the concept is the
same). A store where an ATI Radeon 9800Pro might be both a
stand-alone, boxed item on the shelf (at one price) OR part of three
different PC pre-built products (in an unboxed version, at a different
price than the boxed version) that I build onsite. Despite the
differences, I would still be able to easily figure out how many
Radeon 9800Pro's I've sold even though there might be multiple SKU's
for it, depending on the different products I use it in.

I think I've heard this referred to as a certain type of DB around
here, I want to say a 'bill of lading' db but I think that's wrong, I
think the term might actually have 'manifest' in the name. Hopefully
you guys (or gals, or somebody) know what I'm talking about here.

So, like, as a 'product' of MINE(the store owner), a 9800Pro might be
at numerous levels of 'building hierarchy' - it can be a stand-alone
piece as Product A, #1 of 3 pieces in Product B, or #4 of 6 pieces in
Product C, and yet still be trackable as a distinct entity when I need
to order new parts or count inventory. And I'd like the composition
of my multi-part products to be reflected somehow in my data/data
structure, so that I could figure out how many Product C's I could
make at a given moment based on whatever is the limiting factor in
terms of what parts I have in stock at that moment.

Oh, and I'd like the structure to allow for indefinite 'complexity' in
terms of product construction hierarchy. What I mean by this, is that
if I suddenly decide I want to not only stock prebuilt Radeon
9800Pro's, but also to grab the individual parts so I could build a
9800Pro MYSELF (and use THAT exactly like it were a prebuilt one-even
though it's actually a product I built on-site). See what I mean by
'indefinite complexity'?
Anybody know where to find a good sample of this type of DB? I'm
CERTAIN that this kinda thing has been constructed many many many
times - like, say, at a auto manafacturing plant. Don't wnat to have
to reinvent the wheel, ya know!?!

TVMIA,
brett

[--CELKO--]

>> Alright, I'll search for ol' Joe then. Should've thought of that,
after all who among us doesn't own "SQL for Smarties", eh? <<
Actually get a copy of TREES & HIERARCHIES IN SQL, which came out in
April 2004. It has a lot of details.