Relational Gui Dilemma

On usenet, a discussion had broken out whereby there's multiple suggestions for how to represent GUI "widgets" relationally. Here's the basic problem:

All widgets would have a standard minimum set of attributes, but individual and new widgets may have unanticipated and additional attributes. Thus, the landscape looks something like this:

 Standard attributes: ABCDE

 Widget D: FGR  (in addition to ABCDE)
 Widget E: FQ   (in addition to ABCDE)
 Widget F: GQTV (in addition to ABCDE)

Here, letters represent attribute columns. Here were the primary suggestions:

Use DynamicRelational so that attributes can be dynamically "added" as needed.
- Con: Implementation does not exist yet
- Con: Works poorly if features require arguments, or if a feature can be applied twice in two different ways (normalization error).
  - DynamicRelational can make columns and/or values required, if one wants. And normalization is an issue in any design. I'd like to limit this sub-section to con's specific to DynamicRelational and not bring alleged limits of RDBMS into this. That's probably a different topic. Thus, are the stated objections specific to DynamicRelational? An example is welcome. -t
  - There is more on DynamicRelational below near PageAnchor DR-OBJECTION-01.
  - In the spirit of don't-delete-without-asking, I moved a confusing section from here to HomelessContent. -t
Use OOP classes
- Con: It's OOP :-) It's a relational exercise, not a general one.
Have a primary widget table with the common attributes (ABCDE), and then an AttributeTable for the extra's.
- Con: Would mix rows and columns for essentially the same thing. Does not take advantage of column type-checking.
Have a different table for each widget
- Con: Would require ability to create new tables for each new widget. Table-space may get crowded. Lots of UNION queries may be needed to search common attributes.
Have a different table for each widget for the uncommon attributes, but a single Widget table for the common items (ABCDE). A join could be performed to create a result view that looks like a single table per widget.
- Con: Similar to above, except that UNION queries are not needed for the common items.
Have a new table for each new column (linked via foreign key to Widgets table).
- Con: Have to create new tables, and a way needs to be advised to detect new columns. Could pollute table-space.
Add each new column to the Widgets table as needed, creating a "sparse" table.
- Con: Requires altering the schema. Sparse tables are considered "bad" in some circles.
Formalize simple prototype model in Relational (justifiable because creating widgets really is creating objects).
- Con: Doesn't play nice with SQL due to need for both transitive joins and heuristic cuts. (Doable for other relational languages, though.)

 relation Widget(name,description) key(name)
 relation Prototype(widget,prototype) fk(widget from Widget), fk(prototype from Widget) unique(widget,prototype)
 relation Feature(widget,feature,argument) fk(widget from Widget)

 Widget(Base,"Base for almost all Widgets").
 Widget(Widget D,"An ugly button").
 Widget(Widget E,"A blinking smiley-face").
 Widget(Widget F,"Barbershop Scrollbar...").
 Prototype(Button,Base).
 Prototype(Icon,Base).
 Prototype(Scrollbar,Base).
 Prototype(Widget D,Button).
 Prototype(Widget E,Icon).
 Prototype(Widget F,Scrollbar). 
 Feature(Button,F,()).
 Feature(Icon,F,()).
 Feature(Scrollbar,V,()).
 Feature(Widget D,G,R).
 Feature(Widget E,Q,()).
 Feature(Widget F,G,()).
 Feature(Widget F,Q,()).
 Feature(Widget F,T,()).

Need query to find all features of a widget, retrieving only the arguments closest to the widget descriptor.

"Feature" looks suspiciously like an AttributeTable.

"Suspicious"? You say it like it's a bad thing. This is a bit EAV with a bit prototype. What one is avoiding is the gross inconsistency of "Have a primary widget table with the common attributes (ABCDE), and then an AttributeTable for the extra's.".

That could be "fixed" by using the AttributeTable for every widget attribute and dispense with the row-oriented primary widget table. But it has other downsides. But, if we are considering non-existent products, then I'd select DynamicRelational anyhow.

Using an AttributeTable for every attribute? Doesn't that violate: "new widgets may have unanticipated and additional attributes" (I mean, unless you can somehow advertise the new tables? I'm curious as to which query languages support first-order queries, where which table to query upon is indicated by an attribute value). And I wasn't considering non-existent products; what was proposed above could easily be represented in a modern RDBMS or even or very easily in something like DataLog.

I think there is a miscommunication here somewhere. Here's an example AttributeTable for part of a simple GUI line-graph widget:

Table: widgetAttribs

wdgtRef Attrib Value --------------------------- 45 markerColor Green 45 markerUnits Pixel 45 markerSize 3

(This variation assumes we already have a Widget table that defines each widget instance.)

Any new (unanticipated) attribute just becomes yet another row and "Attrib" column item.

Ah, so 'widgetAttribs' == 'Feature', except that you're identifying widgets by number instead of by name, and minus access to the flexible value spec - Feature(widget 45,marker,{color:green,size:(pixels:3)}). When you said "An AttributeTable for every widget attribute" (emphasis yours), I assumed you meant an AttributeTable per widget attribute.

Your approach does have the distinct disadvantage of making it very unclear whether 'markerUnits' is a feature of the widget or a sub-attribute for the 'markerSize'.

As far as the "number", we could use a name also. But if we want auto-install, I figure a number is better since there's no human around to select a unique ID. As far as marker-related attribute grouping, we could make a markerAttribute table, but that's overkill in my opinion. IDE's that over-group attributes are annoying in my opinion. Feel free to disagree. --top

PageAnchor DR-OBJECTION-01

And DynamicRelational also has considerable disadvantages. Why would you choose it?

Only strong-typing zealots find big "flaws" in it.

[Strong-typing aside, anyone with an interest in the primary role of database systems -- data management -- would regard the notions behind DynamicRelational as untenable at best, and downright dangerous at worst. The strength of a database system lies in the degree to which it constrains, not the degree to which it un-constrains. The goal of a database is to record facts with as much reliability as possible, which by definition means considering types, constraints, integrity controls, and security controls. Removing or weakening any of these means reliability is compromised. Would you trust DynamicRelational to GIS, HR, CRM, ERP, pension records, inventory, billing, ordering, payroll or medical records tasks? I wouldn't. With DynamicRelational, I'd be lying awake at night in desperate, sweat-soaked fear that some client-side application bug will allow someone's hourly wage to be recorded as 8,95 instead of 8.95 and blow tonight's entire payroll run. Ever seen what happens when employees don't get paid? As a trivial route to quick-and-dirty, single-user application data persistence, DynamicRelational might have some value. In any other context, it's dire.] -- DaveVoorhis

DynamicRelational would not be for life-support and billing apps. That we can agree. But there seems to be a need for nimble databases for nimble projects, perhaps bordering on experimental. I've done a fair amount of work on experimental reporting systems where people have to see it before they know its what they want. Companies want ad-hoc reports/queries without having to wait for somebody to build a custom 3-page SQL query. Dynamism is useful under such projects. --top

Dave's points are good. The primary flaw I see with DynamicRelational has to do with normalization and constraint descriptions. And I'll admit to being a fifth(or sixth)-normal-form zealot.

How is normalization an issue? The schema can be whatever say an Oracle schema is if you want it that way. And constraints *are* permitted. It just doesn't have to start out with lots of constraints. That's the whole idea: start out with a very loosey-goosey slate and tighten it over time. It's as loose as possible but can be made tight as constraints and restrictions are added. And I am not typically a fan of heavy normalization; it's too inflexible per changing business requirements in my experience. It's often premature classification that's hard to back out of if relationships or requirements change. But I'd like to explore specific scenarios rather than talk generalities. --top

EditHint: move section to DynamicRelational since it doesn't seem specific to GUI's. Or, create DynamicRelationalAndNormalization?.