Just to argue the other side,

Dražen Gemic <usenet@local.machine> wrote:

Right, so you write a class, AND code to retrieve database fields and
store them in the HashMap, AND code to retrieve values from the HashMap
and store them in an object.  Then you write half your code to use
HashMap and the other half to use objects.  And this is less code than
using an ORM product?  No, it's clearly not.  What's more, it implies
that you're writing a considerable portion of your code in a procedural
style, which probably has to do with the desire to avoid writing the
code that you'd get for free with an ORM product.

You're also ignoring the remainder of ORM.  You haven't addressed how to
model associations of data, choose between lazy and eager loading of
associations, enforce pre-loading of lazy association fields prior to
disconnecting from the database, express searches and search criteria.  
Surely you could solve those problems, but you'd surely end up writing a
good bit more code that is reasonable for someone to maintain just to
write a bit of database code.

This depends on the application.

Among other projects, one of the things I'm doing for work involves
using a database to retrieve data that's used in a kind of analysis that
takes far more time in computation than the database takes to retrieve
information.  In fact, the computation is so long that we limit the
amount of time spent on it and apply heuristics to finish with a
reasonable answer when the time limit is up.  The more time is spent
comparing strings in the HashMap, the less time is spent analyzing the
data.

(In case you're curious, it has to do with analyzing large numbers of
something like journal entries and trying to identify different entries
that use the same vocabulary in as close as possible to the same
grammatical forms; except that grammatical forms is defined in a way
that's defined recursively so that it also applies to paragraph
structure, etc.  The point is, the more computation time, the better the
results.  We cache only a certain amount of the text in memory at once,
but enough that we never have the computation threads waiting on the
thread that retrieves new data; they've always got other things they can
do.)

This may be a case in which you'd build classes... so fine, but you've
now eliminated this application from places where it makes sense to use
your HashMap approach.  There are surely others like it.  The entire
world doesn't consist of writing CRUD web apps.  If all you do is write
CRUD web apps, then Google -> "Ruby on Rails", except that then you
might soon be out of a job.

Hold on... you write config, OR you write annotated code.  Not both.  
The only time you'd write both is if you were trying to fit an existing
database schema to an existing class model, in which case your HashMap
idea is clearly useless anyway.

On Mon, 29 May 2006 00:21:37 +0800, Dra¾en Gemiæ wrote
(in article <e5ci1f$bup$1@magcargo.vodatel.hr>):

you are really going to have some fun later ;-), sticking stuff into a
database as an hashmap object is akin to encryption.

it's not searchable, structure is fixed, unless you de-serialize all your
records, change their structure & re-serialize, and put them back into the
database.

also you cannot partition your database easily.

Steve