I swear to God, Code First databases are the worst idea out of Redmond since the DataSet
-
...a really, really, really stupid idea. Let's pretend that EJB3 was a good idea. Let's double down on incompetent developers pretending they are passable data modelers. Let's double down on incompetent developers pretending they are database administrators. Let's double down on giving the application layers primacy over all others. Let's double down on incompetent developers resolving the Object Relational Impedance Mismatch by completely ignoring it. Let's double down on incompetent developers treating databases as little more than a bag for their crap. Guess who is up all night fixing someone else's quagmire.
"I need build Skynet. Plz send code"
I hear you. My one client decided to have some co-op students develop some web apps this way, and I have been working through this, trying to get it all working so that it is at least minimally useful ever since...
-
Bergholt Stuttley Johnson wrote:
Sounds like a DB admin rant. remember that some DB admins think that programmers are the spawn of the devil* and should not be let anywhere near the sacred databases
For the record, I'm an application architect and C# developer first. I'm also (I feel) a competent domain modeler, a competent relational data modeler, a competent "junior" database administrator, and a world class Service Nazi. And no, you absolutely aren't supposed to touch a database as an application developer. The relational model is an implementation detail. You can touch the database while wearing a data modeler's or a database administrator's hat, but not as an application developer. You will break shit.
"I need build Skynet. Plz send code"
yet by your own argument you should not be let near the DB, the problem isn't the Idea of code first but the fact that companies let staff attempt it without sufficient training - its not the tools its the implementation. sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application, and as such it should be driven by the application. I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions I would ensure that any code first project on my watch at least had the input from the database side if not one assigned as part of the project, to write off a tool because you feel left out is not the answer
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
tbh it sounds like you've got a management/personnel problem rather than a code/tool problem :D unless you're saying there's some limitation in EF code first?
cjb110 wrote:
unless you're saying there's some limitation in EF code first?
It's limited by design by not only allowing but promoting the structure of application artifacts(and the context that was used to write them) to dictate the persistence model of a system. As with the DataSet, if you are developing a toy, it works great. If you're trying to do anything substantial, it falls flat on its face and costs you more than it helps you.
"I need build Skynet. Plz send code"
-
yet by your own argument you should not be let near the DB, the problem isn't the Idea of code first but the fact that companies let staff attempt it without sufficient training - its not the tools its the implementation. sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application, and as such it should be driven by the application. I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions I would ensure that any code first project on my watch at least had the input from the database side if not one assigned as part of the project, to write off a tool because you feel left out is not the answer
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Bergholt Stuttley Johnson wrote:
yet by your own argument you should not be let near the DB
How so? You have misunderstood my argument(more of a rant than an actual argument) if you feel I said that.
Bergholt Stuttley Johnson wrote:
sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application,
Implementation detail. That's not to the application developer to decide. That's for the data modeler to decide, even if those are the same person.
Bergholt Stuttley Johnson wrote:
I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions
Over engineering is an orthogonal concern. If you have a defined layer of Views, Stored Procedures, and Functions as your interface into the database, then a DBA should have full rein to normalize the physical tables any way they see fit, within project constraints.
Bergholt Stuttley Johnson wrote:
to write off a tool because you feel left out is not the answer
I never feel left out. Crappy Entity Framework implementations and Code First databases have generated a ton of work for me. It's just disheartening to have to explain to businesses that the green field developers that dropped in on them with industry jargon and "bleeding edge" tools royally ripped them off.
"I need build Skynet. Plz send code"
-
You don't understand Code Based modelling. Then, you have incompetent developers. That's now three problems, the third being you have no competent DB developers/DBAs.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
Brady Kelly wrote:
You don't understand Code Based modelling. Then, you have incompetent developers. That's now three problems, the third being you have no competent DB developers/DBAs.
There's really very little to understand. Code based modeling came about as a way to "easily" maintain an implementation history of a database, which can be done just as effectively by other methods without castrating your data model.
"I need build Skynet. Plz send code"
-
...a really, really, really stupid idea. Let's pretend that EJB3 was a good idea. Let's double down on incompetent developers pretending they are passable data modelers. Let's double down on incompetent developers pretending they are database administrators. Let's double down on giving the application layers primacy over all others. Let's double down on incompetent developers resolving the Object Relational Impedance Mismatch by completely ignoring it. Let's double down on incompetent developers treating databases as little more than a bag for their crap. Guess who is up all night fixing someone else's quagmire.
"I need build Skynet. Plz send code"
My general rule of software development: "Design should be top-down, but implementation should be bottom-up." So I agree that code-first is wrong, but I don't agree with your stated reasons. Of course, middle-first is even worse. I have worked at only two places where there were proper DBAs who controlled the database and all the developers could do was ask for additions and changes, I couldn't make the changes myself. On all other jobs, including now, I have had full control of everything myself top-to-bottom and that's how I like it.