Re: Entity Framework - the lay of the land

[Greg Keogh]

GL

If your table design matches your object design, at least one of them is a
> poor design (again I'm talking about serious apps).
>

Then there's no hope. Game over man! It was easier for Jeff Goldblum to
plug his laptop into an alien mothership that it is for coders and DBAs
to exchange data effectively. Perhaps the relational database is a niche
evolutionary branch that just gained too much popularity in the last 30
years and is now overused or incorrectly used and we all take if for
granted. Robust RDBs come in all sizes and prices, many free, so they're
just everywhere and you use them without thinking. Codd might regret his
legacy!

You must have experienced many situations where some business data doesn't
feel right in an RDB and you finish up with self-joins and tricks to mimic
hierarchies, inheritance or represent temporal data. If other people have
stumbled into this situation and have opted for an effective non-RDB
solution then I'm keen to hear what happened.

In light of this whole discussion though, in future I'm going to be more
careful about bridging the code-to-DB gap. Rather than just lazily spiting
out wads of ORM generated code and throwing it at the DB, I'm going to
consider how to use views and procs more effectively to do what they do
best.

*GK*

Re: Entity Framework - the lay of the land

[罗格雷格博士]

Three other key aspects of this:

If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps). Yet most ORMs start with this 
assumption.

If you don't bypass your normal object access paths for high speed operations, 
you'll have serious perf issues. It might seem clean to load up a set of 
entities to filter and paginate them on each call. People who do that keep 
generating work for people like me though.

Finally, caching is your friend. I'm called in all the time to help with 
concurrency and scale issues. The #1 way to get a DB to scale is to stop 
talking to it in the first place.

Regards,

Greg

Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com

_
From: Greg Low (罗格雷格博士) >
Sent: Saturday, September 17, 2016 11:11 AM
Subject: RE: Entity Framework - the lay of the land
To: ozDotNet >


And if you have two days free on 28th/29th of this month,  come 
and spend those days on starting to get your head around query performance: 
http://www.sqldownunder.com/Training/Courses/3   (And sorry, 
Melbourne only this year. Might get time mid-next year for a Sydney one).

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under| Web:www.sqldownunder.com 
|http://greglow.me

From: Greg Low (罗格雷格博士)
Sent: Saturday, 17 September 2016 11:04 AM
To: ozDotNet >
Subject: RE: Entity Framework - the lay of the land

Hey Dave and all,

“The great” -> hardly but thanks Dave.

Look, my issues with many of these ORMs are many. Unfortunately, I spend my 
life on the back end of trying to deal with the messes involved. The following 
are the key issues that I see:

Potentially horrid performance

I’ve been on the back end of this all the time. There are several reasons. One 
is that the frameworks generate horrid code to start with, the second is that 
they are typically quite resistant to improvement, the third is that they tend 
to encourage processing with far too much data movement.

I regularly end up in software houses with major issues that they don’t know 
how to solve. As an example, I was at a start-up software house recently. They 
had had a team of 10 developers building an application for the last four 
years. The business owner said that if it would support 1000 concurrent users, 
they would have a viable business. 5000 would make a good business. 500 they 
might survive. They had their first serious performance test two weeks before 
they had to show the investors. It fell over with 9 concurrent users. The 
management (and in this case the devs too) were panic-stricken.

Another recent example was a software house that had to deliver an app to a 
government department. They were already 4 weeks overdue and couldn’t get it 
out of UAT. They wanted a silver bullet. That’s not the point to then be 
discussing their architectural decisions yet they were the issue.

I was in a large financial in Sydney a while back. They were in the middle of 
removing the ORM that they’d chosen out of their app because try as they might, 
they couldn’t get anywhere near the required performance numbers. Why had they 
called me in? Because before they wrote off 8 months’ work for 240 developers, 
the management wanted another opinion.

Just yesterday I was working on a background processing job that processes a 
certain type of share trades in a UK-based financial service organisation. On a 
system with 48 processors, and 1.2 TB of memory, and 7 x 1 million UK pound 
20TB flash drive arrays, it ran for 48 minutes. During that time, it issued 550 
million SQL batches to be processed and almost nothing else would work well on 
the machine at the same time. The replacement job that we wrote in T-SQL issued 
40,000 SQL batches and ran in just over 2 minutes. I think I can get that to 
1/10 of that with further work. Guess which version is likely to get used now?

Minimal savings yet long term pain

Many of the ORMs give you an initial boost to “getting something done”. But at 
what cost? At best, on most projects that I see, it might save 10% of the 
original development time, on the first project. But as David pointed out in 
his excellent TechEd talk with Joel (and as I’ve seen from so many other 
places), the initial development cost of a project is usually only around 10% 
of the overall development cost. So what are we talking about? Perhaps 1% of 
the whole project? Putting yourself into a long-term restrictive straightjacket 
situation for the sake of a 1% saving is a big, big call. The problem is that 
it’s being decided by someone who isn’t looking at the lifetime cost,