3 ms·

When I can do my ideal best, I write a remote facade to my database that provides functions and views on the data as an API, which can be adapted to an ORM or m

When I can do my ideal best, I write a remote facade to my database that provides functions and views on the data as an API, which can be adapted to an ORM or mapped nearly 1:1 to a DAO. This API lends itself to TDD, and yes, you must test your database components the same as any other code. Preferably using database code. For PostgreSQL I really liked PGTap. Include this testing in CI and other unit test executions. My sniff-test for a well-done schema is that developing application(s) around it should be clean.

lmm 12y ago
This link is about Redis but I apply the same approach to databases: http://michaelxavier.net/posts/2014-04-27-Cool-Idea-Free-Monads-for-Testing-Redis-Calls.html http://michaelxavier.net/posts/2014-04-27-Cool-Idea-Free-Mon... The downside is that you need to express the command language, so you lose the ad-hoc querying capability that SQL gives you. But something more structured and more closely corresponding to the domain is generally want I want anyway.
- spacemanmatt 12y ago
  > something more structured and more closely corresponding to the domain If the needs have changed, the API should be upgraded. It seems like ad-hoc querying is mainly to get around shortcomings in the API, right?
  - lmm 12y ago
    Sometimes the business requirements really are that ad-hoc that you need something as general as SQL (in which case there's no point reimplementing it yourself as an "inner platform").
    - spacemanmatt 12y ago
      There's no inner platform. If the business requirements obligate the schema to change, that has a cascade effect on the remote facade and any ORMs using it or DAOs written against it. The database is part of the product, but if you treat it as a foreign component on its own change schedule, I understand how it looks like an inner platform.
      - lmm 12y ago
        I meant in the sense of http://thedailywtf.com/articles/The_Inner-Platform_Effect http://thedailywtf.com/articles/The_Inner-Platform_Effect . If you try to create a platform that has all the power and flexibility of SQL queries, you end up reimplementing SQL, poorly.

lmm 12y ago

This link is about Redis but I apply the same approach to databases: http://michaelxavier.net/posts/2014-04-27-Cool-Idea-Free-Monads-for-Testing-Redis-Calls.html http://michaelxavier.net/posts/2014-04-27-Cool-Idea-Free-Mon... The downside is that you need to express the command language, so you lose the ad-hoc querying capability that SQL gives you. But something more structured and more closely corresponding to the domain is generally want I want anyway.

spacemanmatt 12y ago
> something more structured and more closely corresponding to the domain If the needs have changed, the API should be upgraded. It seems like ad-hoc querying is mainly to get around shortcomings in the API, right?
- lmm 12y ago
  Sometimes the business requirements really are that ad-hoc that you need something as general as SQL (in which case there's no point reimplementing it yourself as an "inner platform").
  - spacemanmatt 12y ago
    There's no inner platform. If the business requirements obligate the schema to change, that has a cascade effect on the remote facade and any ORMs using it or DAOs written against it. The database is part of the product, but if you treat it as a foreign component on its own change schedule, I understand how it looks like an inner platform.
    - lmm 12y ago
      I meant in the sense of http://thedailywtf.com/articles/The_Inner-Platform_Effect http://thedailywtf.com/articles/The_Inner-Platform_Effect . If you try to create a platform that has all the power and flexibility of SQL queries, you end up reimplementing SQL, poorly.