3 ms·
I think this pain comes from using swl databases for integration, which is an antipattern in my book, and prevalent in the enterprise. Databases should have a s
by habitue 12y ago
I think this pain comes from using swl databases for integration, which is an antipattern in my book, and prevalent in the enterprise. Databases should have a single application talking to them, and have a service in from of them that makes it possible to get the data needed out. Services are easier to maintain backwards compatibility with, whereas databases are a massive pain to version and migrate and having to synch multiple teams to do such a job is a nightmare.
That being said, I realize its often much more convenient at the beginning to have one database for integration. SQL is much more expressive than your service's interface will be, and in the beginning this seems like a killer.
- sanderjd 12y agoI've yet to see the real payoff of a database service like you describe over simply having a central database library. Perhaps the payoff comes if you want to use multiple languages, but if you don't, then pulling all the schema versioning and db-related client code into a single library that is used anywhere it's needed solves all the problems your parent brought up.
- acveilleux 12y agoSo much this. Having had to be involved in the transfer of a DB that was used for integration from a legacy SQL DB to postgres, it was a pita (and not even my job) to deal with all the small and not so small things that broke. Especially things like monthly emailed reports and all sort of quick hack/tools that no one even remembers writing.
- dorfsmay 12y agoGood point. I don't think it is that difficult to setup at the begining, especially with the low cost of entry of REST, but forseeing what will be separate and distinguishable services early on is very hard.