I agree, and I am doing the entity attribute model because I simply have to. This table is used to persist data that is hold in user defined information models. Kind of a domain specific language. The users continously create these hierarchical structures, so neither the amount of them, nor their structure is stable. On top of that, these structures can have quite deep hieararchies, with collections, references to other structures etc.. This forces almost everyone working in the domain to end up in this db model. In case you are curious and have a lot of time at your hands, you can visit www.openehr.org to see what I'm talking about. The specifications part have all the documents one can need.
I have worked with very capable DBAs before, and even though it has been quite some time since I've done real DB work, I would like to invest in postgresql as much as I can, to make the total framework faster. Therefore, all suggestions are welcommed.
All the best
Seref
On Thu, Apr 23, 2009 at 1:21 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
2009/4/22 Seref Arikan <serefarikan@xxxxxxxxxxxxxxxxxxxxx>:
> Hi Filip,If I'm not mistaken, you're doing Entity Attribute Value model type
> First of all: thanks a lot for your kind response. Here is the create script
> for my schema:
>
> CREATE TABLE "app"."archetype_data" (
> "id" BIGINT NOT NULL,
> "context_id" VARCHAR(1000),
> "archetype_name" VARCHAR(1000),
> "archetype_path" VARCHAR(1000),
> "name" VARCHAR(1000),
> "value_string" VARCHAR(1000),
> "value_int" BIGINT,
> "value_double" DOUBLE PRECISION,
> "session_id" VARCHAR(1000),
> "instance_index" INTEGER,
> CONSTRAINT "archetype_data_pkey" PRIMARY KEY("id")
> ) WITHOUT OIDS;
storage. I.e. a database in a database. Makes for easy coding, and
danged near impossible to troubleshoot your data.
It's a religious issue but I come down on the side that good data
modelling is hard for a reason, because it pays you back so much in
the end.
