Do object-relational mappers (ORMs) really improve application development?
When I started developing web applications, I used perl. Not even all of perl, mostly just a bunch of “if” statements and an occasional loop that happened to be valid perl (aside: I remember being surprised that I was allowed to write a loop that would run on a shared server, because “what if it didn’t terminate?!”). I didn’t use databases; I used a mix of files, regexes to parse them, and flock to control concurrency (not because of foresight or good engineering, but because I ran into concurrency-related corruption).
I then made the quantum leap to databases. I didn’t see the benefits instantaneously[1], but it was clearly a major shift in the way I developed applications.
Why was it a quantum leap? Well, many reasons, which are outside of the scope of this particular post, but which I’ll discuss more in the future. For now, I’ll just cite the overwhelming success of SQL over a long period of time; and the pain experienced by anyone who has built and maintained a few NoSQL applications[2].
I don’t think ORMs are a leap forward; they are just an indirection[3] between the application and the database. Although it seems like you could apply the same kind of “success” argument, it’s not the same. First of all, ORM users are a subset of SQL users, and I think there are a lot of SQL users that are perfectly content without an ORM. Second, many ORM users feel the need to “drop down” to the SQL level frequently to get the job done, which means you’re not really in new territory.
And ORMs do have a cost. Any tool that uses a lot of behind-the-scenes magic will cause a certain amount of trouble — just think for a moment on the number of lines of code between the application and the database (there and back), and imagine the subtle semantic problems that might arise.
To be more concrete: one of the really nice things about using a SQL DBMS is that you can easily query the database as though you were the application. So, if you are debugging the application, you can quickly see what’s going wrong by seeing what the application sees right before the bug is hit. But you quickly lose that ability when you muddy the waters with thousands of lines of code between the application error and the database[4]. I believe the importance of this point is vastly under-appreciated; it’s one of the reasons that I think a SQL DBMS is a quantum leap forward, and it applies to novices as well as experts.
A less-tangible cost to ORMs is that developers are tempted to remain ignorant of the SQL DBMS and the tools that it has to offer. All these features in a system like PostgreSQL are there to solve problems in the easiest way possible; they aren’t just “bloat”. Working with multiple data sources is routine in any business environment, but if you don’t know about support for foreign tables in postgresql, you’re likely to waste a lot of time re-implementing similar functionality in the application. Cache invalidation (everything from memcache to statically-rendered HTML) is a common problem — do you know about LISTEN/NOTIFY? If your application involves scheduling, and you’re not using Temporal Keys, there is a good chance you are wasting development time and performance; and likely sacrificing correctness. The list goes on and on.
Of course there are reasons why so many people use ORMs, at least for some things. A part of it is that application developers may think that learning SQL is harder than learning an ORM, which I think is misguided. But a more valid reason is that ORMs do help eliminate boilerplate in some common situations.
But are there simpler ways to avoid boilerplate? It seems like we should be able to do so without something as invasive as an ORM. For the sake of brevity, I’ll be using hashes rather than objects, but the principle is the same. The following examples are in ruby using the ‘pg’ gem (thanks Michael Granger for maintaining that gem!).
First, to retrieve records as a hash, it’s already built into the ‘pg’ gem. Just index into the result object, and you get a hash. No boilerplate there.
Second, to do an insert, there is a little boilerplate. You have to build a string (yuck), put in the right table name, make the proper field list (unless you happen to know the column ordinal positions, yuck again), and then put in the values. And if you add or change fields, you probably need to modify it. Oh, and be sure to avoid SQL injection!
Fortunately, once we’ve identified the boilerplate, it’s pretty easy to solve:
# 'conn' is a PG::Connection object
def sqlinsert(conn, table, rec)
table = conn.quote_ident(table)
rkeys = rec.keys.map{|k| conn.quote_ident(k.to_s)}.join(",")
positions = (1..rec.keys.length).map{|i| "$" + i.to_s}.join(",")
query = "INSERT INTO #{table}(#{rkeys}) VALUES(#{positions})"
conn.exec(query, rec.values)
end
The table and column names are properly quoted, and the values are passed in as parameters. And, if you add new columns to the table, the routine still works, you just end up with defaults for the unspecified columns.
I’m sure others can come up with other examples of boilerplate that would be nice to solve. But the goal is not perfection; we only need to do enough to make simple things simple. And I suspect that only requires a handful of such routines.
So, my proposal is this: take a step back from ORMs, and consider working more closely with SQL and a good database driver. Try to work with the database, and find out what it has to offer; don’t use layers of indirection to avoid knowing about the database. See what you like and don’t like about the process after an honest assessment, and whether ORMs are a real improvement or a distracting complication.
[1]: At the time, MySQL was under a commercial license, so I tried PostgreSQL shortly thereafter. I switched between the two for a while (after MySQL became GPL), and settled on PostgreSQL because it was much easier to use (particularly for date manipulation).
[2]: There may be valid reasons to use NoSQL, but I’m skeptical that “ease of use” is one of them.
[3]: Some people use the term “abstraction” to describe an ORM, but I think that’s misleading.
[4]: The ability to explore the data through an ORM from a REPL might resemble the experience of using SQL. But it’s not nearly as useful, and certainly not as easy: if you determine that the data is wrong in the database, you still need to figure out how it got that way, which again involves thousands of lines between the application code that requests a modification and the resulting database update.
I had a similar experience as you, starting off with Ruby on Rails and considering the database as a place to dump and recover my data. For me the book “Enterprise Rails” by Dan Chak was an eye-opener that showed me the powers of a database system (PostgreSQL). A book like that should exist for all programming languages, and be read by all web application developers.
Very timely for me! Just starting my first project in Symfony 2, and
have been taken aback by the bloat that is Doctrine – their default (but
thankfully optional) DB interface. It seems there are no less than 333
files in the project – people write 600 page books about this monster!
And unless you really know how to tune it even the developers concede
that you can suffer dire performance hits. Never mind the cognitive
overhead of actually understanding the thing…
A nice example here http://www.notorm.com/static/doctrine2-notorm/ of
how simple joins can get hairy with Doctrine. And most ORMs seem to
complicate the handling of sets. So we’re actually making two of the
greatest benefits of the RDBMS harder to access. I just can’t see the
compensating benefits…
When you read threads about ORMs, developers seem confused about what
they are for. Portability? Reducing boilerplate? Some kind of magical
fix for the OOP/relational mismatch? A refuge from the so-called horrors
of SQL? Even ORM fanboys seem to disagree.
Do I really need portability for an in-house project? PG is so far ahead
of the OS alternatives,why would I ever have to move? And with good
design, my Postgres specific code will all be gathered behind a few neat
APIs, so in extremis it would only take a few days to port. Far less
time than it would take to become minimally fluent in Doctrine!
Perhaps for huge projects with distributed data there’s a case for all
this indirection – not my world so I can’t judge. But we all know that
only a small proportion of projects using Oracle really need it – the
rest would be better off with EnterpriseDB. And I suspect it’s the same
with ORM – that most users are simply following fashion and would be
better off adopting your more direct approach.
Thanks for reinforcing my intuition that I should be KISSing this ORM
complexity goodbye. I have a battle-proven library that provides
precisely the simple helper functions you describe – I doubt the
boilerplate takes more than two or three minutes per table, which is
less time that it would take to configure a table in Doctrine. For small
to mid sized projects, are ORMs a solution looking for a problem?
In Perl, I’ve been using DBIx::Simple with SQL::Interp for database access. It’s not an ORM, just a pleasant-to-use Database API. My assessment of ORMs has been similar.
Always use the right tool for the job.
“First of all, ORM users are a subset of SQL users, and I think there are a lot of SQL users that are perfectly content without an ORM. Second, many ORM users feel the need to “drop down” to the SQL level frequently to get the job done, which means you’re not really in new territory.”
Your arguments just indicated that some users use the right tool for the job and some don’t. Nothing more, nothing less.
ORM is designed to simplify complex relationship of RDBMS. I won’t considering using ORM if I only have a few tables of a few columns. In some of my simple applications, a text file is sufficient to store my data. On the other hand, if I have hundred of tables and hundreds of fields, maintaining the SQL scripts for all the queries I need is a laborious task. The same goes for NoSQL.
I think you are already aware of this fact. I think you should make it clear to the readers too, especially for those who aren’t experienced, so that they can make a correct decision on which tool to use.
@ nully
> 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.
@ nully
> 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.
– ORM is designed to simplify complex relationship of RDBMS.
They do nothing of the kind. At best, they change set operations to language specific RBAR; that’s not an advantage.
Thanks, that statement was indeed wrong (in fact, it doesn’t even make sense).
I agree! There are also a host of other problems.
A surprising amount of developers somehow thinks that they can ignore schema design because the orm magically will optimize everything for them.
The domain model tends to be a fairly close 1-to-1 mapping with the database schema when using orms making it hopelessly difficult to do any sort of refactoring to accommodate for new features or business insight.
One doesn’t realize a fraction of the performance problems before it’s too late. The small data amounts people tend to test with is just not large enough to expose the host of performance problems related to many orm implementations. I’ve seen Hibernate do insane things like deleting every entry in a collection before inserting them again for certain 1-to-many operations.
Spring’s JDBC templates is far superior to Hibernate imho.
A very thoughtful essay on why the ORM developed and where to look for a better way:
http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html
Historically ORM was developed to overcome the OR mapping impedance mismatch (Object orientation versus row column). Modern ORMs address the following area: inheritance, associations and hiding database specific details (ID values etc). Ideally, in the ORM world a developer would like to think in terms of associations/relationships and use the object graph navigation to traverse. This is where the ORMs come into play. Overcoming the impedance mismatch will expose the ORM to performance penalty. Mature ORMs like hibernate provide a lot of flexibility in terms of its fetch strategy to optimize/reduce performance overhead.
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. ORMs are no hammer and using them in every database interaction scenario does not make sense. It is up to the developer to make a judicious selection between ORM or pure SQL approach.
The hand that wields the knife decides whether to use it to slit someone’s throat or cut bread. Do not blame the knife if it is being used for wrong purposes.
@ Mr President
> 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”.
@Mr President
Surely the question is not whether ORMs are *never* useful, but whether they are regularly being abused because they are the flavour of the month. Here are some quotes harvested at random from a 1 minute Google:
“SQL is like assembly language for the database”
“Like the Patriots, who rebelled against Britain’s heavy taxes, NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data.”
“Relational databases give you too much. They force you to twist your object data to fit a RDBMS [relational database management system],” said Jon Travis, principal engineer at Java toolmaker SpringSource
“I have worked with a number of people who don’t know how to make a query, and just sit there dumbfounded. Then when they figure it out, they make queries that are inherently vulnerable to injection.”
All over the web you see developers arguing that the objects should determine the schema, and that schema-first design is restrictive and outmoded.
Something going adrift here, surely? Personally I know that the data will likely outlast my model – I can’t ever see myself trusting some ORM to autogenerate my schemas!
@Geoff,
“I can’t ever see myself trusting some ORM to autogenerate my schemas!”
I agree on not trusting ORMs to generate schemas. The object and relational world represent two different paradigms. Both should be developed independently to utilize their individual paradigm specific best practices. The only place where there is a possibility of compromise is in case you need to have a specific relational structure construct to satisfy the object oriented model; for e.g. inheritance paradigm. Such compromises should be an exception and not a rule. I personally prefer a meet-in-the-middle approach towards object and relational modeling.
“I have worked with a number of people who don’t know how to make a query, and just sit there dumbfounded. Then when they figure it out, they make queries that are inherently vulnerable to injection.”
As regards people not knowing ways to write a SQL; hmm I wonder about their fitness to continue in the IT industry if they are not willing to invest time and energy in developing such a basic skill set.
“Like the Patriots, who rebelled against Britain’s heavy taxes, NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data.”
Relational databases have been around for some time and although there have been attempts to develop object oriented databases, they have met with limited success. RDBMS are here to stay; noSQL is not going to replace them. NoSQL DBs are meant for specific requirements which I doubt the normal IT applications need.
@Mr President
You are clearly a sane and balanced ORM user – I can’t disagree with most of what you say.
But in the PHP world the two most recent, market leading enterprise frameworks (Symfony2 and Flow3) have come out with a big ORM baked in by default. The assumption seems to be that you will use it for pretty much anything – in Flow3 in particular it’s quite hard to sidestep it. To me this is a worrying trend, as for many, perhaps most PHP projects Doctrine 2 is patent overkill.
As my random quotes illustrate (it really did take just 1 minute to find them) there does seems to be a growing trend in the software industry to regard traditional RDBMS skills as boring and outdated, to be replaced by exciting, modern ORMs and NoSQL. When you get a senior developer at SpringSource saying “relational databases give you too much” (that’s a problem??) you begin to get a sense that we’re entering the twilight zone.
I’m sure that this kind of nonsense is still a minority attitude, but a significant and growing minority. And if it takes hold in a team, god help their customers…
@Geoff,
Chasing the new and the fancy has been the bane of IT industry for long. Just go back a decade and see how organizations as well as IT personnel have reacted to J2EE (now Java EE), SOA, BPM, ESB, Cloud. The reactions typically followed the Gartner hype cycle.
Everyone has a vested interest in working on the latest and greatest technologies; some do it for the heck of it, some for fluffing up their resumes. I have seen this; people without Spring Framework on their resumes are treated as illiterates.
My take is frameworks should stick to forcing users to implementing simple best practices like MVC pattern for UI, DAO for data access etc. They should not try to get too ambitious. In the Java world, iBatis is a simple DB wrapper while Hibernate aims to provide true ORM capabilities. Both have their uses, I personally recommend iBatis for basic needs and hibernate for sophisticated needs. As long as you are willing to invest time and energy in exploring and understanding the intricacies of the framework, so long so good. Things start to unravel as soon as someone tries using sophisticated frameworks like hibernate with half baked knowledge.
A framework like the ones you mentioned which tend to cover all aspects of application stack, will do things nicely as long as you stick to their approach. However God save you if you want something slightly or radically different.
I am sure in case of your PHP frameworks, the world will follow this path. There will be a tremendous interest is doing POCs and small projects using these frameworks. Once successful they will be applied on medium to large applications. There things will unravel, limitations exposed and developer frustration will increase. Some frameworks will mature(overcome/fix/address these shortcomings) and live on. Some will die their natural deaths and after 2/3 years of experience, the framework will be dead or will reach a “slope of enlightment” level. In between will be some failed projects and frustrated enterprises. Its a cycle, there is no escape.
Just pray that you are not taken along on this treacherous ride.
@ Mr President
> 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.
@Tony Marston,
I would appreciate if you could provide a link to your said post.
Here is the link:
http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/comment-page-1/#comment-2440
I respect your experience, but …
If you are developing a small website, or small application or maybe a embedded application for small devices I would not recommend use ORMs or heavy platforms.
But, if you are going to develop a commercial or enterprise application, why you should fight your self waisting time developing infraestructure when this already exits, now … if you are trying to develop a moderm enterprise application without this kind of infraestructure I would say you have a lot of time or you should consult and expert in this matter. Many ORMs connects with the application server or container, adminstrate pools beans and jdbc, transactions, etc. Why don’t use a enterprise known pattern, a trusted application server and better concentrate in business logic?
Another thing is that, why you delegate to the DBMS things that maybe your language or platform is meant to do better? If your platform is limited then is good that DMBS have a lot of things, but if you are programming with, e.g., jee, all that stuff are better in the application server than in the DBMS, and let the DMBS get/store data. The business logic have to be in the enterprise application, the data stored in the DBMS. I am talking for large enterprise applications, as I said before.
– The business logic have to be in the enterprise application, the data stored in the DBMS.
The truest single sentence I’ve ever read, from Fabian Pascal: “A row is a business rule”. Once you grok that, you’ll see that all logic in app code is doing data compares on data that sits in the database, which, if normalized, enforces that logic through DRI. ORMs and the like are merely a desperate attempt by coders to stay employed a bit longer.
Have a look at Apache OFBiz…
@Geoff,
Chasing the new and the fancy has been the bane of IT industry for long. Just go back a decade and see how organizations as well as IT personnel have reacted to J2EE (now Java EE), SOA, BPM, ESB, Cloud. The reactions typically followed the Gartner hype cycle.
Everyone has a vested interest in working on the latest and greatest technologies; some do it for the heck of it, some for fluffing up their resumes. I have seen this; people without Spring Framework on their resumes are treated as illiterates.
My take is frameworks should stick to forcing users to implementing simple best practices like MVC pattern for UI, DAO for data access etc. They should not try to get too ambitious. In the Java world, iBatis is a simple DB wrapper while Hibernate aims to provide true ORM capabilities. Both have their uses, I personally recommend iBatis for basic needs and hibernate for sophisticated needs. As long as you are willing to invest time and energy in exploring and understanding the intricacies of the framework, so long so good. Things start to unravel as soon as someone tries using sophisticated frameworks like hibernate with half baked knowledge.
A framework like the ones you mentioned which tend to cover all aspects of application stack, will do things nicely as long as you stick to their approach. However God save you if you want something slightly or radically different.
I am sure in case of your PHP frameworks, the world will follow this path. There will be a tremendous interest is doing POCs and small projects using these frameworks. Once successful they will be applied on medium to large applications. There things will unravel, limitations exposed and developer frustration will increase. Some frameworks will mature(overcome/fix/address these shortcomings) and live on. Some will die their natural deaths and after 2/3 years of experience, the framework will be dead or will reach a “slope of enlightment” level. In between will be some failed projects and frustrated enterprises. Its a cycle, there is no escape.
Just pray that you are not taken along on this treacherous ride.
As a long-time designer/developer of database applications I totally agree with the OP’s argument that using an ORM is more of a hindrance than a help, a distracting complication instead of a real improvement. A large number of today’s programmers, perhaps the majority, are comfortable with SQL, so why introduce an intermediate layer of indirection (some say mis-direction) which hides the underlying database structure from the application and which forces you to use pseudo-SQL to describe the query that you want executed?
Object Relational Mappers are supposed to solve the problem called Object Relational Impedance Mismatch where the structure of the software components (Objects) is totally different from the structure of the (Relational) database. This means that the two cannot communicate directly with each other, so they have to do it indirectly through an additional component which maps the differences between the two structures.
For me the solution is incredibly simple – instead of creating the problem of a mismatch which requires the solution of an ORM why not eliminate the mismatch in the first place? If you don’t have the problem then you don’t need the solution. Why not allow the application components to have the same structure as the database, and allow these components to communicate directly to the database using standard SQL?
The next question is – which structure to use? In my pre-OO and pre-RDBMS days I learned two basic facts which are just as relevant today as they were then:
(1) The most important part of a database application is the database itself, and a properly normalised database is the bedrock on which the application is built. Try using a badly normalised database and you will quickly trip yourself up.
(2) An application structure which mirrors the database structure will be easier to create and maintain, and will perform more efficiently. This was the basis of various structured programming methodologies which were taught in the 70s and 80s.
Therefore I have always started with a properly normalised database, and designed my software components around the database structure. This worked whether the database was hierarchical, networked or relational, and whether the language was procedural (COBOL), component driven (UNIFACE) or with object oriented capabilities (PHP).
This means that after performing my data analysis and applying the rules of normalisation I end up with a database design which can be represented in an ER diagram. I deliberately avoid performing a second Object Oriented Design (OOD) phase as I consider it to be totally redundant. Why use a second methodology to produce a second design if you already have a workable design? Instead I simply create a class for every table in the database. I have even automated this class creation process – I have written my own Data Dictionary into which I can import the details of every database table, after which I can export each table directly to my application if the form of a table class file and a table structure file. The idea behind having two files is that the class file (which reads the structure file) can be amended to include any business rules and custom logic while the structure file can be regenerated at any time following any changes to the database.
Another reason why some programmers use an ORM is that it helps eliminate the production of boilerplate code in common situations. I have solved that problem as well. I said earlier that I allow my software components (table classes) to communicate with the database directly, but this is not entirely true. I build my applications around the 3-Tier architecture which has a Presentation layer, a Business layer and a Data Access layer, so all of my table classes exist in the middle Business layer. When they want to communicate with the database they go through a separate Data Access Object (DAO). Instead of the business object constructing the SQL query and passing it to the DAO to be executed, the object passes the raw data to the DAO, and it is the DAO which constructs and then executes the query. Some programmers have a separate DAO for each table, but I have a single DAO which can deal with any table in any database. In fact I have a separate DAO class for each of the DBMS engines which I support (MySQL, PostgreSQL, Oracle, SQL Server) which enables me to switch my application from one DBMS to another with a single configuration option.
My DAO automatically creates the SELECT, INSERT, UPDATE and DELETE query for the relevant table, so the developer can concentrate his efforts on the business rules and leave boilerplate code to the framework. In simple cases the framework can automatically include JOINS into a SELECT query using relationship details in the table structure file which was generated by the Data Dictionary. For more complex queries it is possible for the developer to provide fragments of raw SQL which are then assembled and executed by the DAO. Some of these fragments may have to be modified for a particular DBMS, but as each DBMS has its own DAO then the modification code can be built directly into the DAO.
I don’t need an ORM to deal with an Object Relational Impedance Mismatch as there is no mismatch. I don’t need an ORM to generate boilerplate code as this is done within my DAO. I can deal with changes to my database structure simply by using the import and export features in my Data Dictionary.
This nullifies the comment from nully who said “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.”
I also disagree with Mr President who said “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.”
To me the number of columns in a table is irrelevant, as is the number of tables. I have used my ideas to build a complete development framework, and I have used this framework to build an ERP application which contains over 200 tables, over 350 relationships and over 1700 transactions. This is not an application which is “too simplistic”, nor are the models “inappropriate” as it can deal with complex business rules and complex queries.
It was also Mr President who said “I agree on not trusting ORMs to generate schemas. The object and relational world represent two different paradigms. Both should be developed independently to utilize their individual paradigm specific best practices.” I disagree that both should be developed independently. I want a single design structure, and I trust the rules of normalization much more than I trust the theories of OOD. As for “best practices” there too many developers who have totally different ideas on what “best” really means, so I will stick with what works for me.
@Tony Marston,
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?
In my entire career as a database and application designer I have only come across a single instance where I had something resembling inheritance in the data model. When implementing the PARTY database from Len Silverston’s Data Model Resource Book I had the ORGANISATION table and the PERSON table both of which inherit from the PARTY table. Although the DBMS does not natively support inheritance it was a simple matter to do this in the code. It is a simple matter of putting the right code in the right place.
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.
I see the problem very differently. ORMs are here to stay and have real value, but I agree they are really a pain sometimes. SQL is an acceptable reporting language, but it’s a terrible target language to compile to. I think we what we suffer from right now from is a chicken-and-egg problem:
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.
As you may know, first PHP database libraries use something like the myRecord["MyField"], kind of hash syntax. Delphi use something like myRecord(“MyField”).
A mix of both KeyValue (“hash”), and Property may also be used.