Results 1 to 8 of 8
  1. #1
    Join Date
    Jan 2006
    Posts
    1

    help database designing

    Currently I am designing a database for my company that I work for as network administrator, but the company needed me to design a database. The database is intended to store products, since our company is a retail company it has different products under different categories e.g. (auto and its related products, electronics under this camera TV etc...)These products need somewhat different columns and description. Is it good to design a table for the auto and another for electronics? I have even another category under one databse. Please help!

  2. #2
    Join Date
    Aug 2004
    Posts
    330
    A retail company wants a network administrator to design their database? Is this being done in your spare time at no extra cost to the company?

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Hi Abitoma, and welcome to the forum.

    Generally speaking it would be best to store products in one table. If you go down the route or different tables for different products or product types then you will be creating a major maintenance problem in the short to medium term. If you are starting off on the database design route then www.r937.com/relational.htm may be a good starting point

  4. #4
    Join Date
    Jan 2006
    Posts
    2
    hi,

    I'm not sure if this is the best solution but have you thought about using inheritance design?

    You could have a master product table and from that have autoProduct and electronic products as children.

    cheers
    jack

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    A product is just a product, in db design term it shouldn't matter if its a car or a camera.

    Having said that you could have a master product table containing all the common fields and sub table / tables containing the truly unique stuff. At first glance this could be a candidate for a n XML type sub table containng say <productID><featuretype><value>, but I fear it would very quickly become a pig to maintain and search effectively. You would need a table to identify the featuretype and include in that something to identify the display sequence so that similar products are presented in the same manner. You would also need a rules table to identify what features belong to which product or product types (EG it would be silly to store tyre size (appropriate to cars but irrelevant to cameras)). You may also want to store a flag indicating what elements are required, what would be nice to have, and waht could be stored if its handy

    Bear in mind that most db engines allow you to have a memo / blob column which can contain free form text you can ofen coerce a lot of the less relevant data in there - its still (probably - depends on your db of choice) searchable.

    i suppose the key question has got to be what is it in the data stream that separates your product types and how significant are thoise differences - are they something that is mission critical or is it just nice to have. how do you expect to manipulate the data in these differences. As an example do you need to know ech element, and say provide a search for it, or could you get away with a textual description. If its a multilingual application that willbe handling hte data ten a textual desription may not be appropriate and key pair route may be preferable

    of course it does depend on your weapon (db) of choice. if you have an object orientated db then an inherited design may make sense, but you can go down the OO route using a bog standard SQL DB and encapsulate the inheritance within your applicaitons objects.
    HTH
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Oct 2005
    Posts
    178
    Quote Originally Posted by abitoma
    Currently I am designing a database for my company that I work for as network administrator, but the company needed me to design a database. The database is intended to store products, since our company is a retail company it has different products under different categories e.g. (auto and its related products, electronics under this camera TV etc...)These products need somewhat different columns and description. Is it good to design a table for the auto and another for electronics? I have even another category under one databse. Please help!
    YOu have to sit down with your management on what they want to accomplish with the database, for now and future. Starting with good planning saves a lot of time and effort. You can create a database of any form but if it does not serve your accurate outcomes, it's worthless. If your company is depending on you seriously to invest and if you don't have good experience in relational database, get someone who has. If you are an aggressive and fast learner and challenged by this endevour, start playing with MS Access ( which is already maybe loaded in your home computer) to get the concept and besides MS Access is easy to convert to another format if you have to later on. Some people think if you know computer stuffs you know everything. My advise to you, don't ruin your Network Administrator reputation. But if you do take this opportunity, think of how you would protect the data or records integrity and consistency so you can query accurately. Because, if there are inconsistent formats and spellings in one field in the tables, be ready to do global changes if you already have thousands of records entered. Sometimes if you need to repair the inconsistency in a massive records that are also linked to other tables, you have bring out your programming skills to do the job, you can't edit 10,000 records one by one. Good luck
    Last edited by fredservillon; 01-21-06 at 00:06.

  7. #7
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by abitoma
    Currently I am designing a database for my company that I work for as network administrator, but the company needed me to design a database. The database is intended to store products, since our company is a retail company it has different products under different categories e.g. (auto and its related products, electronics under this camera TV etc...)These products need somewhat different columns and description. Is it good to design a table for the auto and another for electronics? I have even another category under one databse. Please help!
    Do network admins not know how to use search engines? There are plenty of open source network admin tools (nmap, for example) so why wouldn't there be open source product catalogs?

    Download one, install it, show it to management and come back here with an intelligent question. By "intelligent" I mean one that can't be answered in 5 seconds with a web search.

  8. #8
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Generally speaking it would be best to store products in one table.
    have you thought about using inheritance design
    Wow. I wonder if forums for highway engineers have similar discussions.

    CluelessSchmuck: "My company needs to design a road. I'm in charge of waste management. This road should go somewhere, but I don't know where yet."

    CaptainObvious: "Well, I suggest making your road flat. Many roads have stripes."

    Deepthinker: "You might want to talk to management about looking at a map. Does anyone there have a car?"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •