From: Phillip Gawlowski Date: 2010-11-15T02:41:30+09:00 Subject: Re: ORM's - Don't Do It! On Sun, Nov 14, 2010 at 6:20 PM, Robert Klemme wrote: > You would apply the very same reasoning when creating classes for a > particular problem domain so normalization isn't really that esoteric for > someone doing OO development. Absolutely, and I never said otherwise. No matter what tool one uses, you don't get around the fact that you have to think about what you are dealing with, how to deal with it, and which tool to use. >> No, it doesn't. SQL's syntax is unlike any programming language I >> know. Pure SQL contains no looping constructs, for example. It can >> only retrieve and store data. > > Since the advent of Analytical SQL you can do amazing things in a single > query. :-) I'm also aware of the trigonometric and geospatial functions modern databases provide. Doesn't mean that SQL gets prettier, or any more useful (the issue actually begets the question of separation of concerns, which is a whole other kettle of fish). > I don't think the *representation* is so much more sophisticated - if at > all.  It's the *storage* of and *access* to the data which is extremely > sophisticated in modern RDBMS.  IMHO the two main features of RBDMS are > efficient management of large volumes of data and maintaining integrity > (transaction management). Absolutely. Which is why I happily use an ACID compliant database any day (unless a simple text file is easier to deal with, but that's only true in few circumstances, like log files, config files, and such). > This is the standard argument for ORM and it is true in many situations. >  However, there are some grains of salt to be taken with this: unfortunately > the exact fact that you do not have to care about the DB underneath can lead > to serious issues because it lowers the awareness level for database > peculiarities - and I am not only talking about differences in SQL dialects. >  The more important things that someone creating an application which uses a > RDBMS should be aware of are concurrency models and performance.  If you > create an application which is exposed to the internet (or any other > potentially "unlimited" number of users) you need to take these aspects into > consideration otherwise you'll learn too late that the design you chose does > not work. :-} This is such a generalized statement, it is true in pretty much all circumstances: You *have* to be aware of the limitations your chosen toolset has. Using an ORM library doesn't excuse you from thinking about the database (it "merely" makes working with the DB easier), nor does the lack of an ORM excuse you from thinking about how to map the data to the program model. There are no silver bullets, and every abstraction is a trade off. We use Ruby, for example, because we prefer an expressive syntax and dynamic features about the line noise of C despite C's better performance in some circumstances. > Just one example: often ORM are ideal to retrieve one or few objects, > manipulate them in memory and store them later.  Even a seemingly simple > task like "up salary of everyone in marketing by 5%" can be tedious with > ORM.  Typically "UPDATE EMP SET sal = sal * 1.10 WHERE dept = 'marketing'" > is far more efficient than an ORM solution - unless the ORM supports mass > data updates via special mechanisms. Obviously. But for mass updates, I rather grab a script and fire that off against the DB itself, than use a database abstraction layer of any kind. It's simply faster. Similarly for moving data into a database. Using an ORM layer and such slows things down too much for little to no benefit (I'd hate to move any non-trivial dataset via ActiveRecord and its migration semantics, for example). TL;DR: No choice of tools is superior in all circumstances. Never was, never will be. But if you decide to agitate against a specific set of tools because of what amounts to religious fundamentalism and with righteous preaching, I'm happy to apply a 4x2 clue any day. -- Phillip Gawlowski Though the folk I have met, (Ah, how soon!) they forget When I've moved on to some other place, There may be one or two, When I've played and passed through, Who'll remember my song or my face.