design help

I want to keep track of products , its inventory and any faults to the
products.. Can someone provide a broad design for this ? As far as table
names and their relationship to other tables. Doesnt have to be detailed and
does not have to include data types,etc.. Thanks
It really depends on what you want to do, how much data your need to =
capture, and how you want to use the data. =20
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
--=20
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =
news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as =
table
> names and their relationship to other tables. Doesnt have to be =
detailed and
> does not have to include data types,etc.. Thanks
>=20
>
|||Does that mean the relation between product and inventory or product and
defect might be a one to one relation
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
It really depends on what you want to do, how much data your need to
capture, and how you want to use the data.
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as table
> names and their relationship to other tables. Doesnt have to be detailed
and
> does not have to include data types,etc.. Thanks
>
|||Yes, product and inventory would be related on ProductID. Since there =
could be multiple inventory checks per day the other PK column could be =
InventoryID OR LogDate could be be part of the PK.
Within the Defect table I am thinking that LogDate and ProductID would =
make up the PK. Then again, LogDate could simply be part of the table =
and another column (identity, for example) could be added the PK. =20
There is not a right or wrong way to do it...you just have to pick a =
method that works for you and meets your business requirements.
--=20
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =
news:uTiZuDlJEHA.3944@.tk2msftngp13.phx.gbl...
> Does that mean the relation between product and inventory or product =
and[vbcol=seagreen]
> defect might be a one to one relation
>=20
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
> It really depends on what you want to do, how much data your need to
> capture, and how you want to use the data.
>=20
> It would seem that these are the bare minimum:
> Product table
> ProductID
> ProductName varchar
>=20
> Inventory table
> InventoryID
> ProductID
> LogDate
> InventoryQty
>=20
> Defect table
> ProductID
> LogDate
> DefectCode
> Explanation
>=20
>=20
> --=20
> Keith
>=20
>=20
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
the[vbcol=seagreen]
table[vbcol=seagreen]
detailed
> and
>=20
>

design help

I want to keep track of products , its inventory and any faults to the
products.. Can someone provide a broad design for this ? As far as table
names and their relationship to other tables. Doesnt have to be detailed and
does not have to include data types,etc.. ThanksIt really depends on what you want to do, how much data your need to =
capture, and how you want to use the data. =20
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
--=20
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =
news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as =
table
> names and their relationship to other tables. Doesnt have to be =
detailed and
> does not have to include data types,etc.. Thanks
>=20
>|||Does that mean the relation between product and inventory or product and
defect might be a one to one relation
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
It really depends on what you want to do, how much data your need to
capture, and how you want to use the data.
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as table
> names and their relationship to other tables. Doesnt have to be detailed
and
> does not have to include data types,etc.. Thanks
>|||Yes, product and inventory would be related on ProductID. Since there =
could be multiple inventory checks per day the other PK column could be =
InventoryID OR LogDate could be be part of the PK.
Within the Defect table I am thinking that LogDate and ProductID would =
make up the PK. Then again, LogDate could simply be part of the table =
and another column (identity, for example) could be added the PK. =20
There is not a right or wrong way to do it...you just have to pick a =
method that works for you and meets your business requirements.
--=20
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =
news:uTiZuDlJEHA.3944@.tk2msftngp13.phx.gbl...
> Does that mean the relation between product and inventory or product =
and
> defect might be a one to one relation
>=20
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
> It really depends on what you want to do, how much data your need to
> capture, and how you want to use the data.
>=20
> It would seem that these are the bare minimum:
> Product table
> ProductID
> ProductName varchar
>=20
> Inventory table
> InventoryID
> ProductID
> LogDate
> InventoryQty
>=20
> Defect table
> ProductID
> LogDate
> DefectCode
> Explanation
>=20
>=20
> --=20
> Keith
>=20
>=20
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
the[vbcol=seagreen]
table[vbcol=seagreen]
detailed[vbcol=seagreen]
> and
>=20
>

