To a "from zero" robust corporative application, I think code-first oriented modeling is a good approach, taking advantage of the SQL script generation to revise it and then execute with appropriated corrections (or not, hopefully).
The problem with that is almost no one ever goes back to make all the "appropriate corrections". For example, as a DBA, I just "love" it when someone defines a telephone number column and the system creates an NVARCHAR(256) column for it. Even better is when it creates a column using the NUMERIC(18) datatype for every bloody integer including those columns that will never contain more than a 1 or a 0.
While I appreciate many of the advantages of a "code first" approach, there are 4 huge disadvantages to it that make it totally not worthwhile, IMHO.
1) People who don't really know much about databases are the ones that frequently suggest the approach.
2) Because of that, they normally don't know enough to fix the generated scripts even if they were to look at them.
3) Even if they are pretty smart about databases, people rarely take the time to actually look at the scripts and fix them because it "works" at the time.
4) The cruddy auto-generated objects are usually good enough until the database final has some meat in it and then there's usually only one or two people that can actually fix it but there's so much to be fixed that the performance problems due to increased scale can't be fixed right away.
And, to be sure, the problems with "code first" doesn't just apply to front end code. A whole lot of batch file functionality is created in much the same way and with much worse effects because we're no longer dealing with just one row or one screen's worth of data anymore.
I've not ever seen a "code first" project scale well unless hundreds of servers are brought to bear in an MPP fashion. Most companies can't afford to do that so it also means that I also only ever seen one "code first" project scale.
Could "code first" projects scale properly? Yes they could... if they fix all the mistakes in the automatically generated objects and the people doing the work have a good understanding of the database objects behind the scenes. Usually, that's not the case and it makes for anything but a "robust corporative application".
is pronounced "ree-bar
" and is a "Modenism
" for R
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.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)