Question for DB admins, DB architects, etc.
-
I've been a developer DBA, for lack of an actual one DBA, and I can say that if you don't know how a database works, you won't perform well with EF either. It's a real issue I think, developers forgetting they're talking to an actual database and not some in-memory code and data. I check the generated SQL for all but the simplest queries (and I've become pretty good at predicting the generated SQL). There are times when I think, this query is not going to scale very well, and I have to change my LINQ query to generate cleaner SQL. Also, I do code first, but always check my migrations and how it's actually generated in the database. I'm checking for names, types, foreign keys, etc. It's very nice for DevOps and CI/CD though! All in all, it's made my life a lot easier, but it doesn't take away that I need to know SQL or how a database works. I've been able to ban views, functions and stored procedures from my life and fix it all in code with good and clean generated SQL queries :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
One have to realize it's a tool. And all tools have to be used appropriately. Just because it doesn't work for everybody doesn't mean it won't work for you. Or vice versa. Performance: Yeah it's crap compared with ADO.Net, but you know what, in 95% of the cases you won't notice. Pitfall nr 1: It doesn't remove you from having to understand how a database works. It doesn't matter if you use Code First or Database First if you're anyway crap at modeling. For the database I'm working on we have a data entry tool that uses EF. It has probably saved us a ton of time developing it. For reporting we DON'T use EF. For performance reasons. Yes you can run queries directly in EF, but why add another layer if you're not going to benefit from that extra layer. So my personal takeaway is that EF is fine for CRUD (and quite a bit more actually), but as soon as your queries are getting more advanced and aggregates a lot of data you need to watch out.
MSBassSinger wrote:
Does its use ever cause you any headaches
Yeah, simple tasks as changing the datatype on a column isn't as easy as it should be if you're database first.
Wrong is evil and must be defeated. - Jeff Ello
-
I've never really like the migrations. I use a project/raw sql to generate and maintain my databases.
Phil
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
Just a point about what often seen as EF making very large queries for simple things. If doing something like Get Record Where ID = 5 Quick SQL could be "select * from table where id = 5" EF will use the full expanded out version, so that * becomes all the fields in the table. So just like writing suitable SQL quieres, EF needs to be used appropriately. If just want to get 2 fields from a 20 field table, then in EF use .Select and Where in combination, and will generate out suitable query.
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
Most DBA's have no practical "application development" experience ... and their designs (and attitude) reflect that. Asking a DBA about EF, or any ORM, would be like asking them what programming language to use.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Most DBA's have no practical "application development" experience ... and their designs (and attitude) reflect that. Asking a DBA about EF, or any ORM, would be like asking them what programming language to use.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
DBAs that are not application developers do have experience in dealing with poorly written SQL by application developers that they have to then clean up and optimize. An application developer who uses SQLProfiler, is adept at SQL, understands indices, avoids table scans, etc. is a delight to the DBAs that have to manage the databases. Asking them about EF and other ORMs is in the context of how does the application developer's use of them impact their work. And it does, if you read some of the other posts.
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
personally, I've used entity for a couple years, but stopped. I didn't like it, and have gone back to using stored procedures and then the system.Data namespace to use the calls, for multiple reasons: *i don't need CRUD on all tables *SPROCs are easy to test and verify results. *complex joins and other like functions are easier to do in T-SQL before it gets to the app *Entity framework feels heavy. but these reasons are mine, and our environment works well with SPROCs.
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
I will rail against the use of ANY ORM when given the opportunity. I've been looking, for the last 10 years or so, for a way to completely rid MVC apps of the scourge that is EF, and have never found anything more descriptive than, "yeah it's possible". I want code, not possibilities.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
There's absolutely nothing in EF that says you have to use the queries it generates. If you see a non-performant query - write the one you want EF to use instead. And EF handles sprocs perfectly well. It has a slight issue with views that EF requires a PK (unique Entity ID) of some kind - but that can be generated as part of the view. If you're going to bash EF - make sure you're aware of the current capabilities - not what is was 6-7 years ago.
Phil
Quote:
And EF handles sprocs perfectly well.
Ah, maybe I should have mentioned that we were using it against an Oracle database. It is true that it talked well with SQL Server, but it wasn't at all happy understanding Oracle packages and views.
Quote:
make sure you're aware of the current capabilities - not what is was 6-7 years ago.
This was indeed 5-6 years ago, so newcomers will hopefully have a better experience with EF than we had :-).
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
In addition to what others said, there are two different EF frameworks: * EF6 is fine for most business work. It enables fast coding for the 99% of your application, and it's easy enough to use raw ADO.net for the 1% that's performance-sensitive; * EF Core does not support Distributed Transactions. For most business applications this is a dealbreaker: it's very common to have to write on different databases, even if both are residing on the same server. EF6 will happily join them in a single transaction, EF Core won't. This is why we are still on the .net framework and skipping .net core...
Luca The Price of Freedom is Eternal Vigilance. -- Wing Commander IV En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. (But the best thing God has created, is a New Day.) -- Sigur Ròs - Viðrar vel til loftárása
-
I know what opinions exist about Entity Framework from the C# developer view. What do those of you who have to maintain production databases think about developers using Entity Framework? Does it matter in your job? Does it positively or negatively affect database design or performance? Does its use ever cause you any headaches or make your job any easier? Thanks in advance.
I use EF not only with MS SQL, it fits fine also for nosql databases (eg Arango) . Yes it saves also work for dumb jobs like "list and some actions".
