|
...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"
modified 11-Feb-15 1:35am.
|
|
|
|
|
Alaric_ wrote: Guess who is up all night fixing someone else's quagmire.
Never fear, super dog is here?! 
|
|
|
|
|
tbh it sounds like you've got a management/personnel problem rather than a code/tool problem 
unless you're saying there's some limitation in EF code first?
|
|
|
|
|
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
*(not that some programmers are not the spawn of the devil)
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Speak for yourself, little spawn. 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
I thought you were busy annoying the Greeks
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
I was busy having a cold last week and having to fix an entire list of highest priority problems in motor testing software for expensive cars. I never was in the moneylending business.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
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 sh*t.
"I need build Skynet. Plz send code"
modified 11-Feb-15 11:09am.
|
|
|
|
|
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"
modified 11-Feb-15 12:30pm.
|
|
|
|
|
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"
modified 11-Feb-15 12:52pm.
|
|
|
|
|
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"
|
|
|
|
|
The problem with being a clever bugger is that you might get to thinking that you can do everyone's job better than they can.
Development is a field that has lots and lots of clever buggers, ergo...
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
As with just about everything in software development, if it is implemented badly it is a crock of shite.
But blameth not the tool, for t'is the wielder of the tool that is the tool.
code 1st database could be a good idea if it is well understood by the developer who creates suitable classes to be stored efficiently etc.
But the people that want to use that sort of thing tend to be those that are scared of those three letters (SQL) so feel more comfortable treating that side of things as a black box.
it is, unfortunately, black like the heart of a serial killer.
I have worked at so many places where the developers use some sort of ORM system (code first or Data first) and just f*** it up because they don't think about what it's doing behind the scenes.
Imagine a system displaying three months of an appointment calendar, for three people, where appointments are, say, 30 minutes long. So 16 appointments per day, 90 days, 3 people - that's over 4000 appointments.
Now imagine someone uses an ORM to grab the details; each appointment has a customer, and a doctor - so off they go to the ORM and ask for the details of those appointments. What do they get back? Gigabytes of data, names, addresses, previous appointments etc. etc.
What gets displayed on the screen? Their name!
Because they wanted to save a little time writing some SQL by having some clever little system write it for them - but never thought to check what they were actually returning from the database was relevant to what they actually needed!
The appointment example was a real system - and they asked for it to refresh every 30 seconds so they always saw up-to-date appointments.
"It worked fine in testing" - yes - with a handful of test appointments for one person.
First real test at refreshing stopped the entire system as the network flooded with data from the database server.
I digress.
PooperPig - Coming Soon
|
|
|
|
|
I have just the opposite right in front of my nose at this very moment. There is no distinction between layers. The whole application's logic is squeezed into stored procedures and database triggers.
Main properties of this 'code':
- It's 100% unreadable. Any hint to what's going on is hidden under masses of SQL, crazy casts, magic numbers, wild joins and thousands of lines of spaghetti code.
- It's redundant, every single task is also done in a similar way in several other procedures.
- Things are never as they seem. On every data table are several triggers. The triggers are extremely long, often thousands of lines and try to handle every consequence of every thinkable change in their datatables. And, of course, they also set off some more triggers. Even changing the sequence of some unrelated SQL statements in an SP can cause a totally different reaction of the triggers.
If I had the choice right now, I would much more like to deal with an ORM running amok than with this trigger hell.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
I agree, I'll take an ORM anyday over stored procedures and views.
'Couple of years ago I took over a project with *lots* of stored procedures and views; hated it:
* code changes, there was no source control system for TSQL, which version is the latest?
* debugging, how do you stop at a breakpoint in TSQL code?
* tracing, how do you trace (i.e. showing stuff in DbgView.exe) from TSQL?
etc.
|
|
|
|
|
CDP1802 wrote: I would much more like to deal with an ORM running amok than with this trigger hell.
I'd much rather deal with neither!
This sounds like another case of ill-equipped developers using the wrong tool for the job!
don't you find this sort of thing just completely frustrating?!
On the one hand the ORM fanbois point to crap like you have, and justify using an ORM because of it.
But SQL fanbois point to cruddy ORM implementations and use that a their reasoning for avoiding them.
I don't suggest a "why can't we all just get along" attitude, but more of a "Learn to use the tools, understand the tools, choose the appropriate tools, use the tools well, look after the tools" attitude.
It's like the curly-bracket-on-the-same-line debate. Almost nobody justifies their position with more than a "that's how I do it so it must be better" argument.
I mean - is Vegemite better than Marmite? If you're giving it to an Aussie kid, probably yes. Giving it to a pommie kid, probably no - because it's just what they're used to. If the kid eats the bread from teh middle out, and gets covered in vegemite, changing his diet to marmite will just produce a slightly different shade of mess!
The solution is to teach him to eat properly!
PooperPig - Coming Soon
|
|
|
|
|
Personally, I lean strongly to the orderly layered object oriented world and really treat the database as a storage system which I abstract away by writing DAO classes with CRUD data access methods.
This is very DRY (no redundance) and also quite easy to stick to the single responsibility principle. Both help me to write applications with little trouble from the beginning and locate and fix errors if they still arise.
Beyond those very basic architectural principles, I think most conventions, rules, guidelines and principles are pointless. They tend to complicate things more than they actually help in any way.
Much less are they anything to start a holy war over. ORMs may do a lot for you, but also make you spend a lot of time learning to configure the ORM for the job at hand. Doing everything in stored procedures holds to many 'un's for me: Unreadable. Undebuggable. Unstructured. Unmaintainable.
I think it's best to find the (for you and your goals) optimal spot between all those worlds, build a clean prototype and then get your team behind you to get some paid work done with this.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
The interesting exchange between you and CDP1802 here has motivated me to ask a question on the "Design and Architecture" forum: [^]. Would appreciate your response when/if you have time.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
Well I for one think code-first databases rock! 
|
|
|
|
|
The code first approach is only best where the database is only used a mere persistence mechanism for some model information.
If we want an application that is heavily data-centric and there are a lot of database operations involved, code first is definitely not the way to go. In such cases database first should be used. So all enterprise grade applications should not even think about code first we they want to have a decent database structure. Database is something that DBAs should worry about and it should never be at the mercy of developers(if its a large application).
P.S. I try to stay away from code first for large applications. Its bad enough that I have to deal with the bad code of others. If I use code first, I will also have to worry about the bad database too.
|
|
|
|
|
Code first is alright for throw away databases
That's about it
|
|
|
|
|
RugbyLeague wrote: Code first is alright for throw away databases
... because ?
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
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...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
