May 8, 2018 at 3:48 pm
patrickmcginnis59 10839 - Tuesday, May 8, 2018 12:48 PMIt is no secret that queries from ORMs are horrific.
I think they can be but I would ask these questions, do you need those to eliminate stored procedures, and is it possible to use them effectively if they are needed in that case or desired?
Remember, I insist on competencies, and from what I've read, you'd better know your stuff with ORM's before you consider using them.
Theres the possibility that some folks think that programming environments that make you extra productive do so by making things easy to understand, but I disagree very much with that assertion simply by some of the incredible programming tools that I've encountered. Maybe its possible that some do, but some certainly multiply your productivity but require high levels of competency, and all the experts I have read regarding ORM's well, they mean business about competence. If your programmers are incompetent then their successful use of ORM's will be in question.
But to summarise there, yes I agree ORM's can create a mess, I can't disagree with you there.
As to your assumption of competency, I would offer this: I've been working on systems messed up by a lack of competency that is often the entire development team along with several layers of management, for the last 20 years, and the last 10 of that in contract roles, so the very idea that there is any place where such competency can actually be assumed is NOT a reasonable perspective. That's why code reviews and DBAs exist in the first place. At least some of those folks learned to adapt to the fact that most devs are not very good with database coding. I could probably go fix stuff for another 20 years and still not make much of a dent because the number of those actually competent is so small in comparison. But you go ahead and assume. Just don't expect to ever work with me...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
May 8, 2018 at 3:58 pm
sgmunson - Tuesday, May 8, 2018 3:48 PMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 12:48 PMIt is no secret that queries from ORMs are horrific.
I think they can be but I would ask these questions, do you need those to eliminate stored procedures, and is it possible to use them effectively if they are needed in that case or desired?
Remember, I insist on competencies, and from what I've read, you'd better know your stuff with ORM's before you consider using them.
Theres the possibility that some folks think that programming environments that make you extra productive do so by making things easy to understand, but I disagree very much with that assertion simply by some of the incredible programming tools that I've encountered. Maybe its possible that some do, but some certainly multiply your productivity but require high levels of competency, and all the experts I have read regarding ORM's well, they mean business about competence. If your programmers are incompetent then their successful use of ORM's will be in question.
But to summarise there, yes I agree ORM's can create a mess, I can't disagree with you there.
As to your assumption of competency, I would offer this: I've been working on systems messed up by a lack of competency that is often the entire development team along with several layers of management, for the last 20 years, and the last 10 of that in contract roles, so the very idea that there is any place where such competency can actually be assumed is NOT a reasonable perspective. That's why code reviews and DBAs exist in the first place. At least some of those folks learned to adapt to the fact that most devs are not very good with database coding. I could probably go fix stuff for another 20 years and still not make much of a dent because the number of those actually competent is so small in comparison. But you go ahead and assume. Just don't expect to ever work with me...
Hmmm this "Just don't expect to ever work with me..." can you elaborate on that some? Did I do something or post something that disqualified me from working for you? I am eagerly awaiting your response, I look forward to enhancing my skillset to whatever degree that would rectify this most undesirable deficiency! What level of competency did I assume or not assume that did not meet with your approval? I was unaware that I was posting anything other than the most carefully considered and researched technical advice that I could muster given my abilities. Did I fall short somewhere?
May 8, 2018 at 5:09 pm
Steve Jones - SSC Editor - Tuesday, May 8, 2018 8:47 AMAlso, what you're describing is what DevOps is about.
Agreed. And I don't know any other way to fly. I've never liked the idea of silos. Perhaps it's because of the training I went through on submarines (despite the fact that it looks like a horizontal silo :D). Everyone helped everyone. We all had our main jobs but we all trained on different watch stations and systems.
Ahem, maybe you'd like to get back to writing some of that knowledge down to share? 😉
Heh... as I "threatened" before, I'm almost there. Work, family, and some SQL related events (like taking over a PASS chapter with Ed Wagner and speaking on a regular basis at that one and the one in Lansing) are finally starting to calm down a bit. The cool part is the presentations have been mostly about things I've taught myself because of requirements at work. Lots of good subjects to write about there.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2018 at 9:10 pm
Steve Thompson-454462 - Tuesday, May 8, 2018 10:23 AMSergiy - Tuesday, May 8, 2018 12:32 AMYeah, I like this bulk of nonsense.
"Working software over comprehensive documentation"
What's the criteria for "working software"?
Who/what defines if it's working or not?The definition of "working" is governed by the team's Definition of Done (which applies to all stories in the project) and the Acceptance Criteria which is tailored for each story.
So the who = a combination of the team and the product owner (who proxies for the "customer"). The what encompasses everything from specifying the appropriate amount of test unit coverage, passing regression and integration tests, code reviews and user acceptance testing, as well as leaving room for any other quality check the team feels adds value.
Steve, you've mixed a Scrum thing and an Agile practice into your response to a question about the Agile Manifesto and I want to separate them out for clarity in case you have a misunderstanding and also so Sergiy and other readers are not misled.
1. Working software over comprehensive documentation is an Agile value. This is nothing to do with processes or artifacts. It simply says we value the item on the left more than on the right while at the same time implying that we still value the item on the right, just less so. The definition of working is left to the implementation however at the end of the day we're judged by what we deliver to our customers, hence my earlier response.
2. The Definition of Done (DoD) is a part of the Scrum framework and is not part of the Agile Manifesto. This is where the left to the implementation kicks in. Scrum is an Agile framework and it helps put some structure around what is considered working, although the Scrum Guide is silent on the definition of working so citing the DoD as the definition of working would be team specific. The Definition of Done defines Doneness, nothing more. Have you ever seen developers that have developed something that satisfies all written requirements yet the end user opens a ticket that says "xyz doesn't work?"
3. User Stories are not part of Scrum nor the Agile Manifesto. They are an Agile practice, some even describe it as a mindset or a behavior, that was designed to help us overcome two major challenges: 1. written requirements documents don't work 2. there is too much to build. Item 1 we've covered. Item 2 gets into prioritization, sizing and business value propositions which addresses a huge problem with big up-front analysis and exhaustive comprehensive requirements documentation, lots of waste.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 9, 2018 at 1:41 am
Steve Thompson-454462 - Tuesday, May 8, 2018 2:23 PMNo, I would't consider making acceptance criteria and quality measures explicit the same as comprehensively documenting the software - that strikes me as the minimal viable documentation.
Yeah, "minimal viable documentation" must be what they used in TSB as acceptance criteria for new online banking software.
Had someone spent time developing comprehensive document for testing and quality acceptance - may be the bank would stay on the market.
_____________
Code for TallyGenerator
May 9, 2018 at 6:34 am
Sergiy - Wednesday, May 9, 2018 1:41 AMSteve Thompson-454462 - Tuesday, May 8, 2018 2:23 PMNo, I would't consider making acceptance criteria and quality measures explicit the same as comprehensively documenting the software - that strikes me as the minimal viable documentation.Yeah, "minimal viable documentation" must be what they used in TSB as acceptance criteria for new online banking software.
Had someone spent time developing comprehensive document for testing and quality acceptance - may be the bank would stay on the market.
Not sure acceptance criteria means what you think it means, at least you're not using it how Steve used it.
In the end TSB probably produced a lot of documentation that was not viable. I have seen reams and reams of paper that couldn't replace a half-day in-person design workshop and I've experienced the process of writing things down in great detail help me think through a really difficult problem. It's whatever works for each person. The key operative word is viable. Anything produced over and above what is needed to create working software is waste.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 9, 2018 at 6:55 am
patrickmcginnis59 10839 - Tuesday, May 8, 2018 3:58 PMsgmunson - Tuesday, May 8, 2018 3:48 PMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 12:48 PMIt is no secret that queries from ORMs are horrific.
I think they can be but I would ask these questions, do you need those to eliminate stored procedures, and is it possible to use them effectively if they are needed in that case or desired?
Remember, I insist on competencies, and from what I've read, you'd better know your stuff with ORM's before you consider using them.
Theres the possibility that some folks think that programming environments that make you extra productive do so by making things easy to understand, but I disagree very much with that assertion simply by some of the incredible programming tools that I've encountered. Maybe its possible that some do, but some certainly multiply your productivity but require high levels of competency, and all the experts I have read regarding ORM's well, they mean business about competence. If your programmers are incompetent then their successful use of ORM's will be in question.
But to summarise there, yes I agree ORM's can create a mess, I can't disagree with you there.
As to your assumption of competency, I would offer this: I've been working on systems messed up by a lack of competency that is often the entire development team along with several layers of management, for the last 20 years, and the last 10 of that in contract roles, so the very idea that there is any place where such competency can actually be assumed is NOT a reasonable perspective. That's why code reviews and DBAs exist in the first place. At least some of those folks learned to adapt to the fact that most devs are not very good with database coding. I could probably go fix stuff for another 20 years and still not make much of a dent because the number of those actually competent is so small in comparison. But you go ahead and assume. Just don't expect to ever work with me...
Hmmm this "Just don't expect to ever work with me..." can you elaborate on that some? Did I do something or post something that disqualified me from working for you? I am eagerly awaiting your response, I look forward to enhancing my skillset to whatever degree that would rectify this most undesirable deficiency! What level of competency did I assume or not assume that did not meet with your approval? I was unaware that I was posting anything other than the most carefully considered and researched technical advice that I could muster given my abilities. Did I fall short somewhere?
Sure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance. That might be more valuable to lawyers practicing argument pre-trial, but in the IT world, devil's advocates have to identify the flaws in the alternative arguments as well as any in the more supported perspective. Continuing to argue for a bad idea and then justifying it as a devil's advocate role is likely to be perceived more as political nuisance than valuable contribution. Where I come from, that's a quick path to irrelevance. I avoid folks that do that like I'd avoid the plague, and thus the "don't expect to work with me" comment.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
May 9, 2018 at 7:12 am
sgmunson - Wednesday, May 9, 2018 6:55 AMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 3:58 PMsgmunson - Tuesday, May 8, 2018 3:48 PMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 12:48 PMIt is no secret that queries from ORMs are horrific.
I think they can be but I would ask these questions, do you need those to eliminate stored procedures, and is it possible to use them effectively if they are needed in that case or desired?
Remember, I insist on competencies, and from what I've read, you'd better know your stuff with ORM's before you consider using them.
Theres the possibility that some folks think that programming environments that make you extra productive do so by making things easy to understand, but I disagree very much with that assertion simply by some of the incredible programming tools that I've encountered. Maybe its possible that some do, but some certainly multiply your productivity but require high levels of competency, and all the experts I have read regarding ORM's well, they mean business about competence. If your programmers are incompetent then their successful use of ORM's will be in question.
But to summarise there, yes I agree ORM's can create a mess, I can't disagree with you there.
As to your assumption of competency, I would offer this: I've been working on systems messed up by a lack of competency that is often the entire development team along with several layers of management, for the last 20 years, and the last 10 of that in contract roles, so the very idea that there is any place where such competency can actually be assumed is NOT a reasonable perspective. That's why code reviews and DBAs exist in the first place. At least some of those folks learned to adapt to the fact that most devs are not very good with database coding. I could probably go fix stuff for another 20 years and still not make much of a dent because the number of those actually competent is so small in comparison. But you go ahead and assume. Just don't expect to ever work with me...
Hmmm this "Just don't expect to ever work with me..." can you elaborate on that some? Did I do something or post something that disqualified me from working for you? I am eagerly awaiting your response, I look forward to enhancing my skillset to whatever degree that would rectify this most undesirable deficiency! What level of competency did I assume or not assume that did not meet with your approval? I was unaware that I was posting anything other than the most carefully considered and researched technical advice that I could muster given my abilities. Did I fall short somewhere?
Sure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance. That might be more valuable to lawyers practicing argument pre-trial, but in the IT world, devil's advocates have to identify the flaws in the alternative arguments as well as any in the more supported perspective. Continuing to argue for a bad idea and then justifying it as a devil's advocate role is likely to be perceived more as political nuisance than valuable contribution. Where I come from, that's a quick path to irrelevance. I avoid folks that do that like I'd avoid the plague, and thus the "don't expect to work with me" comment.
Its an absolute must for me to know the facts. Its probably a good idea for the OP to know also, and prepare for what directions that he might find himself being offered, so just offering that up for anyone who cares to consider it, but I'm ok with you taking a pass!
May 9, 2018 at 8:18 am
Orlando Colamatteo - Tuesday, May 8, 2018 9:10 PMSteve Thompson-454462 - Tuesday, May 8, 2018 10:23 AMThe definition of "working" is governed by the team's Definition of Done (which applies to all stories in the project) and the Acceptance Criteria which is tailored for each story.
So the who = a combination of the team and the product owner (who proxies for the "customer"). The what encompasses everything from specifying the appropriate amount of test unit coverage, passing regression and integration tests, code reviews and user acceptance testing, as well as leaving room for any other quality check the team feels adds value.Steve, you've mixed a Scrum thing and an Agile practice into your response to a question about the Agile Manifesto and I want to separate them out for clarity in case you have a misunderstanding and also so Sergiy and other readers are not misled.
1. Working software over comprehensive documentation is an Agile value. This is nothing to do with processes or artifacts. It simply says we value the item on the left more than on the right while at the same time implying that we still value the item on the right, just less so. The definition of working is left to the implementation however at the end of the day we're judged by what we deliver to our customers, hence my earlier response.
2. The Definition of Done (DoD) is a part of the Scrum framework and is not part of the Agile Manifesto. This is where the left to the implementation kicks in. Scrum is an Agile framework and it helps put some structure around what is considered working, although the Scrum Guide is silent on the definition of working so citing the DoD as the definition of working would be team specific. The Definition of Done defines Doneness, nothing more. Have you ever seen developers that have developed something that satisfies all written requirements yet the end user opens a ticket that says "xyz doesn't work?"
3. User Stories are not part of Scrum nor the Agile Manifesto. They are an Agile practice, some even describe it as a mindset or a behavior, that was designed to help us overcome two major challenges: 1. written requirements documents don't work 2. there is too much to build. Item 1 we've covered. Item 2 gets into prioritization, sizing and business value propositions which addresses a huge problem with big up-front analysis and exhaustive comprehensive requirements documentation, lots of waste.
All good points, Orlando. Mainly I was trying to address the implication that adapting an Agile framework results in having no real concept of what "working" means. The Manifesto is driving home that delivering potentially releasable functionality is a better value proposition than delivering detailed documentation but no implementation (such as might happen in the early phases of a Waterfall project). So, my post was defending the fact that Agile teams do have mechanisms by which "working", i.e. potentially releasable, is determined.
But, as you point out, Agile is more than just Scrum, and the Manifesto is separate from the practices it engenders. Also, the self-organizing aspect of the framework often leads to teams doing "Scrum, but...". On teams I've worked with, DoDs are often developed for each stage of the CI pipeline, so that quality checks, such as passing code review before a merge request is completed, are made explicit. May not be canonical but it does seem to bring value.
May 9, 2018 at 8:33 am
sgmunson - Wednesday, May 9, 2018 6:55 AMSure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance.
I've been following this thread closely and, in Patrick's defense, I don't think he's been arguing illogically at all. You suggest that that your 20 years of experience make your opinions irrefutable, but I have coming up on 30 years of experience, and whereas much of my data layer architecture has included a stored procedure based interface just as you advocate for, I have also seen plenty of deployments where CRUD operations are handled just fine by an ORM framework, with business logic being encoded elsewhere. I feel like this is pretty close to what Patrick has been saying and there's nothing illogical about it - these systems are out there, working to spec as I type.
In fact, in microservice architectures, encompassing large amounts of business logic in a monolithic database would be considered an anti-pattern, but restricting an ORM-based DAL to simple CRUD operations works well.
With that said, would I promote tearing down a functioning SP-based interface in a brown field project, as Luis suggests his company is considering? No I would not. And I believe Patrick has said much the same over his posts.
May 9, 2018 at 10:14 am
Steve Thompson-454462 - Wednesday, May 9, 2018 8:33 AMsgmunson - Wednesday, May 9, 2018 6:55 AMSure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance.I've been following this thread closely and, in Patrick's defense, I don't think he's been arguing illogically at all. You suggest that that your 20 years of experience make your opinions irrefutable, but I have coming up on 30 years of experience, and whereas much of my data layer architecture has included a stored procedure based interface just as you advocate for, I have also seen plenty of deployments where CRUD operations are handled just fine by an ORM framework, with business logic being encoded elsewhere. I feel like this is pretty close to what Patrick has been saying and there's nothing illogical about it - these systems are out there, working to spec as I type.
In fact, in microservice architectures, encompassing large amounts of business logic in a monolithic database would be considered an anti-pattern, but restricting an ORM-based DAL to simple CRUD operations works well.
With that said, would I promote tearing down a functioning SP-based interface in a brown field project, as Luis suggests his company is considering? No I would not. And I believe Patrick has said much the same over his posts.
My mention of experience was not intended to be anything other than a statement of fact, and in that respect, I have another 15 years to add to that, having had a front-row seat to watching as database project after database project went wrong because the depth of incompetence was so deep that there wasn't really any attempt to do it even remotely right. Management was cycled in and out, PMs came and went, and very little changed until the upper management level got canned after a multi-million dollar project went so badly that even recovery from it was going to be problematic. Up to that point, there always seemed to be time to do it wrong at least 3 times, if not 4 or 5. ORM and other variations were certainly common elements in most of the problems, and because stored procedures were not being used, even for CRUD, any changes to the applications, which were quite frequent due to the failure to do much in the way of useful database design or user interaction to gather requirements, often took anywhere from a month and a half to as long as 6 months. Then by the time the users noticed there was a problem, it was going to be another couple of months to fix the application in concert with the now necessary database changes. Most of that could have been avoided if stored procedures had been in place, as a few simple changes there could have minimized the impact and the app could have been updated and fixed in a couple of days instead of a month or more. So if you expect me to buy into sprocs ever being unnecessary, forget it. They are just too valuable to ignore, and they can achieve cost avoidance in ways you might not even imagine, when properly designed and implemented.
And since you mentioned that you had 30 years of experience, do you want me to believe that this suddenly makes facts refutable? Or were you just trying to take out your measuring stick? Take the ego elsewhere.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
May 9, 2018 at 10:26 am
sgmunson - Wednesday, May 9, 2018 10:14 AMSteve Thompson-454462 - Wednesday, May 9, 2018 8:33 AMsgmunson - Wednesday, May 9, 2018 6:55 AMSure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance.I've been following this thread closely and, in Patrick's defense, I don't think he's been arguing illogically at all. You suggest that that your 20 years of experience make your opinions irrefutable, but I have coming up on 30 years of experience, and whereas much of my data layer architecture has included a stored procedure based interface just as you advocate for, I have also seen plenty of deployments where CRUD operations are handled just fine by an ORM framework, with business logic being encoded elsewhere. I feel like this is pretty close to what Patrick has been saying and there's nothing illogical about it - these systems are out there, working to spec as I type.
In fact, in microservice architectures, encompassing large amounts of business logic in a monolithic database would be considered an anti-pattern, but restricting an ORM-based DAL to simple CRUD operations works well.
With that said, would I promote tearing down a functioning SP-based interface in a brown field project, as Luis suggests his company is considering? No I would not. And I believe Patrick has said much the same over his posts.
My mention of experience was not intended to be anything other than a statement of fact, and in that respect, I have another 15 years to add to that, having had a front-row seat to watching as database project after database project went wrong because the depth of incompetence was so deep that there wasn't really any attempt to do it even remotely right. Management was cycled in and out, PMs came and went, and very little changed until the upper management level got canned after a multi-million dollar project went so badly that even recovery from it was going to be problematic. Up to that point, there always seemed to be time to do it wrong at least 3 times, if not 4 or 5. ORM and other variations were certainly common elements in most of the problems, and because stored procedures were not being used, even for CRUD, any changes to the applications, which were quite frequent due to the failure to do much in the way of useful database design or user interaction to gather requirements, often took anywhere from a month and a half to as long as 6 months. Then by the time the users noticed there was a problem, it was going to be another couple of months to fix the application in concert with the now necessary database changes. Most of that could have been avoided if stored procedures had been in place, as a few simple changes there could have minimized the impact and the app could have been updated and fixed in a couple of days instead of a month or more. So if you expect me to buy into sprocs ever being unnecessary, forget it. They are just too valuable to ignore, and they can achieve cost avoidance in ways you might not even imagine, when properly designed and implemented.
And since you mentioned that you had 30 years of experience, do you want me to believe that this suddenly makes facts refutable? Or were you just trying to take out your measuring stick? Take the ego elsewhere.
All that experience provides is a single point of view. I have worked for 40 years in the IT field. My experience does not validate or invalidate the experience of others, it just provides another point of view. What you have experienced may not be what I have experienced. In the database side of my career (over 20 years) I have had the pleasure (or displeasure depending on your POV) of working in relatively small and stable environments and not dealing with some of the issues others have experienced. That is one of the reasons I try to stay active here, to see and hopefully learn from other experiences. No ego, just a desire to gain from other peoples POV.
May 9, 2018 at 10:41 am
Steve Thompson-454462 - Wednesday, May 9, 2018 8:33 AMsgmunson - Wednesday, May 9, 2018 6:55 AMSure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance.I've been following this thread closely and, in Patrick's defense, I don't think he's been arguing illogically at all. You suggest that that your 20 years of experience make your opinions irrefutable, but I have coming up on 30 years of experience, and whereas much of my data layer architecture has included a stored procedure based interface just as you advocate for, I have also seen plenty of deployments where CRUD operations are handled just fine by an ORM framework, with business logic being encoded elsewhere. I feel like this is pretty close to what Patrick has been saying and there's nothing illogical about it - these systems are out there, working to spec as I type.
In fact, in microservice architectures, encompassing large amounts of business logic in a monolithic database would be considered an anti-pattern, but restricting an ORM-based DAL to simple CRUD operations works well.
With that said, would I promote tearing down a functioning SP-based interface in a brown field project, as Luis suggests his company is considering? No I would not. And I believe Patrick has said much the same over his posts.
Thanks for considering other viewpoints! I work with a small team, and we've agreed with the advantages with stored procedures, and with the projects we can carve out in our little niche thats what we use. I'm really comfortable with SQL Server and have confidence that I can keep the data safe and consistent.
On the other hand I've seen a big project that takes the other direction, its a big honking Microsoft install, and its got its own school of thought on how to program databases and we experienced the same trepidation that Luis is experiencing. However, given the system it replaced, I was all on board with our project even with the lack of stored procedures and differing paradigm so theres that bit of anecdotal information, simply because its my belief that the system helps the company immensely and once that the decision is made and we're in the process, I'm on board, and I am sure that once the cards fall in Luis situation, he'll be able to handle it in the same professional manner he has demonstrated time and again here at SSC.
Maybe being a "devils advocate" causes some negativity for some, but I find that when preparing for a meeting, presentation, or process of advocacy, efforts to anticipate information points counter to mine leads me to do all the more homework in preparation for these encounters, thats all I'm saying, and even if some folks may not like me cluttering up the thread here with this sort of thought, hopefully at least yall know why I do it even if the only result for me is some typing practice 😉
May 9, 2018 at 10:48 am
Lynn Pettis - Wednesday, May 9, 2018 10:26 AMsgmunson - Wednesday, May 9, 2018 10:14 AMSteve Thompson-454462 - Wednesday, May 9, 2018 8:33 AMsgmunson - Wednesday, May 9, 2018 6:55 AMSure... even if I assume you were entirely trying to play the devil's advocate role, your willingness to continue to argue illogically for what is demonstrably a bad idea, seriously devalues that role to nothing more than political nuisance.I've been following this thread closely and, in Patrick's defense, I don't think he's been arguing illogically at all. You suggest that that your 20 years of experience make your opinions irrefutable, but I have coming up on 30 years of experience, and whereas much of my data layer architecture has included a stored procedure based interface just as you advocate for, I have also seen plenty of deployments where CRUD operations are handled just fine by an ORM framework, with business logic being encoded elsewhere. I feel like this is pretty close to what Patrick has been saying and there's nothing illogical about it - these systems are out there, working to spec as I type.
In fact, in microservice architectures, encompassing large amounts of business logic in a monolithic database would be considered an anti-pattern, but restricting an ORM-based DAL to simple CRUD operations works well.
With that said, would I promote tearing down a functioning SP-based interface in a brown field project, as Luis suggests his company is considering? No I would not. And I believe Patrick has said much the same over his posts.
My mention of experience was not intended to be anything other than a statement of fact, and in that respect, I have another 15 years to add to that, having had a front-row seat to watching as database project after database project went wrong because the depth of incompetence was so deep that there wasn't really any attempt to do it even remotely right. Management was cycled in and out, PMs came and went, and very little changed until the upper management level got canned after a multi-million dollar project went so badly that even recovery from it was going to be problematic. Up to that point, there always seemed to be time to do it wrong at least 3 times, if not 4 or 5. ORM and other variations were certainly common elements in most of the problems, and because stored procedures were not being used, even for CRUD, any changes to the applications, which were quite frequent due to the failure to do much in the way of useful database design or user interaction to gather requirements, often took anywhere from a month and a half to as long as 6 months. Then by the time the users noticed there was a problem, it was going to be another couple of months to fix the application in concert with the now necessary database changes. Most of that could have been avoided if stored procedures had been in place, as a few simple changes there could have minimized the impact and the app could have been updated and fixed in a couple of days instead of a month or more. So if you expect me to buy into sprocs ever being unnecessary, forget it. They are just too valuable to ignore, and they can achieve cost avoidance in ways you might not even imagine, when properly designed and implemented.
And since you mentioned that you had 30 years of experience, do you want me to believe that this suddenly makes facts refutable? Or were you just trying to take out your measuring stick? Take the ego elsewhere.
All that experience provides is a single point of view. I have worked for 40 years in the IT field. My experience does not validate or invalidate the experience of others, it just provides another point of view. What you have experienced may not be what I have experienced. In the database side of my career (over 20 years) I have had the pleasure (or displeasure depending on your POV) of working in relatively small and stable environments and not dealing with some of the issues others have experienced. That is one of the reasons I try to stay active here, to see and hopefully learn from other experiences. No ego, just a desire to gain from other peoples POV.
Lynn, I hear ya... BUT ... when I see arguments that don't hold water and/or don't stand up to scrutiny, I call BS on them. That's just part and parcel of what has made me successful, and my overall IT experience is just over 40 years, so we're not all that far apart. I may not have the spit and polish or the just be nice genes, but I'm not about to sacrifice success just to accommodate some other point of view. If folks choose to get bent out of shape over that, well, I guess that's their problem. What bothers me most is the intellectual dishonesty some folks are willing to engage in, and I have pretty much zero tolerance for that kind of foolishness. I've also found that it's not usually some other point of view that I learn from... it's almost exclusively new information. Especially where technical stuff is involved; e.g. science, math, T-SQL, etc...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
May 9, 2018 at 11:29 am
Using SP's vs ad-hoc queries is not an argument here, really.
Placing a single CRUD query into a sp does not provide any significant advantages in terms of performance, stability, etc.
But avoiding sp's is usually an indicator of lack of knowledge about "DB stuff".
Effective code starts with "CREATE TABLE".
Designing adequate data structure is crucial, and this is a part which is not in the scope for a typical front end developer.
Too often they just create a bunch of tables reflecting object structure with a single key on an identity column. From that point - it does not really matter if you use stored procedures or ad hoc queries, the damage is irreversible.
Actually, using CRUD queries against object-like tables in SQL Server does not make any sence from business point of view.
With such a data repository it's more effective to use a set of flat files. SQL Server only creates a huge overhead with no apparent advantages. Why pay quite significant fees for functionality you don't understand and don't intent to use - that's the question.
_____________
Code for TallyGenerator
Viewing 15 posts - 151 through 165 (of 191 total)
You must be logged in to reply to this topic. Login to reply