in reply to OO concepts and relational databases
While there are some cases in which this is a good idea, it can also lead to really confused things like this:
Entity Attribute Value
| Entity | Attribute | Value |
| Elephant | Color | Gray |
| Workstation | Linux_distro | Debian |
What happens to constraints and data types when each new row potentially introduces a new data type? What meaning does the concept "entity" have if there are no limits on the kinds of attributes it can take and the range and type of data the values for those attributes can have? I realize that you know what you're doing and probably only use this kind of a table in appropriate circumstances (and you did specify an example in which there were multiple optional attributes which is not the same as the example I've shown), but this kind of design seems to be a favorite with beginners who don't realize that it can sabatoge any notion of structure in the data.
You wrote:
Storing the optional attributes as columns requires a database change for every new attribute.
The ability to change the structure of the database is an essential feature of relational databases. Sure, you want to avoid it when you can, but to label it a bad thing (tm) throws out the entire relational baby with the bathwater.