September 13, 2014 at 11:03 am
Comments posted to this topic are about the item Swallowing the Camel
September 13, 2014 at 11:07 am
Thanks Tony, couldn't have said it better!
😎
September 13, 2014 at 12:26 pm
Oh so true.
If the only tool you know is a hammer ( or ORM/Hibernate/etc.) then all problems look like a nail. The developers/database staff that know many tools tend to be open to a wide variety of solutions. Few tools -> less open.
I was stabilizing and optimizing a SQL2005 system years back for a large public facing company, where the developers had setup a query against 192 tables. (yes, that was 192). They thought that the dB query engine should be able to optimize this just fine! Oh-well.
IMHO, I like to see ORM's that connect to stored procedures. More work, but more secure and scalable.
The more you are prepared, the less you need it.
September 13, 2014 at 8:11 pm
On this topic I completely disagree.
I don't see the primary purpose on an ORM to add a layer of abstraction. Yes, ORMS would be able to map between the database and entity columns/fields to give the abstraction if needed.
I actually see the purpose of an ORM to provide compile-time checks against tables, queries etc. used. And providing easy and fast inserting, updating, querying entities are a lot easier via an ORM than cutting your own ADO style layer. Especially if you use LLBLGen rather than NHibernate or Entity Framework.
I think it's also the responsibility of the developer to known/understand the underlying table structure and I feel views could potentially complicate this. It's easy to some to create a complex view joining a massive number of tables and have the end developers not actually know.
And really there's also no excuse not to performance profile something 🙂
September 13, 2014 at 10:32 pm
courtney.smith (9/13/2014)
And really there's also no excuse not to performance profile something 🙂
+10
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 15, 2014 at 3:41 am
I'm going to throw my hat into the ring with Courtney on this one. I think the article misrepresents developers, at least good developers.
"I actually see the purpose of an ORM to provide compile-time checks against tables, queries etc. used. And providing easy and fast inserting, updating, querying entities are a lot easier via an ORM than cutting your own ADO style layer. Especially if you use LLBLGen rather than NHibernate or Entity Framework."
I'm happy enough with EF personally but agree with what Courtney says about the purpose of an ORM. I'll go further and say it helps to minimise the amount of explicit (i.e. non-constrained) business logic in a database. I'm happy in either DB or code realms and there is no doubt in my mind that code can generally be better structured outside of the database. Of course there is a time for SQL but eliminating some of the unpleasant monolithic code in procs and twisted nonsense I have found in views is no bad objective.
I do have developers who are less comfortable in SQL but that is where I (or several others) can step in. I've never heard of or wished for the elimination of SQL altogether, just desired to make it manageable.
September 15, 2014 at 6:23 am
I look at this from both sides being both a admin and a accidental DBA. Too often we hear "ORM BAD, HULK SMASH!" from the DBA, when the real issue is that of developer and DBA education. There are sane ORM solutions that can be utilized correctly by pragmatic developers.
September 15, 2014 at 9:39 am
I am a developer and I prefer Stored Procedures over ORMs every day of the week.
It is possibly because the developers who tout ORMs, in my experience, defer all issues such as maintenance and performance to after they will have left.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 15, 2014 at 2:24 pm
The best developers that I have worked with use ORMs against a set of views in an application schema and also utilize procedures for all DML. They were also good at taking the time to understand the data model...it makes everyone's life easier.
Aigle de Guerre!
September 15, 2014 at 5:26 pm
To bring what the good Mr. King has observed into the real life methods of current application development, in may cases, here's a twist on his statement...
"Both the object model and the relational model are incredible ways of screwing up the data, and both are present in most applications."
😛
--Jeff Moden
Change is inevitable... Change for the better is not.
September 15, 2014 at 7:24 pm
Picket sign:
===========
- Blow Up -
- the -
- ORM's! -
===========
=
=
=
=
Okay, I'm not against the concept of the ORM. I'm against the implementation.
1) If you open a transaction from any server but the database server, I will shoot you, publically, and it will be considered a justifiable homicide. Lost connections are no joke when you lock tables out.
2) Implementation of standardized and parameterized queries is apparently difficult. The majority of them I've ran headfirst into run unwashed sql_executes. 40 billion execution plans in the cache, and you want me to figure out why *1* of those ran slowly? Also, who's Bobby Tables again?
3) Volume Controls: Can ORM even implement this stuff? I've seen entire tables downloaded to cache when pulling up the record for a single user.
The new table object as a parameter for SQL Server (or hell, just XML passing) can be used for serious 'abstraction' layers for the developers if necessary. Admittedly, it means having someone who knows what they're doing in the DBEngine of choice, but the ORM is like watching the Hulk go to a tea party. The little girl will probably survive but the entire tea set will be in pieces by the time they're done.
I have refused jobs, outright, that run ORM.
Them: "We want you to come in and help us fix our system so the ORM runs better."
Me: "Delete the ORM."
Them: "No, you need to fix the database to make ORM work better."
Me: "Check, please!"
I know of *2* locations that can use ORM well, and they lean heavily on procs under the hood of the ORM to control the SQL for them.
No, I'm sorry. ORM is immature for any system that actually needs a DBA Dev in the first place. It's like a lot of other contracts I've seen. You don't actually care what's getting the data out until you suddenly have to care, and at that point it's entrenched and you're making due with what's there and trying to plug the dyke. Once you run out of machine to throw at a problem you have to hire an expert.
If your front end devs actually used procs and standard methodology, there's a fighting chance we can save you from the fire you jumped into. If it's ORM and abstracted to the 10th degree and if you change THAT you break EVERYTHING (oh my god what a jackass of a DBA he wants to break our stuff HE HATES ORM GOD HE'S SUCH AN ARSE HE JUST DOESN'T UNDERSTAAAAANNNNDDDD!!!!!! wwaaaaaaahhh!) instead of having the discussion with one in the first place to help put it into place intelligently... yeah.
No. Screw ORM. Not because the idea is bad. The implementation is horrid except by experts and I'm just sick of the war with people who are supposed to be my compatriots. ORM is not newbie friendly. Stop giving it to them.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
September 16, 2014 at 1:45 am
It will always be an ongoing battle.
Ask a developer to use a dll, RESTful service ... Fine no worries.
Ask a developer to use a stored procedure and majority will look at you as if you are mad.
The arguments I have heard:
* I cant debug a stored procedure
* it takes too long to write the extra code
* I cant see whats happening.
* What happens if I need to add a column
September 16, 2014 at 2:30 am
Well, ususally I agree 100% with what you write, and I love your way of thinking.
However, this time I really think you did not consider all the benefits of an ORM.
First off:
I am also a developer and DBA for most of 3 decades and use a plethora of ORMs and have written a considerable number of non-ORMd applications where ORMs did not exist yet, or where ORMs were unwanted by the end client.
I too think that SQL cannot be fully replaced by ORMs, and that gray matter should always be applied to see what fits better for the particular problem.
There is quite some stuff that cannot be fully or efficiently ORM-ed.
Note that I do think that ORMs can create horrific DB traffic when used without the proper experience, but that argument is valid for most technologies we use these days.
However, I want to input that ORMs bring more to the table than just abstraction.
Abstraction itself can- as you state correctly- be largely done by SQL/Views.
Having a good ORM you can do that too and:
* Have typesafety using the object model. Throughout my career I have seen many, many issues with implicit conversions, DB specific types and such.
* It vastly reduces code clutter, even compared to code using code constructs as .NET's lambda expressions to envelope the field access code with the connection/command code.
* Have automatic client-side caching (if you want), reducing DB traffic altogether. You can even deliberately pre-cache, without writing any code.
* Have automatic batching (if you want), reducing latency.
* if you are more experienced with ORMs you can use object inheritence, reducing model complexity and promoting code reuse.
* Although complex applications can give you some trouble, most of the LOB applications can be switched to another database (MySQL, Oracle) without any (or little trouble).
I do NOT think this is a big plus though. I have seen less than 10 database switches during my career, and I think choosing a specific ORM for this reason is nuts.
* AND - using a good ORM, you can actually have both. Create your views in the DB, use the ORM to create a class for the resulting recordset. You will have the mentioned benefits AND use all the speed and complexity of the DB. I do this all the time. USE THE BRAINS. This works for stored procedures aswell.
So, I think that there's more to this than just the abstraction.
There is no need to make this a ORM bash. In this case, you CAN have your cake and eat it too.
Use the DB for what it's good at. Use an ORM if it benefits your cause.
They work together you know.
DBA's will always be necessary. An ORM is just another tool in the box.
September 16, 2014 at 2:39 am
ORM is not newbie friendly. Stop giving it to them.
I FULLY agree with that though.
The ease of use has attracted a flurry of newbies that DO use it badly.
ORMs are powerful tools, but easily abused.
Like I said, they can create a horrible, horrible diarrhea of SQL if not used wisely.
September 16, 2014 at 2:48 am
Yet Another DBA (9/16/2014)
It will always be an ongoing battle.Ask a developer to use a dll, RESTful service ... Fine no worries.
Ask a developer to use a stored procedure and majority will look at you as if you are mad.
The arguments I have heard:
* I cant debug a stored procedure
* it takes too long to write the extra code
* I cant see whats happening.
* What happens if I need to add a column
That developer needs mentoring. I can debug a SP in SSMS so so can they. If the SP has been tested and works then you can ascertain the data it returns and mock it for a unit test. If the developer cannot do that then they need training, of some sort or other, in the fundamentals of their job which not only includes coding but also application design.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 15 (of 33 total)
You must be logged in to reply to this topic. Login to reply