2 ms·

You can have a SQL database and still end up with assumptions about the data smeared across your codebase. I've worked on multi-million line codebases on top of

by Joeri 6y ago

You can have a SQL database and still end up with assumptions about the data smeared across your codebase. I've worked on multi-million line codebases on top of a SQL database where nobody dared change the schema of some (very non-optimal) tables because too much code directly depended on the structure of those tables. Having a clean and DRY data access layer is necessary regardless of the underlying database. As soon as multiple independent codebases share the same database I would argue you need to put an API on top of that database and turn it into a microservice that owns its database. Otherwise the internal details of how the tables are structured will wrap itself into the codebases and make it very hard to evolve the database's schema.

jacques_chester 6y ago
This is where views shine. "It's microservices for data!"
dragonwriter 6y ago
> Having a clean and DRY data access layer is necessary regardless of the underlying database. SQL databases (via views and even sprocs) allow you to abstract particular client’s view of the data from the base storage layer inside the database. > As soon as multiple independent codebases share the same database I would argue you need to put an API on top of that database and turn it into a microservice that owns its database. An RDBMS is is an integrated service that owns its own datastore with a very-well-defined, extremely battle-tested API designed to support multiple clients with completely different views of and access to the data, all as logically isolated as necessary from the design of the base storage layer. If you aren't using an RDBMS, sure you may need to wrap something around the datastore that provides a tricky-to-get-right subset of what an RDBMS provides fairly trivial-to-use facilities for out of the box, just like like not using an RDBMS often forces you to do for another subset if you are concerned about integrity.
nojokes 6y ago
Corollary: do not let multiple applications to access the same database objects.

by Joeri 6y ago

jacques_chester 6y ago

This is where views shine. "It's microservices for data!"

dragonwriter 6y ago

> Having a clean and DRY data access layer is necessary regardless of the underlying database. SQL databases (via views and even sprocs) allow you to abstract particular client’s view of the data from the base storage layer inside the database. > As soon as multiple independent codebases share the same database I would argue you need to put an API on top of that database and turn it into a microservice that owns its database. An RDBMS is is an integrated service that owns its own datastore with a very-well-defined, extremely battle-tested API designed to support multiple clients with completely different views of and access to the data, all as logically isolated as necessary from the design of the base storage layer. If you aren't using an RDBMS, sure you may need to wrap something around the datastore that provides a tricky-to-get-right subset of what an RDBMS provides fairly trivial-to-use facilities for out of the box, just like like not using an RDBMS often forces you to do for another subset if you are concerned about integrity.

nojokes 6y ago

Corollary: do not let multiple applications to access the same database objects.