5 ms·

Has anyone ever done this in practice before without it mattering: > 4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, Co

Has anyone ever done this in practice before without it mattering: > 4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database. MongoDB vs Oracle.. Ok architecture astronaut, you're gonna have a real bad time when you swap those out for each other.

specialist 9y ago
Your business is the database. Models matter. Anyone who wants "database neutrality" (least useful common denominator), vs leveraging the awesomeness of pgsql, mssql, oracle, should just use flat files. Or mysql.
- UK-AL 9y ago
  You can leverage whatever database feature you want, just a long as you do it in the database adapter/gateway. I write mine in raw sql normally.
  - specialist 9y ago
    Versus in situ (eg stored procedures)? I currently agree. There was a time when the database engine was the "app server". Before client/server & ODBC. I miss those days. That strategy is overdue for a comeback.
    - UK-AL 9y ago
      My raw sql can call out to stored procedure if that's the best tool for the job. A database is a perfectly good application core, if you application primary about creating/updating/deleting records. If your application is business workflows, and complicated business logic. Then this is something to be considered.
      - pmart123 9y ago
        Good to see I'm not crazy! I think this can be easier than maintain, and with tools like Datagrip now, seems to make a lot of sense. Coming from the data science side, I observed many talented people spending time on projects like https://github.com/cloudera/ibis https://github.com/cloudera/ibis to abstract SQL into something that I often thought was more verbose, less literal and less portible in reality.
- vardump 9y ago
  s/mysql/sqlite Almost foolproof.
- jlg23 9y ago
  > Your business is the database. Models matter. If you tie your model to your database, you might be out of business sooner that you think. Just ask any of the oracle customers who paid $$$ to migrate away from that license fee sinkhole. > Anyone who wants "database neutrality" (least useful common denominator), vs leveraging the awesomeness of pgsql, mssql, oracle, should just use flat files. Or mysql. Alternatively, simply invest a little bit more time into proper design and implementation. In one of my products I am "leveraging the awesomeness of pgsql" but switching to another storage engine is still a matter of one or two hours. After all, it's only about 200 lines of code: The connection itself and the adapters for the query engine (and no, it's not loosely coupled - it's strongly typed and my compiler inflects on the model and the constraints imposed on it by the storage backend).
UK-AL 9y ago
I don't think the main advantage of this is switching databases. It's switching mindset. Lots of developers think database first, then build on top of that. That's good for simple crud apps. Creating/updating/deleting stuff is what databases are good at. For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. You domain is your application core, database persistence is a technical issue outside of that core. You write an adapter to persist that domain to whatever database you want. It just so happens this means you can write many adapters for any database to persist your domain to it. Utilizing whatever advanced features your database has to speed things up in that database adapter.
- codemac 9y ago
  > For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. Yes, you should design your work first, and figure out what type of data you need to store, and how it should be stored. Just about any application that uses Oracle cannot be "adapted" to use mongodb. It's an entirely different scope, different persistence model, different features... If we were comparing mysql vs postgres, there would be novel-sized comments about how you can't just switch between them. mysql : postgres :: bicycle : recumbent bicycle mongodb : oracle :: tricycle : underwater nuclear submarine They're just soluctions to entirely different business problem domains. This kind of "if the architecture is clean enough it can run on your microwave" attitude is a disease.
  - UK-AL 9y ago
    Well if you model your domain, then if you find only a certain database can persist that domain well, then write a specific adapter for that database and stick with it. If your using DDD + OO most of the adapter will be converting to and from your persistence model and your domain model. However there are plenty of applications why there is no technical reason why they can't work on both though.

specialist 9y ago

Your business is the database. Models matter. Anyone who wants "database neutrality" (least useful common denominator), vs leveraging the awesomeness of pgsql, mssql, oracle, should just use flat files. Or mysql.

UK-AL 9y ago
You can leverage whatever database feature you want, just a long as you do it in the database adapter/gateway. I write mine in raw sql normally.
- specialist 9y ago
  Versus in situ (eg stored procedures)? I currently agree. There was a time when the database engine was the "app server". Before client/server & ODBC. I miss those days. That strategy is overdue for a comeback.
  - UK-AL 9y ago
    My raw sql can call out to stored procedure if that's the best tool for the job. A database is a perfectly good application core, if you application primary about creating/updating/deleting records. If your application is business workflows, and complicated business logic. Then this is something to be considered.
    - pmart123 9y ago
      Good to see I'm not crazy! I think this can be easier than maintain, and with tools like Datagrip now, seems to make a lot of sense. Coming from the data science side, I observed many talented people spending time on projects like https://github.com/cloudera/ibis https://github.com/cloudera/ibis to abstract SQL into something that I often thought was more verbose, less literal and less portible in reality.
vardump 9y ago
s/mysql/sqlite Almost foolproof.
jlg23 9y ago
> Your business is the database. Models matter. If you tie your model to your database, you might be out of business sooner that you think. Just ask any of the oracle customers who paid $$$ to migrate away from that license fee sinkhole. > Anyone who wants "database neutrality" (least useful common denominator), vs leveraging the awesomeness of pgsql, mssql, oracle, should just use flat files. Or mysql. Alternatively, simply invest a little bit more time into proper design and implementation. In one of my products I am "leveraging the awesomeness of pgsql" but switching to another storage engine is still a matter of one or two hours. After all, it's only about 200 lines of code: The connection itself and the adapters for the query engine (and no, it's not loosely coupled - it's strongly typed and my compiler inflects on the model and the constraints imposed on it by the storage backend).

UK-AL 9y ago

I don't think the main advantage of this is switching databases. It's switching mindset. Lots of developers think database first, then build on top of that. That's good for simple crud apps. Creating/updating/deleting stuff is what databases are good at. For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. You domain is your application core, database persistence is a technical issue outside of that core. You write an adapter to persist that domain to whatever database you want. It just so happens this means you can write many adapters for any database to persist your domain to it. Utilizing whatever advanced features your database has to speed things up in that database adapter.

codemac 9y ago
> For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. Yes, you should design your work first, and figure out what type of data you need to store, and how it should be stored. Just about any application that uses Oracle cannot be "adapted" to use mongodb. It's an entirely different scope, different persistence model, different features... If we were comparing mysql vs postgres, there would be novel-sized comments about how you can't just switch between them. mysql : postgres :: bicycle : recumbent bicycle mongodb : oracle :: tricycle : underwater nuclear submarine They're just soluctions to entirely different business problem domains. This kind of "if the architecture is clean enough it can run on your microwave" attitude is a disease.
- UK-AL 9y ago
  Well if you model your domain, then if you find only a certain database can persist that domain well, then write a specific adapter for that database and stick with it. If your using DDD + OO most of the adapter will be converting to and from your persistence model and your domain model. However there are plenty of applications why there is no technical reason why they can't work on both though.