Hacker News Reader

Comment by ap22213 | Hacker News Reader

Using ORMs gives developers (and other stakeholders) a way to get through the initial conceptual design and development faster. It helps getting to 'functional' much faster and it makes feedback loops very effective.

However, before pushing to production, you should always have some idea of typical user scenarios. What actions are they taking? With how much data? How often? In what sequence? Then, you load test based on that information. You identify that 20% of the ORM isn't going to work, and you replace it with stored procedures, or in-memory tables, or something.

For someone who grew up pre-ORM with on-staff dba-types who had to redesign their schemas on every little feature change, and thus recreate entire data layers, ORMS are FREAKING AWESOME.

But, you still need someone who knows what they're doing.

View on HN

I agreed with you until the point that you said to replace things with stored procedures and in-memory tables.

Having the two different contexts for logic, code and SPs makes things a thousand times harder to debug and maintain, making the cost of anything skyrocket.

ORMs are indeed awesome, but the solution for problems like this is not to take ORM out of the way, is to work with it to make it work better.

Why is that more difficult? It seems like it worked fine for two teams I worked with. What are other common or better ways to get around this?

the big problem is that it makes refactoring and changing logic much harder, as you now two different places to maintain business logic.

In my experience, most problems that DBAs would like to use SPs for can be easily solved by refactoring/merging SQL calls and proper caching of objects during a request or session, two things that an ORM really help you with.

I think that object oriented languages (e.g. java) is not well suited for business logic.

Putting all logic in DB also provides natural separation of concerns. UI in one place, business logic in another.

What? So you think Java is not expressive enough for business logic, and you think it's better to move that logic to PLSQL? Seriously?

Java may not be the best language for some things, and that's why you use DSLs, but moving that to the place you store the data is probably the worst thing you can do 99% of the time.

Yes.

Business logic as far as possible must be expressed in declarative way.

Java have very poor facilities for declarative programming.

SQL (not PL/SQL) on other side - is pure declarative language. It's already powerful DSL if you master it.

And yes, I agree with you, that writing logic in PL/SQL (as in imperative language) is equally terrible as writing it in Java.

Omg.. this is getting worse.

SQL is a DSL to deal with sets of data. Unless the application you're writing is a database management app, you're pretty much doing it really wrong, I'm sorry to tell you that.

>>SQL is a DSL to deal with sets of data

What's wrong with this?

Can you imagine process of billing campaign?

Than try it in Hibernated database and in raw SQL.

Pure SQL will be thousands times faster.

ORMs are good only for smth like Django Admin

Reply on news.ycombinator.com