9 ms·
So in 20 years we've gone from vilifying SQL statements in code, witch-hunted folks who did this and instead invented and propped up clunky ORM implementations,
by ak39 8y ago
So in 20 years we've gone from vilifying SQL statements in code, witch-hunted folks who did this and instead invented and propped up clunky ORM implementations, ignored sage advice on the famous "object-relational impedance mismatch" (which the author claims he doesn't "believe" exists - it's not a choice btw) and now, after 20 years of agent orange in the bloody Vietnam of Computer Science, we are presenting why SQL was better all along - showing off windowing functions as examples? This is irony that took 20 years to sink in.
Am I understanding this guy's presentation correctly? (I left around the 20 min mark of the 50 min presentation).
- thegeomaster 8y agoRecently I tried using an ORM "properly" for a bigger application. I tried for days to fix the performance problems, which were mainly caused by serialization/deserialization overhead because of humongous generated queries where I didn't need 90% of the info. I finally gave up, and now most of the ORM usage in the codebase is just to communicate my custom queries to the underlying database and translate to/from domain entities. I feel like this is the sweet spot―give me a thin abstraction over SQL and do the gruntwork of converting domain entities to tables and vice-versa, but nothing else, thanks. I'm still unhappy about the performance (when everything is in the working set, query takes 2ms and returns a couple of rows but the whole API call, which doesn't do much except massage the response to some kind of JSON, takes 30ms!), but that's on me for my ORM/language/runtime choice, I suppose.
- lugg 8y agoWhat language are you using? Most languages plain sql drivers have something like a cast result row into object as you cursor over the set. E.g. PHP has fetchObject https://www.php.net/manual/en/pdostatement.fetchobject.php https://www.php.net/manual/en/pdostatement.fetchobject.php
- ak39 8y ago"I feel like this is the sweet spot―give me a thin abstraction over SQL and do the gruntwork of converting domain entities to tables and vice-versa, but nothing else, thanks." Something like iBatis/nBatis? (Haven't used this since 2004)
- lukaseder 8y agojOOQ!
- coleifer 8y agojOOQ is legit. I found it very helpful to read jOOQ as I was writing my own library in python. There's a huge difference between a query-builder and something like hibernate or sqlalchemy. Query-builders make it easy to compose queries, leaning on your programming language to enforce syntactic correctness. When you're dealing with SQL directly, composition means string concatenation. A query builder gives you a data-structure that represents a query. I think it's helpful to distinguish between query-building and object mapping when the "orm-vs-sql" thing comes up.
- michaelcampbell 8y ago*Batis is still a thing, and is closer to what they were asking for, but you're still mapping your domain to hand-coded SQL. That's not bad, necessarily; I just don't know if his "abstraction over SQL" means you write it and your domain code uses that abstraction, or it's provided by the framework.
- balfirevic 8y ago> Recently I tried using an ORM "properly" Which ORM was it, if I may ask?
- michaelcampbell 8y ago> Recently I tried using an ORM "properly" No, you weren't. > ...queries where I didn't need 90% of the info.
- nabla9 8y agoAssumption that only private consumers consume fashion, trends and "Pepsi generations" is wrong. Corporate management, consulting and engineering subfields are made of people who don't check out from their personal needs when they work. Hype cycles, fashions, scenes and subcultures exist in software engineering just like they exist in corporate management and consulting. People want new and change. SQL is the best for most database needs, but not for everything. It may seem boring if there is no marketing push that connects to emotions. SQL was established and boring for new software engineers. The emergence of "Web 2.0" in early 2000s started hype cycle for no-SQL. The 'scene' was so emotionally engaging that enterprises were abandoning SQL databases because "they don't scale" and because that's what their developers wanted to work with.
- ak39 8y agoYour analogy with fashion is useful, except it doesn't convey the wanton waste of money and time and brain cells this diversion took us through - we have come out poorer and it seems with significant loss of memory (intellectual and academic memory). Fashion choices are mostly innocuous ... this whole anti-SQL crusade was more akin to measles anti-vaccers who eventually forget the original controversies, somehow survive the ensuing epidemic only to one day stumble upon the very same measles vaccine they were against. They then present it to the infected leper colony as something new!
- lukaseder 8y agoI like this analogy given that the relational model solved all the problems of networked/hierarchical models, which preceded it. Yet, NoSQL aimed to regress towards pre-SQL times
- lugg 8y agoI'm curious about pre SQL database times. What sort of solutions were out there? What did the DBs look like before SQL was a thing? NoSQL fixes a lot of the mismatch with code models but imo doesn't really solve much else and lacks the expressive power of SQL when it comes to reporting software. I suspect most developers don't realise how much they are not the main user or consumer of SQL. (Business excel spreadsheets)
- lukaseder 8y agoPresenter here. Yes that's pretty much it. There are many more convincing reasons than window functions in the second part which focuses on the execution of a 4GL, not the development with it. Just to be clear: the talk uses hyperbolic language to make a point being that SQL is perfect for data processing, not for everything
- ak39 8y agoHi Luka, Your presentation was excellent. I'm not attacking you. I agreed with everything you said (at least the parts that I watched). My _rant_ (or attack), instead is with the _phenomenon_ we were so strongly and needlessly gripped in for two whole decades. A cult phenomenon that had all the hallmarks of religious indoctrination. You said: "Just to be clear: the talk uses hyperbolic language to make a point being that SQL is perfect for data processing, not for everything" I agree. SQL isn't useful for all cases. But those cases are few.
- lukaseder 8y agoI know you didn't attack me, just wanted to make sure the pendulum won't swing too far to the opposite side :)
- gigatexal 8y agoGive me a raw sql statement or give me death. I like the way you think.
- michaelcampbell 8y ago> Just to be clear: the talk uses hyperbolic language to make a point being that SQL is perfect for data processing, not for everything. So, there's the point.
- gigatexal 8y agoI should add this is for when working with a relational database where raw SQL is the best option. For other things say like data science python and pandas would be my go to
- lugg 8y agoI dunno. I think there is quite a lot of us that have consistently expressed the stupidity that is wrapping a powerful query language in a mediocre, limited, buggy, half baked, shoe horned into OO shit what was I saying? Oh yea, ORM. I've always veiwed it as a legitimate (though always over engineered) solution to wrap some repetitive database operations in a consistent manner. The biggest issue with ORM isn't the solution they came up with, half baked and buggy as they are, but the problem they are actually employeed to "solve": developers afraid of SQL. Whether they can't write it, can't learn it, or just straight hate the string representation in their code, it's the main reason people sign on for ORM. Then they prop it up with all manner of baseless reasoning. Theb there is the leakyness. ORMs are usually quite fluid in their language, they make it easy to represent the database in code. The only issue is that it isn't there. It's a separate thing. When you see database code it should be obvious and very far away from business logic. What does ORM do? Mix it all up On purpose. Have fun with all the mocks.
- sfilipov 8y agoI don't disagree overall but I'm using SQLAlchemy (Python) on a daily basis and it works quite well. I agree that if you are building ORM with the intention of hiding so many SQL details that the developers don't need to learn SQL, you'll run into problems. SQLAlchemy on the other hand starts simple, but is flexible enough that you can do inner/outer joins, you have different loading strategies etc. It is quite nice if you are proficient enough in SQL. When writing complicated select queries, I'd start by writing the raw SQL then spend my time representing it in SQLAlchemy. It's a bit less than double the work sometimes, but working with the SQLAlchemy objects in Python is quite nice as long as you pull them in an efficient manner. SQLAlchemy just feels like a well thought out ORM.
- lugg 8y agoNever heard of SQLAlchemy. The core part of the lib looks quite nice, the problem is its design is driven by the needs of its ORM. If you define your database properly typed, defaulted, and not null unless an update field that sort of layer isn't needed at all. Using the correct native types on your function params or class structures means you'll never run into type mismatch or cast failures loading or unloading from the db. So I just don't get why the need for ORM. The only thing that needs mapping is the table schema to your data type object/structs. ORMs don't offer anything of value their and often make things you need to do in your job harder.