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"
-
...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"
Alaric_ wrote:
Guess who is up all night fixing someone else's quagmire.
Never fear, super dog is here?! ;P
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
...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"
-
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?
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.
-
...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"
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
-
...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"
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!
-
...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"
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 fuck 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
-
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 fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." -
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 fucking 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.
-
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 fuck 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 fucking 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 fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." -
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 fucking 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.
-
...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 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 fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada."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
-
...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"
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.
-
...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"
Code first is alright for throw away databases That's about it
-
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 fuck 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
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
-
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
-
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 fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." -
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.
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"