5 ms·

Do you have multiple separate apps that can change a shared DB schema? How do you keep that all in sync across your apps?

by sbarre 1y ago

int_19h 1y ago
In situations like these, the database admins are the ones responsible for the schema; the apps are mere users.
scott_w 1y ago
So usually one is the “main” but, personally speaking, I’d just say “don’t do it,” for the obvious issues I suspect you’re aware of ;-) By “don’t do it,” I mean having multiple apps talk to one DB schema.
- throwaway7783 1y ago
  "don't do it" is the right answer. Others have pointed it out as well, many large SaaS companies I worked with, have had apps owning their databases. Anyone else needs anything - use APIs (and ETL if you need everything)
  - ecb_penguin 1y ago
    It's definitely not the right answer. It's actually the completely wrong answer. Services are slow, restrictive, and don't enjoy the benefits of an actual DBMS, like transactions. You also add additional dependencies and failure points.
    - scott_w 1y ago
      This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.
      - ecb_penguin 1y ago
        > Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other. All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates. As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reason for what you're proposing.
        throwaway7783 1y ago
        I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.
        ecb_penguin 1y ago
        > a schema update is accompanied by application updates 1. DB -> App = Two updates, the schema and the app 2. DB -> Service -> App = Three updates, the schema, the service, and the app In both cases, obviously the DB changes. In both cases, obviously the App changes. In the second case, you also get to update your services.
        scott_w 1y ago
        No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.
        ecb_penguin 1y ago
        > No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. Literally everything you just said applies to services and API contracts as well. You haven't solved anything. > the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder. "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument. I'd work to fix the communication problem before I adopted a terrible tech solution.

Do you have multiple separate apps that can change a shared DB schema? How do you keep that all in sync across your apps?

by sbarre 1y ago

Do you have multiple separate apps that can change a shared DB schema? How do you keep that all in sync across your apps?

int_19h 1y ago

In situations like these, the database admins are the ones responsible for the schema; the apps are mere users.

scott_w 1y ago

So usually one is the “main” but, personally speaking, I’d just say “don’t do it,” for the obvious issues I suspect you’re aware of ;-) By “don’t do it,” I mean having multiple apps talk to one DB schema.

throwaway7783 1y ago
"don't do it" is the right answer. Others have pointed it out as well, many large SaaS companies I worked with, have had apps owning their databases. Anyone else needs anything - use APIs (and ETL if you need everything)
- ecb_penguin 1y ago
  It's definitely not the right answer. It's actually the completely wrong answer. Services are slow, restrictive, and don't enjoy the benefits of an actual DBMS, like transactions. You also add additional dependencies and failure points.
  - scott_w 1y ago
    This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.
    - ecb_penguin 1y ago
      > Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other. All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates. As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reason for what you're proposing.
      - throwaway7783 1y ago
        I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.
        ecb_penguin 1y ago
        > a schema update is accompanied by application updates 1. DB -> App = Two updates, the schema and the app 2. DB -> Service -> App = Three updates, the schema, the service, and the app In both cases, obviously the DB changes. In both cases, obviously the App changes. In the second case, you also get to update your services.
        scott_w 1y ago
        No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.
        ecb_penguin 1y ago
        > No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. Literally everything you just said applies to services and API contracts as well. You haven't solved anything. > the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder. "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument. I'd work to fix the communication problem before I adopted a terrible tech solution.