Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Question for DB admins, DB architects, etc.

Question for DB admins, DB architects, etc.

Scheduled Pinned Locked Moved The Lounge
databasequestioncsharpdesignperformance
22 Posts 18 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L LucianPopescu

    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

    K Offline
    K Offline
    KateAshman
    wrote on last edited by
    #9

    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.

    1 Reply Last reply
    0
    • M MSBassSinger

      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.

      S Offline
      S Offline
      Slacker007
      wrote on last edited by
      #10

      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.

      1 Reply Last reply
      0
      • J Jan Holst Jensen2

        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.

        P Offline
        P Offline
        Phil Boyd
        wrote on last edited by
        #11

        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

        J 1 Reply Last reply
        0
        • Sander RosselS Sander Rossel

          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

          P Offline
          P Offline
          Phil Boyd
          wrote on last edited by
          #12

          I've never really like the migrations. I use a project/raw sql to generate and maintain my databases.

          Phil

          J 1 Reply Last reply
          0
          • M MSBassSinger

            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.

            J Offline
            J Offline
            Jorgen Andersson
            wrote on last edited by
            #13

            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

            1 Reply Last reply
            0
            • P Phil Boyd

              I've never really like the migrations. I use a project/raw sql to generate and maintain my databases.

              Phil

              J Offline
              J Offline
              jochance
              wrote on last edited by
              #14

              Flyway is excellent.

              1 Reply Last reply
              0
              • M MSBassSinger

                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.

                M Offline
                M Offline
                maze3
                wrote on last edited by
                #15

                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.

                1 Reply Last reply
                0
                • M MSBassSinger

                  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.

                  L Offline
                  L Offline
                  Lost User
                  wrote on last edited by
                  #16

                  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

                  M 1 Reply Last reply
                  0
                  • L Lost User

                    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

                    M Offline
                    M Offline
                    MSBassSinger
                    wrote on last edited by
                    #17

                    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.

                    1 Reply Last reply
                    0
                    • M MSBassSinger

                      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.

                      M Offline
                      M Offline
                      Matt McGuire
                      wrote on last edited by
                      #18

                      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.

                      1 Reply Last reply
                      0
                      • M MSBassSinger

                        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.

                        R Offline
                        R Offline
                        realJSOP
                        wrote on last edited by
                        #19

                        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

                        1 Reply Last reply
                        0
                        • P Phil Boyd

                          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

                          J Offline
                          J Offline
                          Jan Holst Jensen2
                          wrote on last edited by
                          #20

                          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 :-).

                          1 Reply Last reply
                          0
                          • M MSBassSinger

                            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.

                            L Offline
                            L Offline
                            Luca Leonardo Scorcia
                            wrote on last edited by
                            #21

                            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

                            1 Reply Last reply
                            0
                            • M MSBassSinger

                              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.

                              T Offline
                              T Offline
                              Tomasz Jureczko
                              wrote on last edited by
                              #22

                              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".

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • World
                              • Users
                              • Groups