Reader responses to ORM series

I’ve received several reader comments in response to the last week’s emails about databases and ORMs. I love that. Keep the comments coming!

Two comments in particular, both about PostgreSQL, I thought were worth digesting and sharing:

  1. PostgreSQL comes with a rich set of JSON functions, which can make it work as a quite capable JSON document store. This can be valuable if you already have PostgreSQL installed, and don’t want to complicate your infrastructure by adding MongoDB or similar.

    In truth, any relational database can be treated as an unstructured document store or key-value store. A simple 2-column table does the trick. For small data sets, this is often enough. When you need more sophisticated indexes or search capabilities you may need to opt for a product designed around document storage.

  2. Another reader wrote to mention that he uses PostgreSQL to generate nested JSON that he can serve directly as an API response. By using the row_to_json function, in a sense, PostgreSQL itself is his ORM (according to a loose definition of the term), and his application just passes the raw result through to the API client. As an example:

    SELECT
      forum_posts.*,
      row_to_json(users) AS author
    FROM forum_posts
    INNER JOIN users
      ON users.id = forum_posts.author_user_id
    WHERE forum_posts.forum_thread_id = $1
    

I love both of these approaches, because they’re thinking critically about the problem at hand, and finding useful, application-specific solutions, rather than blindly applying a cargo cult approach.

What other non-standard database configurations have you seen? I’d love to hear from you.

Share this