I've got what I think is a fairly simple SQL question.
Frist, some background.
I'm building a database to log events produced by some scientific instruments. The postgresql database is attached
toby muliple java programs using JDBC.
An event has: timestamp,event_name,list_of_attributes The list_of_attributes are simple (string) name,value pairs.
Anevent may have 1 or more attributes in its list (no upper limit is imposed by the system).
Insertion performance is critical - selection performance *much* less so.
I wrote a simple test version using a single table with columns:
lab.devel.eventdb=# \d events_table Table "events_table" Attribute | Type |
Modifier -----------+--------------------------+--------------- time | timestamp with time zone | default now()
event | character varying(64) | not null name | character varying(64) | not null svalue | character
varying(80) |
The Java code accepts (via CORBA) events and then splitsthe events into multiple rows in this table (one row
perattributein the list_of_attributes).
This works fine for insertion - it's simple and fast enough with
transactions.
However, although selection performance isn't a priority, the
ability to reconstruct the events from the database is needed
and the above simple table doesn't provide enough information
to do so. (The resolution on the timestamp field isn't
enough to distinquish separate events that have the same name.)
Is there an obvious way to solve this (preserving insert
performance as much as possible) at the database level? Or
should I bite the bullet and solve it at the java level?
I'm partial to a solution solving it at the database level
because the fact that there are multiple event sources (java
apps distributed across a network).
I'm leaning toward two tables - one with rows of "timestamp,event"
and an internal tag that can be used to identify rows of "name,svalue"
in a second table, but I'm new enough to SQL to be uncertain
of the best way to set this up and still get good insert performance.
(And whether this would really be better than some approach using a
single table.)
Thanks for any guidance!
Steve
--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.