4 ms·

> schema, enforced declaratively at the application layer Nobody has just one app forever. Any org that gets big enough is going to be uncertain about how many

> schema, enforced declaratively at the application layer Nobody has just one app forever. Any org that gets big enough is going to be uncertain about how many apps depend on a particular database, much less whether they’re all in the same language and bundle the same schema rules. Customer service builds weird support tools, accounting and compliance build weird reports …

lmm 5y ago
Make sure each datastore has a clear owner, and access it via that API rather than directly. If you really must share a datastore, use a schema registry. Sharing between multiple applications doesn't really work for SQL database either (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks).
- tdrdt 5y ago
  This only works in theory. In reality sometimes access via an API is way too slow or is lacking flexibility. And I don't get this: "(e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks)" Isn't this why transactions exist in the first place?
  - belk 5y ago
    depends on what level of isolation and how it's done, MVCC avoids deadlocks, but if you manually lock any row/table, you can still run into deadlocks. but the DBMS' transaction manager will notice and timeout one of the transactions, failing it. While MVCC avoids deadlocks, you'll still get a lot of failed transactions if they all operate on the same data at the same time, which you'll have to retry, but I'll take that over data inconsistency
- irishsultan 5y ago
  > (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks). That assumption is only true if the DB is continually used by different applications. The reality is more likely a large number of applications used by a relatively small set of users, so most of the time there won't be any application writing, and it would be extremely rare for multiple applications to write at the same time.
  - smorgusofborg 5y ago
    Are rare deadlocks better than frequent ones? That sounds like a good way to not know you have problems.
- nine_k 5y ago
  Quite often you have several applications that look up each other's data, but mostly write to their own tables. (But indeed, with uncoordinated development, deadlocks can occur. Still better than data corruption.)

lmm 5y ago

Make sure each datastore has a clear owner, and access it via that API rather than directly. If you really must share a datastore, use a schema registry. Sharing between multiple applications doesn't really work for SQL database either (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks).

tdrdt 5y ago
This only works in theory. In reality sometimes access via an API is way too slow or is lacking flexibility. And I don't get this: "(e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks)" Isn't this why transactions exist in the first place?
- belk 5y ago
  depends on what level of isolation and how it's done, MVCC avoids deadlocks, but if you manually lock any row/table, you can still run into deadlocks. but the DBMS' transaction manager will notice and timeout one of the transactions, failing it. While MVCC avoids deadlocks, you'll still get a lot of failed transactions if they all operate on the same data at the same time, which you'll have to retry, but I'll take that over data inconsistency
irishsultan 5y ago
> (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks). That assumption is only true if the DB is continually used by different applications. The reality is more likely a large number of applications used by a relatively small set of users, so most of the time there won't be any application writing, and it would be extremely rare for multiple applications to write at the same time.
- smorgusofborg 5y ago
  Are rare deadlocks better than frequent ones? That sounds like a good way to not know you have problems.
nine_k 5y ago
Quite often you have several applications that look up each other's data, but mostly write to their own tables. (But indeed, with uncoordinated development, deadlocks can occur. Still better than data corruption.)