It's true that it happens, but it's the antipattern of our age.
When you have seven applications written against a single database (plus a load of complex SQL that operators use for support), it becomes impractical to refactor the schema. Now your business is evolving around rotting data structures.
Companies like Oracle make their money by convincing people that they should adopt this misdesign, and then licensing expensive training, staff and technology to help manage it.
Even putting aside the management issues, databases+SQL is a synchronous communications model, so you can't stream data effectively.
Relational theory is intended to make it easier to achieve data independence, including various kinds of schema changes.
You did not offer an alternative, but I am very skeptical that whatever alternative you have in mind somehow improves matters.
"you can't stream data effectively"
If the currently available SQL products don't allow you to stream data effectively, and that's what you need to do, then use something else.
My point was what people are actually doing for IPC. And for the most part, it's using SQL databases. Even communicating between processes in a single application (e.g. related web requests served by different processes), SQL databases dominate.
If you have several different software teams all with different apps against the same database, it's a struggle to coordinate a refactor.
Often there's problems just because of subtle differences in assumptions made about data that aren't covered by the sparse type system that relational databases offer.
These are very common problems for businesses that are growing beyond their "small business" stage.
> You did not offer an alternative
* services which offer synchronous lookups over HTTP.
* services which offer interaction by custom streaming protocol.
* pipelines of data along the lines of Drake, which was on the homepage yesterday. This is similar to the batch-processing approach that dominated the mainframe era.
Each of these have lend themselves to "grandfathering" APIs as stuff changes. So when you rely on them, your teams can be flexible in ways that aren't open to you when everyone is running against a shared schema.
Also, you can write those approaches in whatever language you like, rather than being restricted to the stored procedures combinations that your DB offer, which always have poor state handing and limited concurrency mechanisms, and generally have a quirky syntax as well.
> If the currently available SQL products don't allow
> you to stream data effectively, and that's what you
> need to do, then use something else.
Once you have people starting to use a database for message passing, you'll develop an ecosystem of platform-specific stored procedures and the like.
Databasese get chosen for messaging not because they're a good solution for it, but because it's the lazy option.
Think of all the systems that start off as an access database on someone's desk, and then evolve into SQL server. And then people write several apps against them and the business is locked into the platform.
By the time you need streaming often you've already made decisions that lock you out of it.
The business can't justify a rearchitect on period-by-period accounting. So the business hits the schema harder and harder until no work is getting done. You end up with a large team of cranky database admins, testers and developers. They work hard but generate little value. Their lives are dedicated to trying to slowly shuffle the blob forward. Your infrastructure costs are now huge.
> My point was what people are actually doing for IPC
I agreed with you on that from my open. And went on to make the point that - irrespective of that - it's a bad pattern.
There are things relational databases are effective solutions for. Messaging is not one of them. A schema should be owned and interacted with by one and only one codebase. Databases should not be used as ad hoc messaging systems.