What do you mean by “associations”? If you mean the association entity in a many-to-many relationship then again this is a simple matter of generating the right SQL query in the right place. Once I know what SQL query I need to solve my problem then as far as I am concerned the problem is solved.

http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/comment-page-1/#comment-2440

The way I see it, you recommend carrying out data modelling and using the data model as the object model. This is one way of implementing the data access layer. Your solution works on the thought process that OO model is unnecessary. If that is the case, need for ORM ceases to exist. The question that remains is what if you need to model OO paradigm like inheritance, associations etc? Is that possible in your approach?

I would appreciate if you could provide a link to your said post.

A mix of both KeyValue (“hash”), and Property may also be used.

> ORM is designed to simplify complex relationship of RDBMS.

Are you implying that you can only handle complex relationships with an ORM? If so you are sadly mistaken. I have an ERP application with over 200 tables and 350 relationships and *NO* ORM.If I can do it then anybody can.

> The object and relational world represent two different
> paradigms. Both should be developed independently to
> utilize their individual paradigm specific best practices.

It is possible to employ sound Object Oriented techniques in your application code *AND* keep synchronised with the relational structure *WITHOUT* using a second Object Oriented Design which produces a conflicting and mismatched structure. See my post dated March 2, 2012 at 03:41 which describes how I deliberately avoid the OOD step as it is totally redundant. This enables me to produce an application which does *NOT* have any mismatch between my Object and Relational structures, therefore I do not need to pollute my code with that abomination called an ORM. As for “best practices” there are too many developers who have totally different ideas on what “best” really means, so I will stick with what works for me.

> In some comments it was mentioned that the object model and
> relational model have a 1-to-1 relationship. If such is the case
> either the application is too simplistic or the models are
> inappropriate and need to be revisited.

I disagree completely. I have used the one-class-per-table approach for years. I don’t use an ORM to generate my boilerplate SQL queries, instead I use intelligent Data Access Objects (see my post dated March 2, 2012 at 03:41). I have built an entire ERP application using this methodology containing over 200 tables, 350 relationships and 1700 transactions, so in no way could it be called “too simplistic” or “inappropriate”.

> I won’t consider using an ORM if I only have a few tables of a
> few columns. On the other hand, if I have hundreds of tables
> and hundreds of fields, maintaining the SQL scripts for all the
> queries I need is a laborious task.

If you are still writing individual queries in your code then you are doing something seriously wrong. See my post dated March 2, 2012 at 03:41 where I describe how I use a single Data Access Object to generate every type of query for every database in my application. This means that the number of tables in my application, or the number of columns in an individual table is irrelevant. My largest application has over 200 tables, 350 relationships, 1700 transactions and *NO* ORM, and has been serving an internet business for nearly 4 years, so don’t tell me it can’t be done.

ORMs are really bad because there is no practical way for them to actually be good. And therefore, most (but not all) database back-end engineers sniff at ORMs and never balm the issues so they can actually be good.

Every ORM I have encountered is very, very leaky. Yet, one cannot retain the illusion write queries in a so-called “fourth generation language” that is SQL, marvel that it works very well (it does) on the one hand while saying that one mere level of syntactic abstraction — most ORMs do not seek to drastically change the semantics of what happens, at all — is not “abstraction” but “indirection.” I think this is only true in the sense that ORMs have an incredibly leaky abstraction in implementation. That may be a valid reason to not use them today, but I think the first database that really figures out how to give its user an awesome integrated experience will have a huge leg-up in adoption. Nobody I’ve seen gets it right.

I’ll start with a simple one that is a pet peeve of mine: a static (type error, for example) or runtime (divide by zero) exception doesn’t point me to the source text in the client program (written in a language like Python, say), but rather into a ugly as sin generated SQL. At best I get told “the error happened when you decided to execute the query.” Thanks, ORM. But what could it really have done? If the backend had annotation and debugging symbol support, the ORM could reverse-map to, say, the offensive “.filter” expression that has long since left the backtrace and was composed into the query.

There are no debugging symbols for SQL. It would be a slog for any ORM to show you the plan, either, and it still would be quite challenging and ugly to write a good profiler. However, all of these things are doable, they’re just not done.

TL;DR: ORMs should become more like a database language layer and do a lot more work, but they really can’t without implementing a full blown catalog and semantic analyzer, making it very nearly economically unfeasible.