This forms a very good basis for defining the scope of what you may consider a platform. Thanks for sharing this.

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.