Results 1 to 5 of 5
  1. #1
    Join Date
    Apr 2008
    Posts
    1

    Question Design Concept Help, Resursive References... Kinda

    On and off for about a year, I've been trying to wrap my head around how to build a database structure to support what I want to do and I've about given up. I'm relatively new to database design... there must be something I'm not seeing.

    Imagine the concept of Components and Parameters.
    A Component can contain any number of Parameters and/or other Components.
    The allowable depth of Component 'nesting' could theoretically be very large, but in reality won't be more than be 6 or 7 levels deep.

    For example...

    Imagine I want to store information about a Web Server (Component). The server has simple properties, such as Manufacturer, Model Number, etc which might be represented as Parameters. It also has more complex properties that might be represented by other components, such as a Network Interface Card, with their own set of parameters and/or components.

    Every parameter is contained within a component. Components hold no real data themselves (other than maybe a name and type)... rather, they just act as a container for parameters and other components.

    It's pretty similar to how Classes and Attributes are related to eachother in OOP.

    Any insight into how I might store this kind of thing?
    Last edited by csimpkins; 04-15-08 at 13:11.

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Databases like to have defined elements and relationships. You may think of this as a limitation, but actually it is their strength. Part of their job is to ensure that the data they store makes sense, and putting rule and limits on the data is how a relational database manages this.
    That said, your problem can be modeled using an unconventional database technique that most seasoned DBAs avoid like the plague. Its called the Entity/Attribute/Model design.
    Remember that scene in Star Wars where Yodo shows Luke the dark side of the force?
    Yeah. Its kinda like that.
    These days, this Jedi master encourages young padewans to use XML data instead of an EAV model, and even then only as a last resort and only to store that portion of the data which is unstructured.

    Live long and prosper.
    Damn. I screwed that up....
    May the Force be with you. You're gonna need it.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Entity/Attribute/Value design. Your lexdyslia is getting worse
    Testimonial:
    pootle flump
    ur codings are working excelent.

  4. #4
    Join Date
    Apr 2008
    Posts
    29
    How about Classes, Attributes and Instances ??

  5. #5
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    No....

    Definition: Entity/Attribute/Model
    Example: Client/Address/"Claudia Schiffer"
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

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