The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Efficiency question on creating classes for ASP.NET online store

I'm working on an ASP.NET e-commerce store, but I'm relatively new to e-commerce things, so I've run into a small snag with designing the relevant classes (I'm trying to take my time with this app and develop it the "right" way).

The issue is that our product database can have products that belong to multiple categories; the products table itself (an old Foxpro 2.6 DBF) has five CategoryID fields (e.g. CatID, CatID2... CatID5), and theoretically could have tons of different attributes based on the product itself (e.g. clothing would have a style, size, color and gender).  Naturally I want to do this efficiently, but as I said I'm not familiar with e-commerce. 

First, the multiple IDs.. is there a better way of doing it than having multiple CategoryID properties for each one?  I have defined a struct for the Category itself, maybe an array of these would be more efficient?

Next, the problem of different attributes for each product.. the big issue here is that the store's products depend on the client (in effect, my company is setting up and managing the store for multiple clients, who can all have different categories and products.  Hosted e-commerce, basically), so Client A may offer Shirts and Balloons, while Client B offers Balloons and Flowers.  We have no way of currently knowing what products they offer; it's determined later on.  Is there *any* effective way to try and minimize the coding? 

Should I even BE looking at a true OOP solution for this, given how convoluted it is with differing factors?  Or should I not worry about a specific Product class and instead pull the categories to display straight from the DBF when the time comes, based on the client's ID, and then proceed from there by displaying the products associated with that ID?

Please forgive my relative inexperience.. I have not had the chance to do much more than dabble in programming, so I am still learning the best ways to "object-ize" things.
Wayne M
Wednesday, July 12, 2006
Work out how the data relates to each other, e.g., whether you have one-to-one, one-to-many, etc. type relationships and then figure out your table and field structure from that.  Sounds like categories and products are related as one-to-many (one product, many categories).  Sure you can make catids fields in the product table, but if you don't really know how many is the max, you could be limiting yourself later and if you have more than a few, you are wasting space.
Mike Stephenson Send private email
Wednesday, July 12, 2006
A common way of dealing with something like multiple categories is to keep the category information out of the product table and stick it in a product-to-category join table.  The join table contains columns for product ID and category ID and can then be queried with a category ID to list all product IDs associated with that category or a product ID to list all categories associated with that product.  Often, this query will use a SQL JOIN to return more details from one of the associated tables, hence the name "join table".  Google for "many-to-many" "join table" for tons of info -- it's a very common pattern.
SomeBody Send private email
Wednesday, July 12, 2006
Thanks, I will definately check that out.  Can Foxpro 2.6 even USE a SQL JOIN?  My experience has only been only with SQL Server, but this company refuses to spend the money to upgrade and keeps everything in Foxpro 2.6 DBF files.
Wayne M
Thursday, July 13, 2006
==> Can Foxpro 2.6 even USE a SQL JOIN?

Wow. 1994 is calling. They want their file format back.

I used to work with Fox, but I can't set the WayBackMachine far enough back to remember. I *know* there was a way to join data from multiple tables -- whether or not it was an actual ANSI Compliant SQL JOIN or not? Who knows. Last time I worked with FP was in 1995.
Thursday, July 13, 2006
I work with some apps written in FoxPro 2.6 (they're getting rewritten any day now...)

The SQL Select in FP2.6 doesn't support the 'FROM <table1> JOIN <table2> ON <condition>' syntax, but you can do a join with 'FROM <table1>, <table2> WHERE <condition>'. It's not as clear (or probably as effecient) but it does work.

I'm not sure how clear (or useful) the following will be, but here's the Select syntax from the FP2.6 help:

    [AS <column_name>]
    [, [<alias>.]<select_item>
        [AS <column_name>] ...]
FROM <table>
    [, <table> [<local_alias>] ...]
    [[INTO <destination>] |
    [PREFERENCE <name>]
    [WHERE <joincondition> [AND <joincondition> ...]
    [AND | OR <filtercondition> [AND | OR <filtercondition> ...]]]
    [GROUP BY <groupcolumn>[, <groupcolumn> ...]]
    [HAVING <filtercondition>]
    [UNION [ALL] <SELECT command>]
    [ORDER BY <order_item> [ASC | DESC] [, <order_item> [ASC | DESC] ...]]
RocketJeff Send private email
Thursday, July 13, 2006
That should be helpful, thanks.  I would much rather use SQL Server (or even MySQL) but management does not see a reason to upgrade because they have all legacy programs that load individual DBFs; when it was set up it was great, so "if it's not broken, why fix it"
Wayne M
Thursday, July 13, 2006
Actually (now that I think about it) it doesn't matter what version of FoxPro the tables are in if you're accessing them with the Visual FoxPro ODBC or OLEDB drivers.

Both drivers implement the 'LEFT JOIN' style syntax and can read/write FoxPro 2.6 tables (and it leaves them in the 2.6 format).  I do this all the time when I'm mining data from 2.6 tables in VB using ADO.
RocketJeff Send private email
Thursday, July 13, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz