row-driven tables

[mitch]

A group at work claims that the familiar relational database table design of a row being an occurrence with attributes defined in each column does not work as well in applications as its reverse. For example, to add a column, location, to TableA which now has columns ID and Name means changing the table structure and redeploying the executable forms; but if TableA is flipped into row-driven TableB with columns ID, Attribute and Value then this is faster and cheaper as we're just adding rows and not changing structure, etc. I see lots of problems here with data types and integrity; any other problems?

[MAK]

Depends on Functional specification.
If you are trying to create a dynamic page where users can create their own form then your idea will be good.

You can get those kind of information from system tables( instead of you maintaining a table for all the tables )and if your DB engine is RDBMS.

Give a brief description about your application, so that we can give suggestions,recommendations and comments.

[mitch]

Thanks for your interesting response. Not the case of users creating their data entry forms dynamically. This is a hierarchical bureaucracy! A corporate Oracle8i database documents the occurrence of wildlife in various geographic regions. Wildlife surveys follow different protocols in different regions. Corporate wants to resolve differences by using row-driven tables described previously instead of subsetting core tables to accommodate regional differences. The pros are this is easier to administer; the cons are many data elements not in corporate but mandated by regional protocols will remain external to core database and relationships and integrity rules between such elements will not be enforced or even defined.