Hacker News Reader

Comment by imbusy111 | Hacker News Reader

Services should be communicating through public interfaces, not databases. Otherwise you're confusing implementation details with public interfaces and change becomes really hard and risky.

I can see this being useful in some legacy system that you have to maintain that is not changing anymore, but otherwise I don't see a good use for it for properly designed and new projects.

View on HN

Suppose we want to run a complex reporting query on tables in Sales database (running MySQL) and Finance database (running PostgreSQL). What is the good option without duplicating data from one system to another?

ETL, that way you can also ensure your data gets put in a format that'd make it easy to report on.

Granted, it's not quite as quick as this, and not suited for "one-off" reporting, but it's a lot more flexible. Put things in a nice star schema and you have a good way to do analytics on your data.

Duplicating data isn't a bad thing.

Having a process that copies data into a reporting system solves the problem that otherwise it would be brittle (changes to either system might break things) and performance (any reporting queries affect realtime ones). Also, as it's decoupled, pulling in data from a 3rd system, e.g. CRM is possible.

>but otherwise I don't see a good use for it for properly designed and new projects.

What's your definition of properly designed projects?

A project that adapts easily to changing business requirements and environments.

There are cases where you do know that those don't change as fast or that the actual core of your software needs a fundamental rewrite anyway to pivot. Think about number crunching or comparable small software.

I don't see anything that doesn't meet those requirements.

Reply on news.ycombinator.com