4 ms·

While I see what you mean, I think, personally, the point is moot and also applies to any scripting language. If you have someone in your org specialized on SQ

While I see what you mean, I think, personally, the point is moot and also applies to any scripting language. If you have someone in your org specialized on SQL debugging stored procedures is their job. By now there are also many sufficient tools, that will help you actually debug the code and it has been a first class citizen in visual studio for years now. Also keep in mind, that most APIs are crud, not complex businness logic and that there is a middle ground: build your own libraries instead of microservices and share those. This of course all is heavily debateable and only based on my personal experience, but your statistics are missing the value for the amount of people who are actually "good at sql". Also a lot of people dont understand the value of relational data at all. So yeah, if you never learned to code you cant program. Sql is not just a second class citizien of your stack that "stores stuff" and of course you have to optimize your use cases, but again this is exactly what i mean with my top comment: you sir are dogmatic too :D SQL is AMAZING and can be directly conected to your frontend. That does not mean its a smart thing to do.

KronisLV 4y ago
There are some pretty good points in your comment and I'll agree that context is key here - the project, the team and even particular tech choices will have a lot of impact on what exactly you'll be dealing with and what might be the correct tool for the job. > This of course all is heavily debatable and only based on my personal experience, but your statistics are missing the value for the amount of people who are actually "good at sql". That said, one cannot just optimize for people who are good at a particular technology and instead one needs to look at the market averages, for the locale that they're in (unless they have that many choices of what culture to work in in the first place). In my case, where I am, we are still mostly on board with ACID and RDBMSes, however DBAs are, while not exactly a fleeting career, on the downturn (probably about 20 years away from being as obsolete as "GlassFish Server Manager", much like the DevOps trend digs into Ops engineer positions). Sure, most people are okay with running EXPLAIN PLAN occasionally, but putting significant amounts of logic in the DB is usually a pain to deal with. I've seen first hand how much of a dumpster fire a system that has like 90% of the logic in the DB eventually gets: stored procedures for rendering forms, stored procedures for data validations, stored procedures for persisting data, with absolutely ALL of the issues that I mentioned before. Making changes in it was a mess, figuring out which of the hundred or so packages even needed the changes was a pain, the naming was nonsensical (due to length limitations for DB objects), it's like someone tried coding in a language that wasn't meant for writing proper code. Of course, I've also seen some bad projects in the more traditionally tiered architectures, but none were as bad as the DB-centric design. That's my anecdotal experience, on which I'll base most of my future tech stack decisions. Of course, sometimes in-database processing is just the right way to go about things, especially in something like PostGIS where you don't have many options app-side for handling certain kinds of operations on the data, or need to do them without N+1 issues or too much network I/O due to latency.
- jhoelzel 4y ago
  Oh I agree here, my eyes also have seen terrible things. I think one of the major points im trying to make is the same basis as old school distributed communication. Generate a Data Access Layer( https://en.wikipedia.org/wiki/Data_access_layer https://en.wikipedia.org/wiki/Data_access_layer ). That does not mean that you should be DB-centric, but DATA-Centric. If your stack is written in one language, create a lib, that will be the key in going forward. Application logic as a whole can be distributed throughout thousands of services but your DAL should be a common base. - at least for things that are in one database - Here you can use procs, views or queries depending on what you like, but once i hit a couple of million guid entries in a db, i can in fact sometimes strip seconds of queries by saving on the round trip. Especiall in ERP Apps that "need to have all the data allways". Dont convert everything to stored procs of course because then you are just as unflexible as having a microservice per entity. All in all, I don't believe databases are ever gonna go away and that dbas are still underrated, even though data is gold. As we have seen with machine learning, well defined data sets are the key to better models, meaning faster and quicker results.

KronisLV 4y ago

There are some pretty good points in your comment and I'll agree that context is key here - the project, the team and even particular tech choices will have a lot of impact on what exactly you'll be dealing with and what might be the correct tool for the job. > This of course all is heavily debatable and only based on my personal experience, but your statistics are missing the value for the amount of people who are actually "good at sql". That said, one cannot just optimize for people who are good at a particular technology and instead one needs to look at the market averages, for the locale that they're in (unless they have that many choices of what culture to work in in the first place). In my case, where I am, we are still mostly on board with ACID and RDBMSes, however DBAs are, while not exactly a fleeting career, on the downturn (probably about 20 years away from being as obsolete as "GlassFish Server Manager", much like the DevOps trend digs into Ops engineer positions). Sure, most people are okay with running EXPLAIN PLAN occasionally, but putting significant amounts of logic in the DB is usually a pain to deal with. I've seen first hand how much of a dumpster fire a system that has like 90% of the logic in the DB eventually gets: stored procedures for rendering forms, stored procedures for data validations, stored procedures for persisting data, with absolutely ALL of the issues that I mentioned before. Making changes in it was a mess, figuring out which of the hundred or so packages even needed the changes was a pain, the naming was nonsensical (due to length limitations for DB objects), it's like someone tried coding in a language that wasn't meant for writing proper code. Of course, I've also seen some bad projects in the more traditionally tiered architectures, but none were as bad as the DB-centric design. That's my anecdotal experience, on which I'll base most of my future tech stack decisions. Of course, sometimes in-database processing is just the right way to go about things, especially in something like PostGIS where you don't have many options app-side for handling certain kinds of operations on the data, or need to do them without N+1 issues or too much network I/O due to latency.

jhoelzel 4y ago
Oh I agree here, my eyes also have seen terrible things. I think one of the major points im trying to make is the same basis as old school distributed communication. Generate a Data Access Layer( https://en.wikipedia.org/wiki/Data_access_layer https://en.wikipedia.org/wiki/Data_access_layer ). That does not mean that you should be DB-centric, but DATA-Centric. If your stack is written in one language, create a lib, that will be the key in going forward. Application logic as a whole can be distributed throughout thousands of services but your DAL should be a common base. - at least for things that are in one database - Here you can use procs, views or queries depending on what you like, but once i hit a couple of million guid entries in a db, i can in fact sometimes strip seconds of queries by saving on the round trip. Especiall in ERP Apps that "need to have all the data allways". Dont convert everything to stored procs of course because then you are just as unflexible as having a microservice per entity. All in all, I don't believe databases are ever gonna go away and that dbas are still underrated, even though data is gold. As we have seen with machine learning, well defined data sets are the key to better models, meaning faster and quicker results.