|
|
|
|
|
by MarHoff
3334 days ago
|
|
I like your schema-lite terminology and I think it describe pretty well my approach. I've only start to explore all possibilities, but main use so far: -Store experimental properties before next schema revision -Particularly good alternative to composite-type in early stage dev if you want to make live modifications without replaying the whole deployement script. (Composite type usually have huge cascading constraints) -Storing "metadata row" for later use PS: Actually it may even be an alternative to composite type in production because I can totally picture case when you need row level "objects" that vary depending on the value of another column. Yes you can normalize, but it might be more maintainable to keep everything in one table an write an appropriate check constraint. And it will still be easily human readable as opposed to a literal representation of a custom type or whatever (think of PostGIS geometry type that is very versatile but totally opaque to humans). |
|