4 ms·

Using a server RDBMS it’s trivially easy to decouple schema and query evolution from application. Curious, how do you decouple query evolution from the DB laye

• dragonwriter 5y ago
  > Curious, how do you decouple query evolution from the DB layer of your application? Use application-specific views, and the evolution driven by DB optimization, etc., can happen in view definitions without the app DB layer being involved. It’s a traditional best practice anyway, going back decades to the time when it was expected an RDBMS would serve multiple apps that you needed to keep isolated from each others changes, but it also works to isolate concerns at different levels for a single-app stack. (Because of practical limits of views in some DBs, especially in the 1990s, and developer preferences for procedural code, a common enterprise alternative substitutes stored procs for views, to similar effect.)
  • newlisp 5y ago
    Oh yes views, they are not with no effort and become numerous and specific. But are extremely missed with a document store I'm working on write now ;)
  • no-s 5y ago
    hah, exactly. “application-specific views...Going back decades”, or “substitute Stored Procs for views”. It’s not really much extra overhead to use a schema+views. I ask developers to avoid creating views with “Select *”, always specify the columns desired. Further decoupling is possibly beneficial, e.g. CQRS is wonderful perspective for designing data models that may be more easily distributed or cacheable (by explicitly choosing to separate query schema from modification schema).