3 ms·

This was for long time the "correct" way to think about this. Let me show you why is insane. Imagine you work on Java. Do you build a DSL/Transpiler to Java s

by mamcx 9y ago

This was for long time the "correct" way to think about this. Let me show you why is insane. Imagine you work on Java. Do you build a DSL/Transpiler to Java so you MAYBE could change later to C#? A RDBMS is even more important that the glue code. Why hide it, why think is something "easy" to trow away? Why think is nut to code most or all the code on it?

kodablah 9y ago
> Imagine you work on Java. Do you build a DSL/Transpiler to Java so you MAYBE could change later to C#? Why would I do such a thing? I rarely ever promote abstraction for abstraction's sake and will in almost all cases disagree with premature abstraction. There are levels and for simple CRUD things, a thin contract over your DB is a reasonable tradeoff. > A RDBMS is even more important that the glue code. Why hide it, why think is something "easy" to trow away? I don't think you even need glue code. You just need a well-specified contract. You don't want to throw away anything of course. > Why think is nut to code most or all the code on it? I don't think that. Often it can be prudent to use plsql/triggers for things. Doesn't mean the frontend of your web app needs to build the SQL in the JS though, right? Just a high level "DoThing" contract with a description of what it should do is fine.
- dagss 9y ago
  In many projects the database is way more important than the "backend" or what have you. Business logic in SQL (DB table schemas is 80% of business logic anyway...); Java or Python or whatever is just some glue to connect user interface or API to database. (I think "glue code" in parent referred to "what is not the UI or DB" BTW, i.e. the "Java app".) When the database is the most fundamental thing, then trying to abstract away the database can be a bit like trying to abstract away the programming language you are using. I have code where I would much rather rewrite the "backend" in another language than swap out the database. I think it was a very good analogy to say that abstracting over database is a bit like abstracting over what programming language you are using.

by mamcx 9y ago

kodablah 9y ago

> Imagine you work on Java. Do you build a DSL/Transpiler to Java so you MAYBE could change later to C#? Why would I do such a thing? I rarely ever promote abstraction for abstraction's sake and will in almost all cases disagree with premature abstraction. There are levels and for simple CRUD things, a thin contract over your DB is a reasonable tradeoff. > A RDBMS is even more important that the glue code. Why hide it, why think is something "easy" to trow away? I don't think you even need glue code. You just need a well-specified contract. You don't want to throw away anything of course. > Why think is nut to code most or all the code on it? I don't think that. Often it can be prudent to use plsql/triggers for things. Doesn't mean the frontend of your web app needs to build the SQL in the JS though, right? Just a high level "DoThing" contract with a description of what it should do is fine.

dagss 9y ago
In many projects the database is way more important than the "backend" or what have you. Business logic in SQL (DB table schemas is 80% of business logic anyway...); Java or Python or whatever is just some glue to connect user interface or API to database. (I think "glue code" in parent referred to "what is not the UI or DB" BTW, i.e. the "Java app".) When the database is the most fundamental thing, then trying to abstract away the database can be a bit like trying to abstract away the programming language you are using. I have code where I would much rather rewrite the "backend" in another language than swap out the database. I think it was a very good analogy to say that abstracting over database is a bit like abstracting over what programming language you are using.