Re: Database Structuring (again)

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 49806
interpreted = N
texte = My tendency would be to add a single options.db that could handle multiple types of options and indicate whether or not the option carried an additional charge. Something with fields like these:optSKU - the SKU for the product in questionoptClass - the classification of the option - size, color, length, etcoptValue - the internal representation of an option's value (blue, red, green; 8, 8.5, 9)optLabel - how to display the option in a menu for the user (Navy Blue, Red, Forest Green; 8, 8 1/2, 9)optCost - additional charge for this option (maybe it costs more in XXL than M)Now you when you display the order form for a given product, you can search the options.db by optSKU, and build menus for the user to choose from for each Class providing each Value as an option (while displaying to the user as Label). If an option requires an additional cost, that can be calculated based on the option selected.- brianOn Thursday, April 24, 2003, at 06:19 PM, Kimberly D. Walls wrote:> That is certainly one of my considerations.>> At this point, I have started with a separate database for colors.> Certain vendors have certain colors. I have built the administration> interface to allow the client to manage colors by vendor. Then, when> the client goes to add an item for that vendor, only the matching > colors> appear as checkbox options.>> Some of the other options don't seem to be quite as simple. Who knew > a> kayak paddle could be so damn complex??>>>>>> -----Original Message-----> From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com] On Behalf Of> Gary Krockover> Sent: Thursday, April 24, 2003 9:05 PM> To: WebDNA Talk> Subject: Re: Database Structuring (again)>> Personally, I've always treated this type of inventory with a single> database, with each instance of size or color or option being a> different> line in the database. Of course that means that clients have to enter> nearly identical information in more than once. I'll be curious to see> how> others treat this type of layout.>> GK>>>> I know this was just a hot debate the last couple of days. but you> guys>> left me behind a bit, so I'm going to ask for myself with considering>> the store I am working on now.>>>> My client sells anything and everything having to do with outdoor>> sports, from kayaks to outdoor cooking utensils to sandals to tents,>> clothing and then some. With clothing, we obviously have the usual> size>> and color options; with sandals we have size, color, insole and> outsole.>> With paddles we have length, color, grip size and 1 or 2 piece sets.> and>> the list goes on and on for various items and their options.>>>> My question is to database or to multiple database. Given my>> programming skills, not the greatest, but not the worst. I am leaning>> more toward multiple databases. Can anyone assure me that I'm headed> in>> the right direction, or can anyone save me from disaster down the long>> road?>>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to> > Web Archive of this list is at: http://webdna.smithmicro.com/>>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: Database Structuring (again) (Brian Fries 2003)
Re: Database Structuring (again) (Kenneth Grome 2003)
Re: Database Structuring (again) (Kimberly D. Walls 2003)
Re: Database Structuring (again) (Gary Krockover 2003)
Database Structuring (again) (Kimberly D. Walls 2003)

My tendency would be to add a single options.db that could handle multiple types of options and indicate whether or not the option carried an additional charge. Something with fields like these:optSKU - the SKU for the product in questionoptClass - the classification of the option - size, color, length, etcoptValue - the internal representation of an option's value (blue, red, green; 8, 8.5, 9)optLabel - how to display the option in a menu for the user (Navy Blue, Red, Forest Green; 8, 8 1/2, 9)optCost - additional charge for this option (maybe it costs more in XXL than M)Now you when you display the order form for a given product, you can search the options.db by optSKU, and build menus for the user to choose from for each Class providing each Value as an option (while displaying to the user as Label). If an option requires an additional cost, that can be calculated based on the option selected.- brianOn Thursday, April 24, 2003, at 06:19 PM, Kimberly D. Walls wrote:> That is certainly one of my considerations.>> At this point, I have started with a separate database for colors.> Certain vendors have certain colors. I have built the administration> interface to allow the client to manage colors by vendor. Then, when> the client goes to add an item for that vendor, only the matching > colors> appear as checkbox options.>> Some of the other options don't seem to be quite as simple. Who knew > a> kayak paddle could be so damn complex??>>>>>> -----Original Message-----> From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com] On Behalf Of> Gary Krockover> Sent: Thursday, April 24, 2003 9:05 PM> To: WebDNA Talk> Subject: Re: Database Structuring (again)>> Personally, I've always treated this type of inventory with a single> database, with each instance of size or color or option being a> different> line in the database. Of course that means that clients have to enter> nearly identical information in more than once. I'll be curious to see> how> others treat this type of layout.>> GK>>>> I know this was just a hot debate the last couple of days. but you> guys>> left me behind a bit, so I'm going to ask for myself with considering>> the store I am working on now.>>>> My client sells anything and everything having to do with outdoor>> sports, from kayaks to outdoor cooking utensils to sandals to tents,>> clothing and then some. With clothing, we obviously have the usual> size>> and color options; with sandals we have size, color, insole and> outsole.>> With paddles we have length, color, grip size and 1 or 2 piece sets.> and>> the list goes on and on for various items and their options.>>>> My question is to database or to multiple database. Given my>> programming skills, not the greatest, but not the worst. I am leaning>> more toward multiple databases. Can anyone assure me that I'm headed> in>> the right direction, or can anyone save me from disaster down the long>> road?>>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to> > Web Archive of this list is at: http://webdna.smithmicro.com/>>> -------------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Brian Fries

DOWNLOAD WEBDNA NOW!

Re: Database Structuring (again)

2003

Top Articles:

Related Readings: