David Fetter wrote:
> The math beneath this is that query complexity goes up like O(E!A!V!)
> for Entity, Attribute and Value.
Makes sense.
> The first price, though, and by far the biggest, is that it's
> impossible to maintain any kind of data integrity in such a system, as
> such constraints, by their nature, are application-dependent. Two
> applications means you're violating the SPOT (Single Point of Truth)
> Rule, and that in turn means your data turns quickly into
> incomprehensible gibberish.
Starts making sense, too.
Could you give advice (or pointers what I should look at) on how one
would (roughly) "properly" schemafy the following requirements:
- unknown number of differing paper forms to print data on
- user fills in on-screen masks to aggregate data for printing
Intent: use the database to store a) definitions for on-screen masks,
b) definitions for printout (how to place data), c) the denormalized
data eventually put into form instances (the normalized source data
already is in the database).
There seem to be three basic approaches:
- one table per form def plus one per form type holding content
- one table holding form defs as, say, XML to be parsed client-side
plus another table holding form data as XML, too
- EAV: tables holding form defs, field defs, form instances pointing
to form defs, and field data pointing to field defs and form instances
each with all the relevant foreign keys
The first requires DDL whenever a form is added by a user.
The second requires client-side logic making form reuse across clients
a lot harder (SPOT violation ?).
The third sounds OK -- but seems to be of the apparently dreaded EAV type.
What am I missing ? Where should I get a clue ?
Thanks,
Karsten Hilbert, MD
wiki.gnumed.de
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
