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 TableB which has 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?