design help

I want to keep track of products , its inventory and any faults to the
products.. Can someone provide a broad design for this ? As far as table
names and their relationship to other tables. Doesnt have to be detailed and
does not have to include data types,etc.. ThanksIt really depends on what you want to do, how much data your need to =capture, and how you want to use the data.
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
-- Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as =table
> names and their relationship to other tables. Doesnt have to be =detailed and
> does not have to include data types,etc.. Thanks
> >|||Does that mean the relation between product and inventory or product and
defect might be a one to one relation
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
It really depends on what you want to do, how much data your need to
capture, and how you want to use the data.
It would seem that these are the bare minimum:
Product table
ProductID
ProductName varchar
Inventory table
InventoryID
ProductID
LogDate
InventoryQty
Defect table
ProductID
LogDate
DefectCode
Explanation
Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> I want to keep track of products , its inventory and any faults to the
> products.. Can someone provide a broad design for this ? As far as table
> names and their relationship to other tables. Doesnt have to be detailed
and
> does not have to include data types,etc.. Thanks
>|||Yes, product and inventory would be related on ProductID. Since there =could be multiple inventory checks per day the other PK column could be =InventoryID OR LogDate could be be part of the PK.
Within the Defect table I am thinking that LogDate and ProductID would =make up the PK. Then again, LogDate could simply be part of the table =and another column (identity, for example) could be added the PK.
There is not a right or wrong way to do it...you just have to pick a =method that works for you and meets your business requirements.
-- Keith
"Hassan" <fatima_ja@.hotmail.com> wrote in message =news:uTiZuDlJEHA.3944@.tk2msftngp13.phx.gbl...
> Does that mean the relation between product and inventory or product =and
> defect might be a one to one relation
> > "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:ugJKpikJEHA.2660@.TK2MSFTNGP09.phx.gbl...
> It really depends on what you want to do, how much data your need to
> capture, and how you want to use the data.
> > It would seem that these are the bare minimum:
> Product table
> ProductID
> ProductName varchar
> > Inventory table
> InventoryID
> ProductID
> LogDate
> InventoryQty
> > Defect table
> ProductID
> LogDate
> DefectCode
> Explanation
> > > -- > Keith
> > > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:uwfz3XkJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> > I want to keep track of products , its inventory and any faults to =the
> > products.. Can someone provide a broad design for this ? As far as =table
> > names and their relationship to other tables. Doesnt have to be =detailed
> and
> > does not have to include data types,etc.. Thanks
> >
> >
> >

Design

Hello all,

I am trying to correctly model the relationship between products and
versions within my db. The problem I have is how to store the version
data. I need to collect the following information:
1) Major Build Number (int)
2) Minor Build Number (int)
3) Build Number (int)
4) SP number (int)

What is the "correct" schema for this? How many tables and what
columns?

(On a side note if any one has any links to useful examples of DB
design could they post them?)

Thanks,
JoseHi

The way you design your tables will depend to some extend on if you want to
do with them. If you will need the query the constituent parts, then holding
them separately is an option. If you don't then you may want to hold it as a
single string. You may want to be more exact with your datatypes. Tinyint
may be sufficient for your purposes and smallint almost certainly will.

You may want to check out the chapter on Database Design Considerations in
Books online.

John

"Jose Perez" <jlpv@.totalise.co.uk> wrote in message
news:3724a9d9.0412280740.4bfe3dfa@.posting.google.c om...
> Hello all,
> I am trying to correctly model the relationship between products and
> versions within my db. The problem I have is how to store the version
> data. I need to collect the following information:
> 1) Major Build Number (int)
> 2) Minor Build Number (int)
> 3) Build Number (int)
> 4) SP number (int)
> What is the "correct" schema for this? How many tables and what
> columns?
> (On a side note if any one has any links to useful examples of DB
> design could they post them?)
> Thanks,
> Jose