CODEWITHSUNDEEP
databaseooporm
Zhu Tao
Zhu Tao

Reputation: 7617

What's the meaning of ORM?

I ever developed several projects based on python framework Django. And it greatly improved my production. But when the project was released and there are more and more visitors the db becomes the bottleneck of the performance.

I try to address the issue, and find that it's ORM(django) to make it become so slow. Why? Because Django have to serve a uniform interface for the programmer no matter what db backend you are using. So it definitely sacrifice some db's performance(make one raw sql to several sqls and never use the db-specific operation).

I'm wondering the ORM is definitely useful and it can:

  1. Offer a uniform OO interface for the progarammers
  2. Make the db backend migration much easier (from mysql to sql server or others)
  3. Improve the robust of the code(using ORM means less code, and less code means less error)

But if I don't have the requirement of migration, What's the meaning of the ORM to me?

ps. Recently my friend told me that what he is doing now is just rewriting the ORM code to the raw sql to get a better performance. what a pity!

So what's the real meaning of ORM except what I mentioned above? (Please correct me if I made a mistake. Thanks.)

Upvotes: 7

Views: 7704

Answers (6)

nightingale2k1
nightingale2k1

Reputation: 10335

ORM generates sql queries for you and then return as object to you. that's why it slower than if you access to database directly. But i think it slow a little bit ... i recommend you to tune your database. may be you need to check about index of table etc.

Oracle for example, need to be tuned if you need to get faster ( i don't know why, but my db admin did that and it works faster with queries that involved with lots of data).

I have recommendation, if you need to do complex query (eg: reports) other than (Create Update Delete/CRUD) and if your application won't use another database, you should use direct sql (I think Django has it feature)

Upvotes: 0

Ian Boyd
Ian Boyd

Reputation: 256731

ORM separates you from having to write that pesky SQL.

It's also helpful for when you (never) port your software to another database engine.

On the downside: you lose performance, which you fix by writing a custom flavor of SQL - that it tried to insulate from having to write in the first place.

Upvotes: 0

Javier
Javier

Reputation: 62593

a good ORM (like Django's) makes it much faster to develop and evolve your application; it lets you assume you have available all related data without having to factor every use in your hand-tuned queries.

but a simple one (like Django's) doesn't relieve you from good old DB design. if you're seeing DB bottleneck with less than several hundred simultaneous users, you have serious problems. Either your DB isn't well tuned (typically you're missing some indexes), or it doesn't appropriately represents the data design (if you need many different queries for every page this is your problem).

So, i wouldn't ditch the ORM unless you're twitter or flickr. First do all the usual DB analysis: You see a lot of full-table scans? add appropriate indexes. Lots of queries per page? rethink your tables. Every user needs lots of statistics? precalculate them in a batch job and serve from there.

Upvotes: 0

Hannoun Yassir
Hannoun Yassir

Reputation: 21192

here is the definition from Wikipedia

Object-relational mapping is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

Upvotes: 2

Steve Weet
Steve Weet

Reputation: 28392

You have mostly answered your own question when you listed the benefits of an ORM. There are definitely some optimisation issues that you will encounter but the abstraction of the database interface probably over-rides these downsides.

You mention that the ORM sometimes uses many sql statements where it could use only one. You may want to look at "eager loading", if this is supported by your ORM. This tells the ORM to fetch the data from related models at the same time as it fetches data from another model. This should result in more performant sql.

I would suggest that you stick with your ORM and optimise the parts that need it, but, explore any methods within the ORM that allow you to increase performance before reverting to writing SQL to do the access.

Upvotes: 8

Daniel Earwicker
Daniel Earwicker

Reputation: 116674

A good ORM allows you to tune the data access if you discover that certain queries are a bottleneck.

But the fact that you might need to do this does not in any way remove the value of the ORM approach, because it rapidly gets you to the point where you can discover where the bottlenecks are. It is rarely the case that every line of code needs the same amount of careful hand-optimisation. Most of it won't. Only a few hotspots require attention.

If you write all the SQL by hand, you are "micro optimising" across the whole product, including the parts that don't need it. So you're mostly wasting effort.

Upvotes: 3

Related Questions