Great writeup! I wish there were more self-contained examples for how to use pg (and honestly other SQL systems) for stuff that isn’t just libraries, banks, or scheduling.
I’m not entirely sure I agree with having a different table per event type, since I usually use a hybrid approach of event name/string column plus a json details column, but they made it work and work well.
As a side statement, I want to point out how little (relatively) code this takes compared to the same implementation in other languages. Like, it’s nice to see a clear reminder of how the worldview of a language helps simplify a problem.
This is an interesting approach, and for many use cases I think a very smart one. Personally, I would design the schema a little bit differently. I would merge a few of the tables together, reducing the need for JOINs and views.
This technique is effectively the most common one in the static website world now. Although they don’t use relational databases, they rely on Git having the same behavior. For plain text with little structure, like the example blog here, I think it’s the better tool.
I once tried to shoehorn something like this into django and it was really painful. That version really really really loved their auto increment primary keys. :P
It also makes total sense for wikis and you kinda let your data model already solve your application logic problems. On the other hand the selects can be nasty, especially depending on the degree of normalization…
This is a 5 year old post of mine, so I’ll tidy it up a bit. If you notice some small changes you’re not going mad.
I’m not advocating ditching your favourite static site generator for PostgreSQL – the blog application is just a practical example!
Great writeup! I wish there were more self-contained examples for how to use pg (and honestly other SQL systems) for stuff that isn’t just libraries, banks, or scheduling.
I’m not entirely sure I agree with having a different table per event type, since I usually use a hybrid approach of event name/string column plus a json details column, but they made it work and work well.
As a side statement, I want to point out how little (relatively) code this takes compared to the same implementation in other languages. Like, it’s nice to see a clear reminder of how the worldview of a language helps simplify a problem.
One thing we’ve started using pg for lately is a Message Queuing Service, ala AWS SQS. It has built in support for it and works fantastic.
This is an interesting approach, and for many use cases I think a very smart one. Personally, I would design the schema a little bit differently. I would merge a few of the tables together, reducing the need for JOINs and views.
This technique is effectively the most common one in the static website world now. Although they don’t use relational databases, they rely on Git having the same behavior. For plain text with little structure, like the example blog here, I think it’s the better tool.
I once tried to shoehorn something like this into django and it was really painful. That version really really really loved their auto increment primary keys. :P
It also makes total sense for wikis and you kinda let your data model already solve your application logic problems. On the other hand the selects can be nasty, especially depending on the degree of normalization…
Just use Git.