4 ms·

This was the predominant architectural design about 20 years ago. There are many strong points for this the general challenges are... Databases don't/didn't h

This was the predominant architectural design about 20 years ago. There are many strong points for this the general challenges are... Databases don't/didn't have too much in the way of integration primitives... Databases can become a performance bottleneck that can only be scaled vertically... SQL language is not that great as an application programming language EDIT: forgot the biggest one which is, it is completely up to discipline to produce any kind of separation between implementation details and public api since everything lives in the database. That's really the biggest challenge.

marcosdumay 7y ago
> Databases don't/didn't have too much in the way of integration primitives... Hum... They have the best and most diverse set of integration primitives available. Services architectures (micro, SOA, and whatever) did never actually reach parity to them. Your other points are good (DBMSes do scale horizontally, but it's not easy nor nice), agreed on everything. But they still do not beat the capacity DBMSes have for integrating stuff on most applications, so this is still a good paradigm.
- apalmer 7y ago
  I am quite serious when I ask for more specifics on the types of integration primatives you are talking about? My experience has been the opposite here are some examples: Number of times I had to implement or maintain hand rolled queues in the database. Number of times I had to implement a web service whos only purpose was to expose database data to the world. Number of ETL processes I wrote just to handle some data daily data input from a third party. Number of times I had to use comparatively complex SQL techniques to iterate over a list of rows because SQL is intended for set based operations not iterative processing .. Number of times I had to do tedious text templating to generate HTML or XML or JSON or any kind of heirarchical data format that is easily consumable by a non database system. That's what I am talking about Which isn't to say this is a bad architecture. Just that database as integration platform has its challenges, a lot of them.

marcosdumay 7y ago

> Databases don't/didn't have too much in the way of integration primitives... Hum... They have the best and most diverse set of integration primitives available. Services architectures (micro, SOA, and whatever) did never actually reach parity to them. Your other points are good (DBMSes do scale horizontally, but it's not easy nor nice), agreed on everything. But they still do not beat the capacity DBMSes have for integrating stuff on most applications, so this is still a good paradigm.

apalmer 7y ago
I am quite serious when I ask for more specifics on the types of integration primatives you are talking about? My experience has been the opposite here are some examples: Number of times I had to implement or maintain hand rolled queues in the database. Number of times I had to implement a web service whos only purpose was to expose database data to the world. Number of ETL processes I wrote just to handle some data daily data input from a third party. Number of times I had to use comparatively complex SQL techniques to iterate over a list of rows because SQL is intended for set based operations not iterative processing .. Number of times I had to do tedious text templating to generate HTML or XML or JSON or any kind of heirarchical data format that is easily consumable by a non database system. That's what I am talking about Which isn't to say this is a bad architecture. Just that database as integration platform has its challenges, a lot of them.