September 25, 2017 at 2:51 pm
I'm discussing this topic with a developer, and I'm also performing due diligence and looking for other opinions on the internet. I'm finding quite a bit of information, and it's tough to tell how much more mature Code First (using the Entity Framework) has become. For instance, I'll see a post mention that it creates all varchar table columns as varchar(max), but then another which claims that Developers have total control over datatypes, relationships, indexes, etc.
I can't really tell if this argument has moved much farther along, based on innovations within the Entity Framework. Is Code First any more palatable from a DBA's perspective now, as opposed to 5 years ago?
--=Chuck
September 25, 2017 at 3:53 pm
chuck.forbes - Monday, September 25, 2017 2:51 PMI'm discussing this topic with a developer, and I'm also performing due diligence and looking for other opinions on the internet. I'm finding quite a bit of information, and it's tough to tell how much more mature Code First (using the Entity Framework) has become. For instance, I'll see a post mention that it creates all varchar table columns as varchar(max), but then another which claims that Developers have total control over datatypes, relationships, indexes, etc.I can't really tell if this argument has moved much farther along, based on innovations within the Entity Framework. Is Code First any more palatable from a DBA's perspective now, as opposed to 5 years ago?
--=Chuck
I've seen ORMs generate some amazingly terrible code. I also see developers who let EF generate database structure say how "that's just the way EF does it" and then suffer performance problems. Truth be told, I don't know enough about them to know if they're using them properly or not. They say it makes their lives easier. As for me, I don't use them.
I also define the database structure before I write a lick of front-end code. After all, once the tables, functions and procedures are created, the front end becomes much simpler to write. Granted, there can be a lot of changes that occur during the development process as new things are discovered, but I rarely (as in never) get a 100% complete specification that's been thoroughly thought through. Changes are a natural part of the game.
September 25, 2017 at 4:01 pm
I advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
September 26, 2017 at 10:36 am
TheSQLGuru - Monday, September 25, 2017 4:01 PMI advise clients to NEVER EVER EVER do code first. I also advise them that IF they MUST use an ORM, they MUST READ THE FINE MANUAL OR BE CRUSHED BY BAD STUFF.
+ 1 googolplex to the googolplex power.
I couldn't agree more. The idea of .Net C# folks designing databases in ANY tool, no matter how handy, should scare the CRAP out of ANY given DBA. This is HOW most of the problems I've ever had to fix came into existence. No thought to database architecture, and no thought to the overall design. Bad code = Bad performance, even if not right away, all it usually takes is a little data volume growth, and things start to "fall down, go boom"
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 26, 2017 at 10:54 am
Based on my personal history, I am far more comfortable with designing the database first. But, I also want to keep an open mind if conditions have improved within the Entity Framework. What I have trouble reconciling with our C# developers is the concept of consistency and maintainability in the database, and that being lost with Code First. I've only been with this shop for 2 years, so I have a keen memory for coming in and being lost in their db designs, with missing referential integrity, mis-matched datatypes between "keys", missing indexes, and so on. These systems were all built pre-CodeFirst concepts, and so I am leery that the same patterns could re-surface with Code First. And that's all without even getting into performance issues from a bad design.
Just re-reading my comments above I can already hear my soapbox scraping against the floor as I pull it out from under my bed to stand on. I really want to take a step back, though, and have a conversation with my developers about how well they can design from within Entity Framework, and then at least work backwards from as a mental exercise. Before I started, I was just looking to see if their toolset was better than it used to be.
--=cf
September 26, 2017 at 10:58 am
The answer is neither, you should have good requirements first. Then an agreed upon design between any front and database developers that can be worked on collaboratively as issues come up.
Of course that's in an ideal world 😛
September 26, 2017 at 1:02 pm
Neither database, nor code design first. You need to have a logical design which would include a correct ER design.
Skipping this step will only give headaches when trying to get an acceptable performance.
September 26, 2017 at 1:25 pm
I'll diverge slightly. I think Code First and other ORM solutions have lots of options and they can work well. The problem is that they are set up for the easiest, lowest common denominator. Just add properties to classes and the framework will build out, alter, manage the tables. They do, and if you spend a few minutes adding configuration to the various parts to set types and lengths, to include procs for more complex insert/update/delete stuff, then they work well. If you consider the choices in terms of relational mapping to object classes, you can get things to work well.
However, if you think about those items, you likely realize that in most cases it's easier, and better, to build the db outside of EF/nHibernate/etc and map to it. You build some procs where apporpriate, and you map those in. However, then you're really a better database developer and likely not interested in the easy way out.
If you don't take a little time to think about what choices you should make then you end up with a generic system that doesn't actually perform well after it grows above a developer's workstation.
September 27, 2017 at 7:45 am
September 27, 2017 at 8:05 am
Steve Jones - SSC Editor - Tuesday, September 26, 2017 1:25 PMI'll diverge slightly. I think Code First and other ORM solutions have lots of options and they can work well. The problem is that they are set up for the easiest, lowest common denominator. Just add properties to classes and the framework will build out, alter, manage the tables. They do, and if you spend a few minutes adding configuration to the various parts to set types and lengths, to include procs for more complex insert/update/delete stuff, then they work well. If you consider the choices in terms of relational mapping to object classes, you can get things to work well.However, if you think about those items, you likely realize that in most cases it's easier, and better, to build the db outside of EF/nHibernate/etc and map to it. You build some procs where apporpriate, and you map those in. However, then you're really a better database developer and likely not interested in the easy way out.
If you don't take a little time to think about what choices you should make then you end up with a generic system that doesn't actually perform well after it grows above a developer's workstation.
I agree there are lot of options in these frameworks, EF came long way. But main difference is they are build with one thought ease of development and reduce the coordination, not ease of database maintenance. Unless a logical design and then physical design is created first, the tables or columns will be created adhocly. The focus never remains how the database will be maintained and how better performance can be achieved.
September 27, 2017 at 8:42 am
Here's my Guruism related to ORMs (and numerous other things too):
Anything that allows developers to slap code together more quickly is inversely proportional to the performance and concurrency you will get from that code.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
September 27, 2017 at 9:01 am
TheSQLGuru - Wednesday, September 27, 2017 8:42 AMHere's my Guruism related to ORMs (and numerous other things too):Anything that allows developers to slap code together more quickly is inversely proportional to the performance and concurrency you will get from that code.
And yet another + 1 googolplex to the googolplex power !!!
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 27, 2017 at 9:09 am
sgmunson - Wednesday, September 27, 2017 9:01 AMTheSQLGuru - Wednesday, September 27, 2017 8:42 AMHere's my Guruism related to ORMs (and numerous other things too):Anything that allows developers to slap code together more quickly is inversely proportional to the performance and concurrency you will get from that code.
And yet another + 1 googolplex to the googolplex power !!!
I think I should trademark my Guruisms!! 😎
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
September 27, 2017 at 9:09 am
chuck.forbes - Monday, September 25, 2017 2:51 PMI'm discussing this topic with a developer, and I'm also performing due diligence and looking for other opinions on the internet. I'm finding quite a bit of information, and it's tough to tell how much more mature Code First (using the Entity Framework) has become. For instance, I'll see a post mention that it creates all varchar table columns as varchar(max), but then another which claims that Developers have total control over datatypes, relationships, indexes, etc.I can't really tell if this argument has moved much farther along, based on innovations within the Entity Framework. Is Code First any more palatable from a DBA's perspective now, as opposed to 5 years ago?
--=Chuck
To be honest and with absolutely no reflection on you intended, the terms "Code First" and "Database First" are both ignorant and stupid (and always have been) and tend to perpetuate the "Ivory Tower" syndrome on both sides of the house that so many shops suffer. I work very closely with the Developers at all times and it is a symbiosis. When are people going to learn that there are absolute experts on both sides and each side can help the other accomplish the goals of a project in a spritely manner and with a whole lot less rework especially if both sides are following the same plan and design requirements. Notice that's not a question. It's a suggestion. Drop your egos or drop your pants for a royal screwing. The choice is yours.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 27, 2017 at 9:10 am
Oh, and another Guruism specifically for Entity Framework, and this topic in particular:
Code First, Performance Last!!
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply