51–60 of 108 posts
For a long time I was on the side of the ORM haters, until I tried SQLAlchemy - it truly is an awesome ORM package and I have yet to find anything like it in PHP/Ruby/etc...
Earlier quoted context omitted.
your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational). What if it's better structurally for the program as a whole to think about individuals?
That seems to be the question at the heart of the debate surrounding ORM's and OO in general and the debate rages on...
Earlier quoted context omitted.
The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost,…
But the truth is the days of DB being king are almost gone. These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand h…
Honestly, every time I see how badly Facebook handles data and caching, I can't help but wonder why they don't use a real data store and DBAs.
Earlier quoted context omitted.
The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost,…
But the truth is the days of DB being king are almost gone. These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand h…
The database is where you store your data. If you have data of which its integrity is critical to your organization, a properly designed and maintained database is going to save a lot of hastle.
I believe that databases will remain important, and maintaining data will always involve restrictions on how you can use it. Restricting data is not a relational database problem - it's more often than not a business constraint. Often times you don't want programmers doing stupid things with your data :-)
Earlier quoted context omitted.
The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost,…
To me it sounds like you're talking about the argument of who has the responsibility of applying business rules, the application layer or the database layer - which is another entirely valid argument in itself, but distinctly different than the argument of whether to use an ORM in your application layer or not.
I admit I have no statistics, but it's been my experience that most places choose between a highly OO model + ORM and a highly relational model without.
Earlier quoted context omitted.
IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner qu…
ORMs don't try and handle anything. People apply them poorly which simply creates bad code. The same can be said of the goto statement, or any number of other things - used improperly, they screw up everything, but in some instances they are necessary and good.
With an ORM, no matter how much tweaking you do, it is sometimes impossible to get the performance that a well written SQL query can achieve. And that's not because of bad code, or that the ORM is a bad choice.
Earlier quoted context omitted.
Django's ORM is a piece of junk compared to a proper one such as SQLalchemy, hibernate or nhibernate. I wouldn't go drawing conclusions until you've experienced something else.
If Hibernate is one of the "proper" ones, then I can happily declare ORMs to be a non-working, time-wasting, over-complicated POS.
Yet another software religious war, which seems to boil down to "if you don't think my technology is correct 100% of the time, you are insulting my honor". Do other fields get into constant pissing matches like this? Languages, libraries, process, licenses, editors, Operating systems, you name it, software engineers are fighting about how much better theirs is and how you are an idiot for not seeing the true light th…
Earlier quoted context omitted.
The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost,…
But the truth is the days of DB being king are almost gone. These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand h…
I incidentally have stopped programmers from doing X or Y, but it was because the right answer was Z.
As for ORM's winning, I don't think its a war, For some things I use and recommend ORMs, but for others I recommend using pure SQL.
Will there be downsides one day? Probably. Will they come even close to the business value of the amount of the coding time we've saved during the critical bootstrap phase? No way in hell. As they say, those are problems I'd love to have.