4 ms·

Exactly! How about "developers have failed the databases" The majority of the developers don't use (or don't know how to) views/stored procedures/roles/triggers

Exactly! How about "developers have failed the databases" The majority of the developers don't use (or don't know how to) views/stored procedures/roles/triggers. Whenever you mention something like this you hear "omg, you put business logic in the db? everybody knows that does not scale" or "we deconstruct our request into a few simple queries instead of a join so we run super optimal"

sk5t 10y ago
> deconstruct our request into a few simple queries Makes sense if you can cache only portions of the result, and/or the query optimizer or database layout actually struggle with the join.
cr0sh 10y ago
I agree that more business logic needs to be "closer" to the DB - if not in the DB itself (using those facilities you mentioned), then at a level very nearby. There's a very good reason for this: Showing a consistent interface for data update and query. When there are multiple teams developing against the same DB server, they might be able to see most or all of the tables, but they each might implement updates/selects (SQL queries) that exhibit extremely different results - which either present or update the data in potentially incompatible or inconsistent ways. This ultimately manifests itself as errors/bugs which can be very difficult to figure out what went wrong where and why (and correcting the data becomes a nightmare). Things get even worse when you have people querying the data via ad-hoc methods (like ODBC to an Excel file or something weird like that). Essentially, it is possible (likely) that every team sees a slightly (or greatly) different view from each other. Coupling the BL closer to the DB level would prevent this; whether via the tools mentioned (views, triggers, etc) or something else. Ultimately, app developers shouldn't be hitting the DB tables directly, but going through these interfaces. Of course - that brings up a host of problems on its own (table updates become an issue of coordination and conflict between teams, etc) - and there's also the issue of implementing versioning of the business logic (and how that relates to current/past DB structure)... ...but implementing it would solve a lot of headaches (and create more I guess). /sigh
agentultra 10y ago
I suspect it's because many developers are introduced to programming through web development. The pedagogy fails them and they go on to successful careers believing falsehoods. It's hard enough to learn a programming language the first time that I can see how ORMs and frameworks relieve the burden of having to learn SQL, RDBMSs, etc. However it's a convenient lie that seems to rarely ever be corrected. The reality is that ORMs are exactly the wrong abstraction. They introduce premature pessimization into your application. They are not structured around how your data should be designed but how data-structures in your language of choice are designed. And left uncorrected they lead many developers to the mistaken belief that RDBMSs are slow, inflexible, etc, etc. It turns out that relational algebra gives us great tools for querying complex data structures and relationships and building consistent, correct abstractions. RDBMS servers have great facilities for managing and interacting with our data. Procedural languages, authentication, authorization, inter-process communication, etc, etc.
- ruslan_talpa 10y ago
  I also have a theory about this when it comes to a bit older devs (like 30+, yours i think relates to younger ones). We've entered our careers in the days of php4 and mysql4 and in those days if i remember correctly, mysql did not have all these nice features postgres has today and also the query planner was not that powerful, joins indeed were painful. We did not have access to databases like Oracle so this is where the culture of fat middle layer comes from, because it was the only way. But ppl, 15 years have passed, databases are monsters now, postgres can do 1.5M tps on a single box. How many of you are working on projects with that kind of scale ...

sk5t 10y ago

> deconstruct our request into a few simple queries Makes sense if you can cache only portions of the result, and/or the query optimizer or database layout actually struggle with the join.

cr0sh 10y ago

I agree that more business logic needs to be "closer" to the DB - if not in the DB itself (using those facilities you mentioned), then at a level very nearby. There's a very good reason for this: Showing a consistent interface for data update and query. When there are multiple teams developing against the same DB server, they might be able to see most or all of the tables, but they each might implement updates/selects (SQL queries) that exhibit extremely different results - which either present or update the data in potentially incompatible or inconsistent ways. This ultimately manifests itself as errors/bugs which can be very difficult to figure out what went wrong where and why (and correcting the data becomes a nightmare). Things get even worse when you have people querying the data via ad-hoc methods (like ODBC to an Excel file or something weird like that). Essentially, it is possible (likely) that every team sees a slightly (or greatly) different view from each other. Coupling the BL closer to the DB level would prevent this; whether via the tools mentioned (views, triggers, etc) or something else. Ultimately, app developers shouldn't be hitting the DB tables directly, but going through these interfaces. Of course - that brings up a host of problems on its own (table updates become an issue of coordination and conflict between teams, etc) - and there's also the issue of implementing versioning of the business logic (and how that relates to current/past DB structure)... ...but implementing it would solve a lot of headaches (and create more I guess). /sigh

agentultra 10y ago

I suspect it's because many developers are introduced to programming through web development. The pedagogy fails them and they go on to successful careers believing falsehoods. It's hard enough to learn a programming language the first time that I can see how ORMs and frameworks relieve the burden of having to learn SQL, RDBMSs, etc. However it's a convenient lie that seems to rarely ever be corrected. The reality is that ORMs are exactly the wrong abstraction. They introduce premature pessimization into your application. They are not structured around how your data should be designed but how data-structures in your language of choice are designed. And left uncorrected they lead many developers to the mistaken belief that RDBMSs are slow, inflexible, etc, etc. It turns out that relational algebra gives us great tools for querying complex data structures and relationships and building consistent, correct abstractions. RDBMS servers have great facilities for managing and interacting with our data. Procedural languages, authentication, authorization, inter-process communication, etc, etc.

ruslan_talpa 10y ago
I also have a theory about this when it comes to a bit older devs (like 30+, yours i think relates to younger ones). We've entered our careers in the days of php4 and mysql4 and in those days if i remember correctly, mysql did not have all these nice features postgres has today and also the query planner was not that powerful, joins indeed were painful. We did not have access to databases like Oracle so this is where the culture of fat middle layer comes from, because it was the only way. But ppl, 15 years have passed, databases are monsters now, postgres can do 1.5M tps on a single box. How many of you are working on projects with that kind of scale ...