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.
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?
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.