May 8, 2018 at 10:04 am
Steve Jones - SSC Editor - Tuesday, May 8, 2018 8:45 AMSue_H - Tuesday, May 8, 2018 8:23 AM...And I'm not asking those to put you on the spot. Just another side of things. In those environments such as CI, there is often the assumption that everything is automated when it really isn't. And when a person gets involved, it's seen as being something negative. And whoever that person is becomes the "negative" or the bottleneck in the equation when they really are not.
Sue
Automation in DevOps (or other ways of describing software development) is only automated tedious, repeatable processes that humans have built. The automation is just repeating what someone would have to normally do manually. This means that automation would be:
- the process of ensuring you have the latest code
- running all the tests (or specific sets of tests)
- packaging up code
- or executing it under the right credentials to the right server
- or any other taskMost of you are programmers of some sort. You write scripts or utilities or macros or anything to reduce work and handle the tedious tasks. That's what automation in DevOps or Agile is used for. You do the creative work to build something, automation is used to repeat that over and over.
Yup...a lot of it is automated. Not all of it but most of it is for the development groups.
I also think there are other groups involved in the process of deployments directly and indirectly (and often other systems in the infrastructure) and these end up being overlooked too often. And that is part of what leads towards "resource constraints" issues.
Sue
May 8, 2018 at 10:04 am
patrickmcginnis59 10839 - Tuesday, May 8, 2018 9:26 AMSean Lange - Tuesday, May 8, 2018 8:39 AMIf you interpreted my post as implying that dotnet can't do modular programming I either need to completely rewrite what I wrote or you need to reread it. I was speaking of application layers (and the lack of utilizing them), not modularity. Sprinkling (or perhaps littering is a better term) sql statements all through code is what I was speaking of. And it is abominable.
In dotnet there are assemblies, classes, methods and many other module development opportunities. Those are all part of the application layer. In some poorly designed systems the data layer is scattered through those pieces of code which is what I was talking about.
I hear ya, it sounds like dot net has plenty of ways for me to "separate out concerns into discrete tidy buckets" so maybe there isn't really a contradiction of mine that I need to remediate. Are there any other potential contradictions I need to address? If you want to retype your post would you like me to remove the quotations? Especially with you saying I'm contradicting myself when I can't really spot any evidence of it?
I also get that feeling that folks are saying once developers leave stored procedures and do work in dot net, then its "all heck breaks loose" but the thing is, if you can't address the programming process with any sort of legit structure of management ensuring due diligence and care and genuinely effective programming practices, then isn't the question more like "which side of the database connection does the crap code get written to?"
If it helps any, I prefer stored procedures in many cases but as always it probably depends on the project. So if you'd like to consider that in your rewrite I'd appreciate it.
edit: I really regret feeling like I should post with the picky tone I posted with, but all too often I find that we aren't helping each other accurately hone into the differences that separate our opinions, and I guess I do get a bit frustrated, and I otherwise enjoy posting here. I know my posting style is a work in progress, if anybody would like me to remove my posts sent me a message and I'll certainly consider it, obviously those asking that I go **** ****** will have to present a much more persuasive argument in that particular case 😉
I haven't had any issue with the tone in any of our discussions. 🙂
I truly do feel that when you leave stored procedures and start embedding sql in your application that "all heck breaks loose". I have worked on many systems built both ways so my opinion is not one based on theoretical concepts. It is based on working where the rubber meets the road for quite some time. I am by no means alone here. This discussion has been gone all over the internet for years. Here is the MS documentation for best practices in designing an application. https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 8, 2018 at 10:16 am
Sean Lange - Tuesday, May 8, 2018 10:04 AMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 9:26 AMSean Lange - Tuesday, May 8, 2018 8:39 AMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 7:44 AMSean Lange - Tuesday, May 8, 2018 7:33 AMpatrickmcginnis59 10839 - Monday, May 7, 2018 3:25 PMThey have queries that generate thousand and thousand of rows for grids that are paged. They aren't doing any server side paging or caching, just querying the same multiple thousand row query for every page of data.
yes, but are we saying fixing this requires a stored procedure?
edit:
let me put it another way, can we DO paging and caching without stored procedures? how about procedure cache bloat, can we avoid that without stored procedures?
I'm the type that likes to separate out concerns into discrete tidy buckets for consideration.
(another edit, I had a typo in there)
Sure you can do this without procedures. It sounds like you are on the side that doesn't want to use stored procedures. But that contradicts your statement that you like to "separate out concerns into discrete tidy buckets". One of the advantages of using stored procedures is the separation of duties and creating layers. When the application layer also implements all of the data concerns you have created a potential nightmare. For one thing you have to redeploy the entire application for a minor change in a query. And heaven forbid you need to change databases when all your queries are scattered all over the application. Now I realize that changing databases doesn't happen all that often but it does happen. I have migrated applications to sql server in the past. Some of them had code splattered throughout the code and it was a nightmare. But one client I did some work for had everything separated in layers. It was so much simpler.
That sort of implies that dot net or other programming doesn't do modular programming and, well, this is surprising to me. Are there really no high level programming languages besides T-SQL that HAVE facilities to provide any sort of modularity for developers to use? (Sorry, typo)
If you interpreted my post as implying that dotnet can't do modular programming I either need to completely rewrite what I wrote or you need to reread it. I was speaking of application layers (and the lack of utilizing them), not modularity. Sprinkling (or perhaps littering is a better term) sql statements all through code is what I was speaking of. And it is abominable.
In dotnet there are assemblies, classes, methods and many other module development opportunities. Those are all part of the application layer. In some poorly designed systems the data layer is scattered through those pieces of code which is what I was talking about.
I hear ya, it sounds like dot net has plenty of ways for me to "separate out concerns into discrete tidy buckets" so maybe there isn't really a contradiction of mine that I need to remediate. Are there any other potential contradictions I need to address? If you want to retype your post would you like me to remove the quotations? Especially with you saying I'm contradicting myself when I can't really spot any evidence of it?
I also get that feeling that folks are saying once developers leave stored procedures and do work in dot net, then its "all heck breaks loose" but the thing is, if you can't address the programming process with any sort of legit structure of management ensuring due diligence and care and genuinely effective programming practices, then isn't the question more like "which side of the database connection does the crap code get written to?"
If it helps any, I prefer stored procedures in many cases but as always it probably depends on the project. So if you'd like to consider that in your rewrite I'd appreciate it.
edit: I really regret feeling like I should post with the picky tone I posted with, but all too often I find that we aren't helping each other accurately hone into the differences that separate our opinions, and I guess I do get a bit frustrated, and I otherwise enjoy posting here. I know my posting style is a work in progress, if anybody would like me to remove my posts sent me a message and I'll certainly consider it, obviously those asking that I go **** ****** will have to present a much more persuasive argument in that particular case 😉
I haven't had any issue with the tone in any of our discussions. 🙂
I truly do feel that when you leave stored procedures and start embedding sql in your application that "all heck breaks loose". I have worked on many systems built both ways so my opinion is not one based on theoretical concepts. It is based on working where the rubber meets the road for quite some time. I am by no means alone here. This discussion has been gone all over the internet for years. Here is the MS documentation for best practices in designing an application. https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
Well that's the thing though, if we can determine if, when, and why "all heck breaks loose" then the folks recommending stored procedures have something to go with, and that was literally the request that started the thread. I know when I prepare to present a case to people that I want to convince of something, I try to prepare for any counter arguments I might encounter and I'm a huge proponent of this sort of process, its sort of like how I want meeting agenda's emailed ahead of time, etc.
Incidently did you read in your link the text regarding the advantages of not using stored procedures?
May 8, 2018 at 10:23 am
Sergiy - 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.
May 8, 2018 at 10:31 am
patrickmcginnis59 10839 - Tuesday, May 8, 2018 10:16 AMSean Lange - Tuesday, May 8, 2018 10:04 AMI haven't had any issue with the tone in any of our discussions. 🙂I truly do feel that when you leave stored procedures and start embedding sql in your application that "all heck breaks loose". I have worked on many systems built both ways so my opinion is not one based on theoretical concepts. It is based on working where the rubber meets the road for quite some time. I am by no means alone here. This discussion has been gone all over the internet for years. Here is the MS documentation for best practices in designing an application. https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
Well that's the thing though, if we can determine if, when, and why "all heck breaks loose" then the folks recommending stored procedures have something to go with, and that was literally the request that started the thread. I know when I prepare to present a case to people that I want to convince of something, I try to prepare for any counter arguments I might encounter and I'm a huge proponent of this sort of process, its sort of like how I want meeting agenda's emailed ahead of time, etc.
Incidently did you read in your link the text regarding the advantages of not using stored procedures?
This really feels like we are just going around in circles. What is it you want? Every example presented by myself and others you just sort of wiggle around it. Maybe you are trying to play devil's advocate I don't know.
Not sure what you mean by text regarding the advantages of not using stored procedures. Is there something in the MS recommendation about that? I can't find it in there.
As for determining when and why the proverbial poop hits the fan when your application is littered with sql I don't know how many more examples can be provided. Do you want a list? You have no dependency on the objects. What happens when you change a table and the code that references it it outside the database? Your application is now broken. This could have been prevented with procedures and schema binding. What happens when an entire table is dropped? The same issue. If you are the database person and the applications all have code scattered all over the place how can you document what tables are being used? How about if there are 50 or 100 apps like this? It is a management and maintenance nightmare.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 8, 2018 at 10:32 am
patrickmcginnis59 10839 - Tuesday, May 8, 2018 9:26 AMedit: I really regret feeling like I should post with the picky tone I posted with, but all too often I find that we aren't helping each other accurately hone into the differences that separate our opinions, and I guess I do get a bit frustrated,
I don't think your tone was bad but wanted to say I totally agree with these sentiments. There are differences, everyone has different experiences, every <whatever thought, approach, process, procedure> is often implemented differently in different places, by different people, with different results, etc. It's almost like we all want the comfort of a "one size fits all" that is the perfect solution across the board. Personally I don't think such a thing exists. Looking at the bad and the good, the merits and the downfalls, both sides of anything is valuable to me. You personally do present those at times and I appreciate it even if I don't agree with it.
Sue
May 8, 2018 at 12:08 pm
Sean Lange - Tuesday, May 8, 2018 10:31 AMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 10:16 AMSean Lange - Tuesday, May 8, 2018 10:04 AMI haven't had any issue with the tone in any of our discussions. 🙂I truly do feel that when you leave stored procedures and start embedding sql in your application that "all heck breaks loose". I have worked on many systems built both ways so my opinion is not one based on theoretical concepts. It is based on working where the rubber meets the road for quite some time. I am by no means alone here. This discussion has been gone all over the internet for years. Here is the MS documentation for best practices in designing an application. https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
Well that's the thing though, if we can determine if, when, and why "all heck breaks loose" then the folks recommending stored procedures have something to go with, and that was literally the request that started the thread. I know when I prepare to present a case to people that I want to convince of something, I try to prepare for any counter arguments I might encounter and I'm a huge proponent of this sort of process, its sort of like how I want meeting agenda's emailed ahead of time, etc.
Incidently did you read in your link the text regarding the advantages of not using stored procedures?
This really feels like we are just going around in circles. What is it you want? Every example presented by myself and others you just sort of wiggle around it. Maybe you are trying to play devil's advocate I don't know.
Not sure what you mean by text regarding the advantages of not using stored procedures. Is there something in the MS recommendation about that? I can't find it in there.
As for determining when and why the proverbial poop hits the fan when your application is littered with sql I don't know how many more examples can be provided. Do you want a list? You have no dependency on the objects. What happens when you change a table and the code that references it it outside the database? Your application is now broken. This could have been prevented with procedures and schema binding. What happens when an entire table is dropped? The same issue. If you are the database person and the applications all have code scattered all over the place how can you document what tables are being used? How about if there are 50 or 100 apps like this? It is a management and maintenance nightmare.
Chapter 8, the data layer. The document you linked is a really good document, but it counters the assertion that code goes nuts once it leaves SQL and that's a good thing because that's exactly what needs to happen, is that the entire body of code needs to be squared away. I'm not saying that code will not go nuts if you let it because it will.
You can "guess" that I'm playing devils advocate when I literally said in the quoted text that I'm preparing for any counter arguments and I'm like smacking my head at how poorly we're communicating.
Developers CAN make a mess of SQL. Stored procedures can be a mess. I'm not talking about incompetent people, competence in job performance is a separate subject. If you want to make the point that dot net people are incompetent but SQL people aren't then that's fine, but I'm not interested in having that conversation. I'm also not interested in developers who do not know or cannot access and utilize knowledge about SQL server. They should not be employed to do database apps with SQL Server without knowing how SQL Server behaves with the code they send it. Its programming 101 to know how computers work, including the software. I'm not interested in discussing competencies, I am assuming competence, if you don't want to assume that, go argue with someone else.
Schema binding is good. I can agree with that, its a clear advantage with SQL Server when creating views, but this doesn't prevent SQL in the app, and really those are only for natively compiled stored procedures in the first place at least up to 2014 from what I've read, and its probably just too narrow an argument to take to a meeting in my opinion. You're welcome to it however, so I will award you that point just to conclude that portion of the discussion.
Managing complexity is a job. Yes, if you can't do it, then you have a nightmare. Whether or not SQL or stored procedures prevents crap applications, well I don't believe it does. Only quality code and development methodologies can prevent crap applications and you can't convince me otherwise.
Objects that depend on objects are a valid concern. Programming 101 and I agree with that, its worth its own thread but probably would be better at a programming forum than here at SSC. I am reading fascinating stuff about OOP and some of these texts I run across have the sort of deep analysis that are well worth being aware of.
These are me addressing points that I can detect in folks posts. If you want to call that "wiggling around" then you are the expert, I'm completely unprepared in defining, debating or evaluating the "wiggling" paradigm nor am I able to identify the wiggles you have apparently have and will be unable to assist you in the task of "unwiggling" or the prevention of any future "wiggles" in any post appearing here or elsewhere. Whether I'm going around in circles will depend on you showing me the cyclic loop in my text.
May 8, 2018 at 12:28 pm
patrickmcginnis59 10839 - Tuesday, May 8, 2018 12:08 PMChapter 8, the data layer. The document you linked is a really good document, but it counters the assertion that code goes nuts once it leaves SQL and that's a good thing because that's exactly what needs to happen, is that the entire body of code needs to be squared away. I'm not saying that code will not go nuts if you let it because it will.You can "guess" that I'm playing devils advocate when I literally said in the quoted text that I'm preparing for any counter arguments and I'm like smacking my head at how poorly we're communicating.
Developers CAN make a mess of SQL. Stored procedures can be a mess. I'm not talking about incompetent people, competence in job performance is a separate subject. If you want to make the point that dot net people are incompetent but SQL people aren't then that's fine, but I'm not interested in having that conversation. I'm also not interested in developers who do not know or cannot access and utilize knowledge about SQL server. They should not be employed to do database apps with SQL Server without knowing how SQL Server behaves with the code they send it. Its programming 101 to know how computers work, including the software. I'm not interested in discussing competencies, I am assuming competence, if you don't want to assume that, go argue with someone else.
Schema binding is good. I can agree with that, its a clear advantage with SQL Server when creating views, but this doesn't prevent SQL in the app, and really those are only for natively compiled stored procedures in the first place at least up to 2014 from what I've read, and its probably just too narrow an argument to take to a meeting in my opinion. You're welcome to it however, so I will award you that point just to conclude that portion of the discussion.
Managing complexity is a job. Yes, if you can't do it, then you have a nightmare. Whether or not SQL or stored procedures prevents crap applications, well I don't believe it does. Only quality code and development methodologies can prevent crap applications and you can't convince me otherwise.
Objects that depend on objects are a valid concern. Programming 101 and I agree with that, its worth its own thread but probably would be better at a programming forum than here at SSC. I am reading fascinating stuff about OOP and some of these texts I run across have the sort of deep analysis that are well worth being aware of.
These are me addressing points that I can detect in folks posts. If you want to call that "wiggling around" then you are the expert, I'm completely unprepared in defining, debating or evaluating the "wiggling" paradigm nor am I able to identify the wiggles you have apparently have and will be unable to assist you in the task of "unwiggling" or the prevention of any future "wiggles" in any post appearing here or elsewhere. Whether I'm going around in circles will depend on you showing me the cyclic loop in my text.
Here is the part of that article about stored procedures.
The main advantages of stored procedures are that they provide an abstraction layer to the database, which can minimize the impact on application code when the database schema changes. Security is also easier to implement and manage because you can restrict access to everything except the stored procedure, and take advantage of fine-grained security features supported by most databases (though be aware that this may affect your ability to take advantage of connection pooling).
The main advantages of dynamic SQL statements are that they are often considered more flexible than stored procedures, and can enable more rapid development. Many Object/Relational Mapping (O/RM) frameworks generate dynamic queries for you, considerably reducing the amount of code developers must write.
It is no secret that queries from ORMs are horrific. This harkens to Jeff Moden's quote. "If you want it real bad that is exactly how you will get it, real bad". ORMs can make development rapid but it comes at a cost. I don't have any thoughts that using procedures keeps the code from being crappy or going nuts. I have seen plenty of cases that prove that incorrect. 😉
These are me addressing points that I can detect in folks posts. If you want to call that "wiggling around" then you are the expert, I'm completely unprepared in defining, debating or evaluating the "wiggling" paradigm nor am I able to identify the wiggles you have apparently have and will be unable to assist you in the task of "unwiggling" or the prevention of any future "wiggles" in any post appearing here or elsewhere. Whether I'm going around in circles will depend on you showing me the cyclic loop in my text.
ROFL!!!! That was awesome!!! Well stated indeed.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 8, 2018 at 12:48 pm
It 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.
May 8, 2018 at 12:58 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.
Agreed on all counts. In fact the queries are so bad that most ORMs allow for using stored procedures to overcome the performance problems of automatically generated queries. I can safely say that there is no chance I could write code that would be able to write queries like the ORMs. Not because of competence but because the complexity is staggering. I mean I have to tip my hat that they are able to get the correct data at least when the person writing the code is competent.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 8, 2018 at 12:58 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.
Also I'm not calling any programmers incompetent. I'm talking about competence using an ORM. I'm betting that even evaluating whether you yourself have the competency to use an ORM is in itself a pile of work, well except its easy for me, I wouldn't take on a project with ORM and that decision took seconds LOL
May 8, 2018 at 1:27 pm
patrickmcginnis59 10839 - Tuesday, May 8, 2018 12:58 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.
Also I'm not calling any programmers incompetent. I'm talking about competence using an ORM. I'm betting that even evaluating whether you yourself have the competency to use an ORM is in itself a pile of work, well except its easy for me, I wouldn't take on a project with ORM and that decision took seconds LOL
Nope we ruled out incompetence for the technical people long ago. Of course there are many out there in the real world but in our hypothetical utopia they are all competent. FWIW, I am right there with you on the ORM project. I am inept and highly skeptical which is bad combination.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 8, 2018 at 1:35 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.
the team's Definition of Done (which applies to all stories in the project) and the Acceptance Criteria which is tailored for each story - isn't it what we name "Comprehensive documentation"?
Especially when it's "specifying the appropriate amount of test unit coverage, passing regression and integration tests, code reviews and user acceptance testing"
_____________
Code for TallyGenerator
May 8, 2018 at 2:23 pm
Sergiy - Tuesday, May 8, 2018 1:35 PMSteve 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.the team's Definition of Done (which applies to all stories in the project) and the Acceptance Criteria which is tailored for each story - isn't it what we name "Comprehensive documentation"?
Especially when it's "specifying the appropriate amount of test unit coverage, passing regression and integration tests, code reviews and user acceptance testing"
No, 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.
May 8, 2018 at 2:37 pm
Sue_H - Tuesday, May 8, 2018 10:32 AMpatrickmcginnis59 10839 - Tuesday, May 8, 2018 9:26 AMedit: I really regret feeling like I should post with the picky tone I posted with, but all too often I find that we aren't helping each other accurately hone into the differences that separate our opinions, and I guess I do get a bit frustrated,I don't think your tone was bad but wanted to say I totally agree with these sentiments. There are differences, everyone has different experiences, every <whatever thought, approach, process, procedure> is often implemented differently in different places, by different people, with different results, etc. It's almost like we all want the comfort of a "one size fits all" that is the perfect solution across the board. Personally I don't think such a thing exists. Looking at the bad and the good, the merits and the downfalls, both sides of anything is valuable to me. You personally do present those at times and I appreciate it even if I don't agree with it.
Sue
Nice to know I'm not just cluttering up the thread!
I think we all fear getting hammered by decisions out of our control and I can appreciate the angst folks feel about development projects gone wrong, and that combined with the velocity of change in IT nowadays and the lack of velocity of some of the people we may encounter well I can appreciate people have strong feelings, I know I do! Theres been plenty of times that no ORM was needed to get me feeling some, maybe "confusion" to put it mildly 🙂
I hope that Luis the OP will keep this in mind that given even his peers have differing viewpoints, it would be all the more certain that communicating effectively (including listening) to all concerns with his own projects will be all the more important to his success. I know its often tough to get things right even with familiar tools and processes, and change just throws all the more risk our way.
Viewing 15 posts - 136 through 150 (of 191 total)
You must be logged in to reply to this topic. Login to reply