Over-engineered database?

versatilia

I think I'm going slowly insane... I had an interesting problem,
basically I needed a templating/database system which would handle:

rich field types (eg. weight, HTML page, currency)
presentation of data (eg. if the destination is an HTML document, translate character entities)
validation of data (eg. the PostalCode field type looks up the postcode in a web service)
field meta-data (eg. description, friendly name, tool tip, parameters depending on field type)
snapshots
full edit history with point-in-time recovery

Anyway I re-invented the wheel, now I have a database within a database - there's a table of tables, a table of fields, and a table of field values. Each rich field type is a perl module which understands how to present, edit, validate and store its own data (eg. the Postal Code field will validate the postcode using a web service). I even ended up having to write my own 'WHERE clause' parser! At this point I'm really starting to think "WTF?!!!"

The upshot is you can imagine the performance hit of doing all this - so I'm thinking there must be a way to do all this with a modern day DB. Someone said postgres can be extended by writing your own data types in C... any further suggestions?

ammoQ

@versatilia said:

The upshot is you can imagine the performance hit of doing all this -
so I'm thinking there must be a way to do all this with a modern day
DB. Someone said postgres can be extended by writing your own
data types in C... any further suggestions?

Alex ranted in his blog about the new feature of MS SQL Server 2005, which can store instances of .net classes.
Look for the

<font size="3">"When Should I Use SQL-Server CLR User Definied Types (UDT)?"</font>

blog entry. Maybe this will help you, but should also ask yourself if you are on the right track anyway.
Maybe what you really want is the mystical beast called "middleware"?