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
5  1873 
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
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
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
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
>> 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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: toedipper |
last post by:
Hello,
I am designing a table of vehicle types, nothing special, just a list of
unique vehicle types such as truck, lorry, bike, motor bike, plane, tractor
etc etc
For the table design I am...
|
by: serge |
last post by:
I have a scenario where two tables are in a One-to-Many relationship
and I need to move the data from the Many table to the One table so
that it becomes a One-to-One relationship.
I need to...
|
by: Detroit_Dan |
last post by:
Howdy all,
I am having trouble deciding on table strategies. My last dB project
was 1994ish in 1-2-3...
My goal is a database which will keep track of equipment in the field,
and provide...
|
by: ChadDiesel |
last post by:
Hello everyone. I need some advice on table structure for a new project
I've been given.
One of our customers sends us an Excel spreadsheet each week containing
their order. Currently, someone...
|
by: Shannan Casteel via AccessMonster.com |
last post by:
I set up two tables (one with the regular claim
info and another with ClaimNumber, PartNumber, and QuantityReplaced). The
ClaimNumber is an autonumber and the primary key in both tables. I made a...
|
by: eskil |
last post by:
Hi,
I want to link products and contacts, products and axctivities and
activities and contacts. I am using one to many links with full
referential integrity. Each table is linked to a table that...
|
by: The Frog |
last post by:
Hello Everyone,
I have been asked to try and create a single SQL query to retrieve
product information from a database. The way that data is arranged is
that in some tables there are user...
|
by: Khafancoder |
last post by:
Hi guys,
in my db i have these three tables
1.Stores 2.Products 3.Parts
their structure is something like :
Stores ----Products ----Parts
|
by: jeddiki |
last post by:
What could be the reason for this failure to insert a row ?
Here is my insert code:
$sql = "INSERT INTO `products` (live,cat_cd,long,user_id,prod_name,prod_desc_sht,prod_desc_lng)
VALUES ...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
