Wed Jul 15 09:55:57 CEST 2009
I don't understand databases:
In the database world, developers are sometimes tempted to bypass
the RDBMS, for example by storing everything in one big table with
two columns labeled key and value. While this allows the developer
to break out from the rigid structure imposed by a relational
database, it loses out on all the benefits, since all of the work
that could be done efficiently by the RDBMS is forced onto the
application instead. Queries become much more convoluted, the
indexes and query optimizer can no longer work effectively, and data
validity constraints are not enforced.
This is exactly what I would do.
- a table represents a relation (subset of a product space)
- a functional parameter dependency of A -> B means that given
parameter A, there is a unique B (the relation is a function of
- a candidate key is a minimal superkey. a supperkey is a
collection of attributes that uniquely determines a row (there is
a functional dependency key -> row).
About performance: In  is mentioned that first, you should start
from a anormalized design and optimize it, then you can start using
indexing for columns that are frequently used as important selection
criteria, sort criteria, and/or used in joins.