Search Postgresql Archives

Re: [OT] "advanced" database design (long)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux