To ORM or not to ORM
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
No, never.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
You can still use stored procs (at least with EF - don't know about NHibernate). Marc Clifton has a post below about EF. We are starting with EF Core 2 - supposedly a big advance on previous versions in terms of speed and usage - too early to tell if that is the case.
Keep your friends close. Keep Kill your enemies closer. The End
-
No, never.
I take it you are speaking from experience with NHibernate ?
-
I take it you are speaking from experience with NHibernate ?
Frack no.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
I first used ORMs about 20 years ago. I have been saddled with trying out various ones over the intervening years. My advice, if you have to go ORM, roll your own because at least then it might do what you want and not get in the way.
This space for rent
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
Well, if the collegue can explain the added value of the extra dependency and the added complexity, then yes. And all software-shops claim that performance is an important factor, but no-one dies if a manager has to wait a second longer for a loop to complete. Being correct is more important than being quick :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Well, if the collegue can explain the added value of the extra dependency and the added complexity, then yes. And all software-shops claim that performance is an important factor, but no-one dies if a manager has to wait a second longer for a loop to complete. Being correct is more important than being quick :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Well, if the collegue can explain the added value of the extra dependency and the added complexity, then yes. And all software-shops claim that performance is an important factor, but no-one dies if a manager has to wait a second longer for a loop to complete. Being correct is more important than being quick :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Yes, I'd rather wait for a correct answer than get a wrong answer immediately. (Though I don't think this matters to this discussion. However, I have worked with a database system that ignored order of operations but was faaaassssttt. :( )
-
Yes, I'd rather wait for a correct answer than get a wrong answer immediately. (Though I don't think this matters to this discussion. However, I have worked with a database system that ignored order of operations but was faaaassssttt. :( )
PIEBALDconsult wrote:
However, I have worked with a database system that ignored order of operations but was faaaassssttt. :(
Dirty reads, same problem.
PIEBALDconsult wrote:
Though I don't think this matters to this discussion.
Same goes for code; do you want a solution fast, or do you want a solution that is good? I can see how I'd use an ORM for prototyping, but would prefer an actual query in production.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
RickZeeland wrote:
started using NHibernate
There's the problem. He has not yet hit a bump in the road and desperately searched the documentation (which always used to be incomplete) for a solution. The learning curve is steep enough, even if you don't have to pray that the better (Java) Hibernate documentation also applies to your current NHibernate version. The number of tables is not the problem, the number of rows in those tables could be. NHibernate used to be a memory hog and I had to throw it out of a project only days before the deadline because of that. Also, I had to use an existing database and NHibernate kept preaching about good and bad practices and it will not shut the *elephant* up. What else would one expect of something that comes from the Java corner? Don't use it if you are not a masochist.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
ORM. Most old farts have no clue how to ORM, therefore they advise against it. Don't be like that. I have been working on enterprise apps for a long time with ORM and no issues. Do it right, and it will handle itself. Performance is not an issue when done correctly. Edit: do note, that for most application transactions (web and non-web), ORM will be just fine. I wouldn't use ORM for ETL, or big data load stuff.
-
PIEBALDconsult wrote:
However, I have worked with a database system that ignored order of operations but was faaaassssttt. :(
Dirty reads, same problem.
PIEBALDconsult wrote:
Though I don't think this matters to this discussion.
Same goes for code; do you want a solution fast, or do you want a solution that is good? I can see how I'd use an ORM for prototyping, but would prefer an actual query in production.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I enjoy a good dirty read. :~
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
I'm curious -- are you doing anything with the database other than presenting it to the UI so the user can CRUD the data? As in, do you have actually have any business logic that actually does something internally with the data?
Latest Article - Contextual Data Explorer Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
Slacker may have the right of it, most of us old farts despise ORM products probably because we have all rolled our own which we therefore know inside out and most of the ORMs are way too complex. I inherited ClassBuilder from a senior developer in the 90s, written in VB5, the current version (in c#) is basically the same. It does a hell of a lot less than commercial ORMS and it does a hell of a lot more of what I use every day.
Never underestimate the power of human stupidity RAH
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
From a maintenance perspective using ORM relieves the developers from maintaining at the database level. You could develop all your core and business logic in code and cover all the test cases and have the need not to debug at the database level.It would be a good choice.
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
My advice would be to use an ORM (probably EF even though faster ones do exist) but keep a close eye on what the ORM is doing and learn how to performance tune it - in particular when not to use lazy loading. ( This is based on the economics of developer time being staggeringly expensive and hardware spectacularly cheap - if that does not apply in your situation then adjust accordingly. )
-
My advice would be to use an ORM (probably EF even though faster ones do exist) but keep a close eye on what the ORM is doing and learn how to performance tune it - in particular when not to use lazy loading. ( This is based on the economics of developer time being staggeringly expensive and hardware spectacularly cheap - if that does not apply in your situation then adjust accordingly. )
Duncan Edwards Jones wrote:
in particular when not to use lazy loading.
Hear hear
Wrong is evil and must be defeated. - Jeff Ello
-
Slacker may have the right of it, most of us old farts despise ORM products probably because we have all rolled our own which we therefore know inside out and most of the ORMs are way too complex. I inherited ClassBuilder from a senior developer in the 90s, written in VB5, the current version (in c#) is basically the same. It does a hell of a lot less than commercial ORMS and it does a hell of a lot more of what I use every day.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
Slacker may have the right of it, most of us old farts despise ORM products
Don't forget that the ORM crowd still need their programming training wheels; they learn how to do bare metal SQL coding when they get their "big boy pants" ;)
This space for rent
