Question for DB admins, DB architects, etc.
-
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 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.
MSBassSinger wrote:
What do those of you who have to maintain production databases think about developers using Entity Framework?
It doesn't matter, it behind a tier.
MSBassSinger wrote:
Does it matter in your job?
Np, I have none and for hire.
MSBassSinger wrote:
Does it positively or negatively affect database design or performance?
Compared to what, Dapper?
MSBassSinger wrote:
Does its use ever cause you any headaches or make your job any easier?
I prefer SQL. No, we don't prefer it; it had not enough advantages over the proven path. Given it is the third layer, we prefer something proven.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
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.
using EF in my projects ? Are you crazy ? Have you seen what complicated queries it produces for just one simple table ? Never in my lifetime...
-
using EF in my projects ? Are you crazy ? Have you seen what complicated queries it produces for just one simple table ? Never in my lifetime...
Quote:
Have you seen what complicated queries it produces for just one simple table ?
Amen to that. And if you are not careful, it will also open multiple connections to the poor database server. And if you have had the audacity to use views and stored procedures to do a clean database design - oopsie, EF doesn't like that. I implement the business logic in the database and surface client-ready interfaces via views and stored procedures. That way, something like EF is not needed. But if you don't have a DBA around, and you are OK with using the database as dumb storage - then EF looks like a good fit.
-
using EF in my projects ? Are you crazy ? Have you seen what complicated queries it produces for just one simple table ? Never in my lifetime...
I think you guys used very old versions of EF, because I'm using EF for almost every project that I start and the queries are actually very clear and concise. In the end you can even execute your own queries with EF, the same way as you do with Dapper, I'm very satisfied with how EF actually works
-
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'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.
I've been using Entity Framework for about 10 years. Before that, I had 20 years experience in hand-coded SQL queries through stored procedures and views. So, I've used both approaches extensively. This is what I've found. Against: 1) It occasionally produces poor-performing queries, especially when they are big 2) It consistently produces queries that are very hard to understand For: 1) It saves a lot of time in the maintenance of stored procedures and views (or the ugliness of in-line SQL, if that's your thing) 2) You get compile-time checking. If I refactor my schema, my code breaks until I fix the problems. Does it matter in my job? Yes. Does it positively or negatively affect database design or performance? No affect on DB design - I design my database independently then hook EF up to that. It does have an affect on performance though in some cases. Generally, it's fine for simple CRUD operations, but where you have complex joins and grouping it can (but not necessarily will) produce slow queries. I'm generally pleasantly surprised by the perfomance. It produces crazy-looking queries with lots of sub-queries, but they seem to perform OK. I guess the EF designers know what SQL can handle. My approach is to use EF where EF is fine, then drop into views/stored procs where necessary. The difficulty here is with inexperienced team members who may never get the opportunity to learn to hand-code SQL, so will just rely on EF when they shouldn't. Also, some developers just don't like the idea of mixing strategries and would prefer all or nothing. Does its use ever cause you any headaches or make your job any easier? Yes and yes! The LINQ syntax can get very complex. Sometimes it's just quicker to write the SQL yourself. Occasionally queries need to be written in SQL for performance reasons. It all depends what you are doing really. If you are doing complex transactions on high volumes of data, then EF may not be the best choice for that. The time saver isn't so much not having to write T-SQL, but on the admin overhead of having to write views/sprocs seperately from the rest of my code. The compile-time checking is the real benefit for me though. In the past, a common problem I had was production bugs due to an obscure view or sproc that wasn't updated after a schema change. Now, I have a limited number of views and sprocs to check, and the rest is caught by the compiler. This is the single biggest advantage for me. It's reduced production bugs and
-
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.
Make sure you understand navigation properties in EF before you go into production 🤯
-
I think you guys used very old versions of EF, because I'm using EF for almost every project that I start and the queries are actually very clear and concise. In the end you can even execute your own queries with EF, the same way as you do with Dapper, I'm very satisfied with how EF actually works
Same thoughts exactly. A lot of DBA's dismiss the earlier versions and never re-evaluate it again, which is a professional mistake in my opinion. It has improved tremendously in the past decade or so, so much so that I would not start a new project/company without it again. The main reason for it's success, is that it successfully avoids the constant maintenance and performance issues you hit after 5 years or so doing the typical SQL designs. EF is more complex to maintain initially, but it scales up all the way to enterprise, for a fraction of the cost and with a lot less headaches along the way. Also, the typical "the queries are bad" response I get is disingenuous. All DB designs allow for bad queries, but with EF you get a sustainable way of solving them, instead of piling up complexity in either your DB design or constantly retraining developers in more advanced SQL approaches. Neither of those are cost effective in the long run.
-
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.
EF is an ORM at its core and must be approached as such. Yes, we use it all the time and it matters greatly to my/our team's job. If you design your database properly, then EF will work properly. Most, not all, the EF haters have no clue how to use EF. So, they spout off nonsense about EF, but in reality, they know nothing about it or how to use it properly. Good luck.
-
Quote:
Have you seen what complicated queries it produces for just one simple table ?
Amen to that. And if you are not careful, it will also open multiple connections to the poor database server. And if you have had the audacity to use views and stored procedures to do a clean database design - oopsie, EF doesn't like that. I implement the business logic in the database and surface client-ready interfaces via views and stored procedures. That way, something like EF is not needed. But if you don't have a DBA around, and you are OK with using the database as dumb storage - then EF looks like a good fit.
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
-
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 :-).
