Wed Jul 15 09:55:57 CEST 2009


I don't understand databases[1]: 

  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.

Some terminology[2]:

  - 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[3]: In [4] is mentioned that first, you should start
from a anormalized[2] 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.

[1] http://en.wikipedia.org/wiki/Inner-platform_effect
[2] http://en.wikipedia.org/wiki/Database_normalization
[3] http://en.wikipedia.org/wiki/Index_%28database%29
[4] http://www.15seconds.com/Issue/040115.htm
[5] http://www.troubleshooters.com/littstip/ltnorm.html