Results 1 to 4 of 4
  1. #1
    Join Date
    Feb 2006
    Posts
    2

    Relational Database design (practical problem)

    I want to improve a database for product registration system. The goal of the system is to register products with characteristics. (length, height, color, max speed, weight, power etc. ) Each product has different characteristics. For instance, a car is registered with 30 number of characteristics length, height, max speed, etc. But a motor is registered with 6 number of characteristics such as power, weight etc.
    The current architecture of database is so:
    The main table is "registration". (the core of DB) Each product is described by a table. (because of different number of characteristics) For instance: Auto, Motor, etc.
    Each charachteristecs are listed as attributes of this product table. For Auto: length, height, max speed, car year, car model ...
    Now the problem is: The tables (products) are increased enormously, ie. too many tables.....
    How can be solved this problem?

    Thanks in advance!

  2. #2
    Join Date
    Mar 2004
    Location
    Toronto, ON, Canada
    Posts
    513
    What's wrong with lots of tables?
    --
    Jonathan Petruk
    DB2 Database Consultant

  3. #3
    Join Date
    Feb 2006
    Posts
    2
    Quote Originally Posted by J Petruk
    What's wrong with lots of tables?
    The tables (products) are increased enormously... At least invisible. Is the logic of the architecture right at all?

  4. #4
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by bnoyon
    Is the logic of the architecture right at all?
    yes, it is right

    do a search for subtype/supertype
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

Posting Permissions

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