I'm also interested in some elaboration of this scheme. While I'm less interested in ORMs etc, the advantages/disadvantages would be useful to compare to some r

I'm also interested in some elaboration of this scheme. While I'm less interested in ORMs etc, the advantages/disadvantages would be useful to compare to some recent thoughts I've had regarding the use of databases. Professionally I have little use for RDBMSs, however recently I've been working on some side projects with a focus on flexibility and modularity that have changed my perspective on how databases should be used. Formerly, I (and I assume many newcomers) had a database driven approach where the database structure came first, and code grew around that. This reduces flexibility because your data is all coupled together, which will force refactoring of data when your storage configuration changes. Data refactoring sounds like a thing of nightmares, but ability to easily migrate data between a RDBMS-backed module to a redis-backed module with minimal fuss is the kind of flexibility I'd like to have. The alternative that I've settled on is to begin development with the notion of a generic 'data store' and later fitting a database around that. Though I am yet to see the scheme come to reality, I believe this will reduce data coupling, increase testability and debuggability for both code AND data associated with a given module, and increase migratability of the data. This has also pushed me toward the exclusive use of integers for IDs as they can be considered universally supported with minimal effort, which has me curious about further benefits of different ID generation schemes.