Code-first vs database-first, any new developments?

Question

Code-first vs database-first, any new developments?

Viewing 6 posts - 31 through 35 (of 35 total)

You must be logged in to reply to this topic. Login to reply

kevaburg SSCoach Points: 18131 More actions · Answer 1

FridayNightGiant - Friday, September 29, 2017 9:33 AM
kevaburg - Friday, September 29, 2017 8:01 AM
The theme of entity framework being used to create databases objects has bitten me more than once. The worst occasion was where I was troubleshotting a performance issue on a database that had no indexes, no relationships and no constraints. Why? Because the responsibility for these components was handed over to entity framework and the application. It was utter chaos.
I don't think you could blame EF for that. It is the people using it. I'm assuming it if they didn't use EF and those same people designed the database it will still have no indexes / relationships or constraints.
Issue is most users of EF will define a class like this
public class Customer { public int CustomerNumber { get; set; } public string CustomerName { get; set; } public string Region { get; set; } public bool Active { get; set; } }
and then a database person will come along and wonder where there are no keys, all the fields are nvarchar(max) and all the columns allow nulls.
Whereas a better way to setup that class in an EF Code First scenario would be like so.
This will set the CustomerNumber to be a Primary Key and it will
public class Customer { [Key] [DatabaseGenerated(DatabaseGeneratedOption.Identity)] public int CustomerNumber { get; set; } [MaxLength(150)] [Required] public string CustomerName { get; set; } [Column(TypeName = "char(10)")] [Required] public string Region { get; set; } [Required] [Index] public bool Active { get; set; } }

The problem was actually that the people that used EF didn't understand databases in the slightest and a meeting whereby the issue of ACID was discussed resulted in blank stares.

If EF really is up to the job then fine but too many people seem to use it as a fire-and-forget solution and that is where the problems stem. That is why I hold the ground that I do and push for the database to be build first and the application around it. Everything else (and bear in mind I am not a developer) looks to be more of a shortcut.

Luis Cazares SSC Guru Points: 183706 More actions · Answer 2

Steve Jones - SSC Editor - Friday, September 29, 2017 9:47 AM
To be fair, plenty of people use tools (ErWin, Er/Studio, Visio, SSMS, etc.) to design:
create table customer ( CustomerId int , Customername varchar(1000) , Address varchar(1000) , City varchar(1000) , State varchar(1000) , Country varchar(1000) , NonUSProvince varchar(1000) , PrimaryContact varchar(1000) , PrimaryContactEmail varchar(1000) , SecondaryContact varchar(1000) ... )
It's not the tools, it's not the framework, it's not the job description. It's the knowledge.

What kind of fool would design this? We should clearly use varchar(max) to avoid truncation. :hehe:

Luis C.
General Disclaimer:
Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

How to post data/code on a forum to get the best help: Option 1 / Option 2

TheSQLGuru SSC Guru Points: 134017 More actions · Answer 3

Luis Cazares - Friday, September 29, 2017 11:18 AM
Steve Jones - SSC Editor - Friday, September 29, 2017 9:47 AM
To be fair, plenty of people use tools (ErWin, Er/Studio, Visio, SSMS, etc.) to design:
create table customer ( CustomerId int , Customername varchar(1000) , Address varchar(1000) , City varchar(1000) , State varchar(1000) , Country varchar(1000) , NonUSProvince varchar(1000) , PrimaryContact varchar(1000) , PrimaryContactEmail varchar(1000) , SecondaryContact varchar(1000) ... )
It's not the tools, it's not the framework, it's not the job description. It's the knowledge.
What kind of fool would design this? We should clearly use varchar(max) to avoid truncation. :hehe:

Wouldn't it be varchar(255) instead?!? I still see a lot of that believe it or not, usually when the developer is in his 60s or older. 😀

Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service

Steve Jones - SSC Editor SSC Guru Points: 736478 More actions · Answer 4

I've seen both. Max, a "magic" number, and 255 from some frameworks.

Jason A. Long SSC-Insane Points: 23786 More actions · Answer 5

TheSQLGuru - Friday, September 29, 2017 12:57 PM
Luis Cazares - Friday, September 29, 2017 11:18 AM
Steve Jones - SSC Editor - Friday, September 29, 2017 9:47 AM
To be fair, plenty of people use tools (ErWin, Er/Studio, Visio, SSMS, etc.) to design:
create table customer ( CustomerId int , Customername varchar(1000) , Address varchar(1000) , City varchar(1000) , State varchar(1000) , Country varchar(1000) , NonUSProvince varchar(1000) , PrimaryContact varchar(1000) , PrimaryContactEmail varchar(1000) , SecondaryContact varchar(1000) ... )
It's not the tools, it's not the framework, it's not the job description. It's the knowledge.
What kind of fool would design this? We should clearly use varchar(max) to avoid truncation. :hehe:
Wouldn't it be varchar(255) instead?!? I still see a lot of that believe it or not, usually when the developer is in his 60s or older. 😀

I saw one example where EF had created everything with NVARCHAR(MAX)...

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 6

Steve Jones - SSC Editor - Friday, September 29, 2017 9:47 AM
To be fair, plenty of people use tools (ErWin, Er/Studio, Visio, SSMS, etc.) to design:
create table customer ( CustomerId int , Customername varchar(1000) , Address varchar(1000) , City varchar(1000) , State varchar(1000) , Country varchar(1000) , NonUSProvince varchar(1000) , PrimaryContact varchar(1000) , PrimaryContactEmail varchar(1000) , SecondaryContact varchar(1000) ... )
It's not the tools, it's not the framework, it's not the job description. It's the knowledge.

+ 1 Billion to that!

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)