11–20 of 35 posts
That's why we still have that middle tier in our architectures.
Well, at the end of the day you always need server side biz logic, I'm afraid! Still, stored routines in a cloud DB might be more interesting than a full blown middle tier. The biggest problem with cloud DBs I find actually isn't so much their architecture, but rather the fuzzy rules around charging access to them.
Application code in stored procedures? Is this still a thing? SQL2003 standard was completely into it with Java as stored procedures and XML, etc. - but wasn't that just an enterprise fade with big expensive enterprise databases like Orcale/DB2/MSSQL?
It introduces a lot of headache if you update your code often - it's already hard enough with schema changes, especially if you would like to be able to roll back faulty updates. Normal code is maintained a source code repository (GIT/SVN), it can be edited, diffed and debugged using a common IDE.
But the whole world moved onto to 3-tier for a reason.
Well, at the end of the day you always need server side biz logic, I'm afraid! Still, stored routines in a cloud DB might be more interesting than a full blown middle tier. The biggest problem with cloud DBs I find actually isn't so much their architecture, but rather the fuzzy rules around charging access to them.
> stored routines in a cloud DB Application code in stored procedures? Is this still a thing? SQL2003 standard was completely into it with Java as stored procedures and XML, etc. - but wasn't that just an enterprise fade with big expensive enterprise databases like Orcale/DB2/MSSQL? It introduces a lot of headache if you update your code often - it's already hard enough with schema changes, especially if you would li…
Here's a clue, a serious project will go through a dozen languages before it changes its database. You can reimplement your business logic that many times, or do it once, properly.
Earlier quoted context omitted.
> stored routines in a cloud DB Application code in stored procedures? Is this still a thing? SQL2003 standard was completely into it with Java as stored procedures and XML, etc. - but wasn't that just an enterprise fade with big expensive enterprise databases like Orcale/DB2/MSSQL? It introduces a lot of headache if you update your code often - it's already hard enough with schema changes, especially if you would li…
In what way aren't stored procedures "normal code"? Are you claiming Git can't handle SQL files? Or that they can't be tested? Or there are no debuggers or IDEs? Here's a clue, a serious project will go through a dozen languages before it changes its database. You can reimplement your business logic that many times, or do it once, properly.
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." Pretty poor reason for choosing something.
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." Pretty poor reason for choosing something.
Not advocating Mongo here, just saying that adoption is not an irrational reason. I have mostly seen this with Java, when people tell me: We chose Java, because that's what they teach at universities and this is what developers know.
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." Pretty poor reason for choosing something.