271–280 of 654 posts
Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.
I really don't get why people feel like non-ORMs cause boilerplate. I write the same amount of code using Micro ORMS. Type safe. No SQL. Very happy.
Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case. In both cases, one is a higher level abstraction over the lower level capabilities, which can provide a quite large gain in usability and ability to easily understand what is going on at the level you are working at, for the loss of hand optimizing at a low level to get just what you want in every…
Everyone should know sql, but choose an ORM (micro-ORM) that doesn't have any abstractions, and gets data in and out. There are many solutions that offer you this without needing to write any SQL.
https://github.com/CollaboratingPlatypus/PetaPoco
https://github.com/ServiceStack/ServiceStack.OrmLite
Micro ORMs is where it's at. You're asking for trouble if you choose something that does WAY more than it should, like Entity Framework.
Earlier quoted context omitted.
So, SQL is the shovel, correct?
The typical language people use is imperative language where you state how to do something, while sql is a declarative language where you say what you want. Since we are in the world of analogies, using an ORM is like taking a shovel and using it as a prop (without speaking) to explain excavator operator where to dig, how deep, how wide, what things to avoid etc. Except querying a database can be much more complicate…
Whereas, the mini-ex is a complex hydraulic machine requiring regular maintenance and an operator that knows how to use the controls, and a fuel source. Lots of dependencies.
There was a youtube video of a group of men using shovels cooperatively to ‘throw’ cement:
This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
Sometimes you just should live with duplicated code. It's OK.
For example, a company with many data analysts/scientists who may each be writing their own queries. As a basic example, the definition of some “very important” company metric changes, then there would need to be a large number of disperse queries to change.
But an ORM isn’t the answer for the above situation either.
Earlier quoted context omitted.
> ORMs are hard for a reason. Yes, the object-relational impedance mismatch. It's the classic case of having a hammer (OOP) and trying to make everything look like a nail.
I would actually let OOP off the hook here. I think what did the harm in this case was the java generation. The generation of programmers that were told that in the future they would only have to write the "business logic", and everthing else would just happen. They were taught javabeans, orms, gigantic frameworks. They completely forgot that their code actually needed to execute, and no one cared about their "busine…
Are they simpler when it comes to matching the data to the application's data structures? One advantage of ORMs is that they encourage this setup from the start.
This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
Here's your problem
There's a sensible middle ground here, although I agree with the thrust of the message because using an ORM doesn't obviate the need to learn SQL - something I think a lot of developers forget. The other extreme from using an ORM "for everything" is using SQL "for everything", either via loads of handwritten ad hoc SQL, or stored procedures, UDFs, views, or a mix of all of these. This is just a different nightmare. A…
This is really where it's at. Seriously people. Nobody should be writing raw SQL.
Give me just enough of an ORM/abstraction to give me type-safety, leave the rest at the door.
Earlier quoted context omitted.
Sometimes you just should live with duplicated code. It's OK.
Thank you! You just said something I very much agree to but never dare to say out loud.
> Well, redundancy and dependency both have downsides, but in this case...
Will tend to agree with the author. Initially ORMs can save time when developing as you get an easy mapping between objects and the database. However in practise ORM tends to give you quite horrible JOINs that quite frankly are hard to understand for humans. Further more I think that ORM can lead to a bad practice in the sense that you do not need to think about your data layout first. But for database performance da…
This is completely false. The joins I do in the ORM are completely transparent to me as a developer and there is no mismatch whatsoever. The data layout and data migrations are well described. And I have, at most, a half dozen difficult queries which require serious optimization, and that optimization isn't defined by the query but by the indexing and storage strategy for the tables in question.
How many of these are a result of of features that have nothing to do with getting data in and out of the database.
Get bare metal. Anything caked on adds friction.
That doesn't mean "write raw SQL". That means I want just enough of an ORM to give me type-safety for my queries and updates. Leave the rest at the door.