1

Consider an environment where we have a single, core database, with many separate systems using this one database.

This leads to all of these systems have a common dependency, which ultimately introduces coupling between them.

This means that we cannot always evolve systems independently of each other. Structural changes to the database (even if only intended for one, particular system), requires a full sweep test of ALL systems, and may require that other systems be 'patched' and subsequently released.

This is especially tricky when you want to have separate teams working on different projects.

What is a good 'pattern' to help in avoiding such coupling?

I would imagine that a database should be exclusively depended on by one system. If other systems require data for whatever reason, they should request such from an API service of some kind.

A drawback of this approach which comes to mind is performance: routing data between high-throughput systems through service calls is much slower than through a database connection.

  • Best way is, not using Integration Database at all. martinfowler.com/bliki/IntegrationDatabase.html – Euphoric Aug 21 '14 at 6:11
  • 1
    "A drawback of this approach which comes to mind is performance" Did you profile this or is this just baseless assertion? – Euphoric Aug 21 '14 at 6:12
  • @Euphoric: We use WCF Services quite extensively, and yes, there is overhead. While minimal, the impact could be significant if we had to replace all database queries with service calls. – Dave New Aug 21 '14 at 6:15
5

A few tips picked up over the years...

  • The database is the central repository of your data. It should be shared by many applications.
  • Databases are relatively benign when it comes to new projects requiring extension. Adding extra columns or tables should not upset existing products. If fields move, then yes your existing applications are affected, because your business needs changed.
  • Set up a "layer" around your database that does business operations rather than CRUD (e.g. makePayment(), placeOrder(); deliverTo()). If working with Java, my favourite tool is MyBatis, but there are lots of other options (Hibernate, TopLink, Spring JDBC to name a few)
  • Never use "select * from someTable... Always explicitly name the columns you need. So when someone adds an optional 5GB blob to your rows, you won't be hit with the overhead of reading a huge blob.

There is no silver bullet. An API hiding the details seldom helps. SOAP in particular is picky - the slightest change to the API means all clients need attention. REST is somewhat friendlier.

Good luck!

  • +1 for pointing out the false assumption that there is a one-db <-> one-app relationship. – Tulains Córdova Aug 21 '14 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.