April 12, 2018 at 6:20 am
xsevensinzx - Tuesday, April 10, 2018 7:21 AMThat works too. Not to distort the issue as being tied specifically to stored procs. That's actually semantics. But, it's often communicated as stored procs being the issue because everyone knows that means someone else has to write it before they can push forward. If you can get your actual developers writing it instead, then that's exactly the same methodology that I am saying with ORM. Instead of someone else writing that stored proc, you teach your team to write it for themselves.I'm not going to touch that silly H1B post. I will just simply say, I disagree on that mindset, especially factoring in someone's work status or even nationality as a major factor to solving a problem.
Really? Not touch it? You clearly state that you "disagree with that mindset", and thus clearly "touched it", but I'm certain you have no idea what's behind my perspective and I'm also pretty sure you're making an unwarranted assumption about what my mindset is. I couldn't care less where someone is from when it comes to assessing their ability to perform work. My experience, over the last 20 years, clearly indicates that "on average", an H1B visa candidate is almost always less technically skilled and often lacking in work ethic, and far too frequently believing themselves superior to most others. So when that "average" changes, I'll consider making a change to my perspective. As I'm not in management and don't get to make choices on whom to hire, I have no control or input to those processes, and get stuck working with what I'll refer to as low-quality workers, where I'm usually better off coding any SQL for them than trying to educate. It's not that they can't learn... it's that their attitude prevents that from happening. So step down from your ivory tower and have a little respect for a point of view based on facts instead of politically correct behavior. As to the quantity of "less-skilled" H1B types, it certainly appears to be the vast majority. I've met just two whose work skills were highly competent, out of hundreds...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
April 12, 2018 at 6:57 am
sgmunson - Thursday, April 12, 2018 6:20 AMH1B visa candidate is almost always less technically skilled and often lacking in work ethic,and far too frequently believing themselves superior to most others.
So step down from your ivory tower
You sure it's us on that ivory tower?
And it has nothing to do with being politically correct. It has everything to do with not judging a book by it's cover on top of not being prejudice towards someone based on what nationality, race, sex, religious views or whatever. If that's what you do, then you're lucky I don't work with you or manage you because you're ass would be out the door quicker than you could say H1B.
April 12, 2018 at 7:27 am
off topic post removed
April 12, 2018 at 8:26 am
xsevensinzx - Thursday, April 12, 2018 6:57 AMsgmunson - Thursday, April 12, 2018 6:20 AMH1B visa candidate is almost always less technically skilled and often lacking in work ethic,and far too frequently believing themselves superior to most others.
So step down from your ivory tower
You sure it's us on that ivory tower?
And it has nothing to do with being politically correct. It has everything to do with not judging a book by it's cover on top of not being prejudice towards someone based on what nationality, race, sex, religious views or whatever. If that's what you do, then you're lucky I don't work with you or manage you because you're ass would be out the door quicker than you could say H1B.
No surprise here that you ignore what I had to say about my perspective. You ignored it in favor of the politically correct view. That's called bias. I don't have a bias against where someone comes from or any of those things you listed. I do have one against bad work habits and superior attitudes in individuals. But apparently, those facts are ignored when a group is mentioned because that's the PC thing to do these days. I call BS on that perspective, which entirely ignores reality. .Take your BS somewhere else and peddle it. I have no time for it.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
April 12, 2018 at 8:46 am
sgmunson - Thursday, April 12, 2018 8:26 AMxsevensinzx - Thursday, April 12, 2018 6:57 AMsgmunson - Thursday, April 12, 2018 6:20 AMH1B visa candidate is almost always less technically skilled and often lacking in work ethic,and far too frequently believing themselves superior to most others.
So step down from your ivory tower
You sure it's us on that ivory tower?
And it has nothing to do with being politically correct. It has everything to do with not judging a book by it's cover on top of not being prejudice towards someone based on what nationality, race, sex, religious views or whatever. If that's what you do, then you're lucky I don't work with you or manage you because you're ass would be out the door quicker than you could say H1B.
No surprise here that you ignore what I had to say about my perspective. You ignored it in favor of the politically correct view. That's called bias. I don't have a bias against where someone comes from or any of those things you listed. I do have one against bad work habits and superior attitudes in individuals. But apparently, those facts are ignored when a group is mentioned because that's the PC thing to do these days. I call BS on that perspective, which entirely ignores reality. .Take your BS somewhere else and peddle it. I have no time for it.
Can we leave this discussion aside?
I don't feel comfortable with it because I've seen people not caring about doing a good job or being simply unfit for the position they're in. But at the same time, I'm working in the US with a work permit that is much easier to get than an H1B and know that I was chosen over a local for my performance (we were both hired at the same time but they preferred my work and knowledge).
Getting back to the original subject, I'll be trying to get me or another DBA in the discussion for this migration. Hopefully, we'll be heard.
April 13, 2018 at 1:05 am
There is a fact which is denied by absolute majority of IT community:
So called "full stack developers" cannot do T-SQL code.
Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.
Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.
They cannot get away with that so easily in DB environment.
Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.
Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.
Everyone is happy, except those retarded SQL developers.
_____________
Code for TallyGenerator
April 13, 2018 at 6:56 am
Sergiy - Friday, April 13, 2018 1:05 AMThere is a fact which is denied by absolute majority of IT community:So called "full stack developers" cannot do T-SQL code.Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.They cannot get away with that so easily in DB environment.Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.Everyone is happy, except those retarded SQL developers.
Thanks for that. Useful to know that my posts aren't helpful to anyone.
April 13, 2018 at 8:52 am
Chris Wooding - Friday, April 13, 2018 6:56 AMSergiy - Friday, April 13, 2018 1:05 AMThere is a fact which is denied by absolute majority of IT community:So called "full stack developers" cannot do T-SQL code.Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.They cannot get away with that so easily in DB environment.Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.Everyone is happy, except those retarded SQL developers.Thanks for that. Useful to know that my posts aren't helpful to anyone.
Ok since this entire thread has gone to heck, I'd just like to say:
triangular joins are set based queries, you can write procedural code that doesn't need punched cards or tape drives, and stack exchange has better forum software than SSC.
April 13, 2018 at 9:16 am
Luis Cazares - Thursday, April 12, 2018 8:46 AMsgmunson - Thursday, April 12, 2018 8:26 AMxsevensinzx - Thursday, April 12, 2018 6:57 AMsgmunson - Thursday, April 12, 2018 6:20 AMH1B visa candidate is almost always less technically skilled and often lacking in work ethic,and far too frequently believing themselves superior to most others.
So step down from your ivory tower
You sure it's us on that ivory tower?
And it has nothing to do with being politically correct. It has everything to do with not judging a book by it's cover on top of not being prejudice towards someone based on what nationality, race, sex, religious views or whatever. If that's what you do, then you're lucky I don't work with you or manage you because you're ass would be out the door quicker than you could say H1B.
No surprise here that you ignore what I had to say about my perspective. You ignored it in favor of the politically correct view. That's called bias. I don't have a bias against where someone comes from or any of those things you listed. I do have one against bad work habits and superior attitudes in individuals. But apparently, those facts are ignored when a group is mentioned because that's the PC thing to do these days. I call BS on that perspective, which entirely ignores reality. .Take your BS somewhere else and peddle it. I have no time for it.
Can we leave this discussion aside?
I don't feel comfortable with it because I've seen people not caring about doing a good job or being simply unfit for the position they're in. But at the same time, I'm working in the US with a work permit that is much easier to get than an H1B and know that I was chosen over a local for my performance (we were both hired at the same time but they preferred my work and knowledge).Getting back to the original subject, I'll be trying to get me or another DBA in the discussion for this migration. Hopefully, we'll be heard.
"Can we leave this discussion aside?" Gladly... Unfortunately, there are always some that just can't leave well enough alone, and will call you out for telling the truth. I have a really low tolerance for that kind of thing. From what I've read of Sergiy's post, he appears to be very much on the same page that I am, and I have to applaud his courage in continuing to tell the truth in the face of the proverbial gauntlet being thrown down with the intent to suppress it.
Returning to the discussion at hand, I do hope you get to participate, Luis... I've seen a LOT of your code, and it's good stuff, so I'm quite certain your company would ultimately benefit from your participation (along with the DBAs). Good luck to you, sir!
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
April 13, 2018 at 10:05 am
Luis Cazares - Tuesday, April 3, 2018 12:59 PMI got an interesting email today about cutting back on the reliance of the applications on databases and plans to remove all stored procedures from the code.
In my opinion, this is nonsense but I don't feel that it's a good idea to say it like that to my manager. Could you help me establish some valid reasons set my point? I'm thinking on better handle of security, the possibility of less call between app servers and db servers, possible performance improvement from cached plans.
Or maybe I'm wrong and you could give me some reasons to change my mind.
For what it's worth, I spend few years undoing similar effort where the client had gone entirely to EF/ORM. They called me in when a 32 Core 2Tb RAM struggled to process 3-4 business transactions per second.
😎
When I finished, they were in the 32K range with lot to spare.
April 13, 2018 at 10:10 am
Sergiy - Friday, April 13, 2018 1:05 AMThere is a fact which is denied by absolute majority of IT community:So called "full stack developers" cannot do T-SQL code.Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.They cannot get away with that so easily in DB environment.Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.Everyone is happy, except those retarded SQL developers.
I am going to call BS on this. I am one of those "full stack developers" and I would pit my t-sql ability against nearly anyone on this forum. I am not currently, nor have ever been, in a dedicated SQL role DBA or otherwise. Blanket statements based on job title is just uninformed arrogance. Sure there is a stereotype that full stack devs can't write t-sql join with instructions but blanket statements like yours really rub me the wrong way.
_______________________________________________________________
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/
April 13, 2018 at 10:15 am
Eirikur Eiriksson - Friday, April 13, 2018 10:05 AMLuis Cazares - Tuesday, April 3, 2018 12:59 PMI got an interesting email today about cutting back on the reliance of the applications on databases and plans to remove all stored procedures from the code.
In my opinion, this is nonsense but I don't feel that it's a good idea to say it like that to my manager. Could you help me establish some valid reasons set my point? I'm thinking on better handle of security, the possibility of less call between app servers and db servers, possible performance improvement from cached plans.
Or maybe I'm wrong and you could give me some reasons to change my mind.For what it's worth, I spend few years undoing similar effort where the client had gone entirely to EF/ORM. They called me in when a 32 Core 2Tb RAM struggled to process 3-4 business transactions per second.
😎
When I finished, they were in the 32K range with lot to spare.
Sadly the dev team where my wife works is moving this way. They currently have all their data access as stored procedures. They are actively moving all the sql into the application. This is because they have become convinced that the stored procs are the cause of their performance issues. I have seen some of their work and I have to agree that the procs are definitely the cause of the performance problems. But it has nothing to do with the fact that it is a stored proc. It is the while loops, cursors, select *, nonSARGable predicates etc. The usual low hanging fruit for major performance improvements. I know some of the devs and have suggested some improvements and they said it will be better when they get all the sql code back in the application. You can lead people to the data, but you can't make them think.
_______________________________________________________________
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/
April 13, 2018 at 12:14 pm
Sean Lange - Friday, April 13, 2018 10:10 AMSergiy - Friday, April 13, 2018 1:05 AMThere is a fact which is denied by absolute majority of IT community:So called "full stack developers" cannot do T-SQL code.Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.They cannot get away with that so easily in DB environment.Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.Everyone is happy, except those retarded SQL developers.I am going to call BS on this. I am one of those "full stack developers" and I would pit my t-sql ability against nearly anyone on this forum. I am not currently, nor have ever been, in a dedicated SQL role DBA or otherwise. Blanket statements based on job title is just uninformed arrogance. Sure there is a stereotype that full stack devs can't write t-sql join with instructions but blanket statements like yours really rub me the wrong way.
Hate to say this dude, but while YOU have the skills, the vast majority do NOT. Sergiy failed to be sufficiently specific and threw everyone under the bus instead of saying something closer to "on average, most....". That said, I also wonder how many other full stack devs you've worked with, and how often you're called upon to correct a problem one of them created? It's been a career for me, spanning the better part of the last decade. Many of these folks that label themselves full stack devs are anything but. Most wouldn't know a database from a hole in the ground, and that's particularly likely if they're on an H1B visa. The pertinent point here, is that I used the word "most". It does NOT mean ALL. The other thing that continues to amaze me is just how butt-hurt people get when a group is maligned in any way, but without any regard to facts that might be a reason for such maligning. Seems to me that thinking has been dropped out of the education system, and far too few people are willing to do it any more.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
April 13, 2018 at 12:54 pm
sgmunson - Friday, April 13, 2018 12:14 PMSean Lange - Friday, April 13, 2018 10:10 AMSergiy - Friday, April 13, 2018 1:05 AMThere is a fact which is denied by absolute majority of IT community:So called "full stack developers" cannot do T-SQL code.Well, they know the syntax, and they always can ask a question on SSC or SO. But what comes out will be s..t anyway.Actually, their code in any language is typically s..t, but the database environment is much less forgiving than a front end. Massive data amounts, concurrent executions - it's something they never face anywhere else. And in the end of the day users always place a blame on browsers for excessive memory consumption and slow page loading.They cannot get away with that so easily in DB environment.Therefore the whole thing of T-SQL development is declared a problem, which should be avoided in "cloud" or any other "progressive" data management approach.Cutting costs leads to hiring mediocrity, mediocrity hates challenging DEV platforms, so here we are - flat files placed in columnstore: problem solved.Everyone is happy, except those retarded SQL developers.I am going to call BS on this. I am one of those "full stack developers" and I would pit my t-sql ability against nearly anyone on this forum. I am not currently, nor have ever been, in a dedicated SQL role DBA or otherwise. Blanket statements based on job title is just uninformed arrogance. Sure there is a stereotype that full stack devs can't write t-sql join with instructions but blanket statements like yours really rub me the wrong way.
Hate to say this dude, but while YOU have the skills, the vast majority do NOT. Sergiy failed to be sufficiently specific and threw everyone under the bus instead of saying something closer to "on average, most....". That said, I also wonder how many other full stack devs you've worked with, and how often you're called upon to correct a problem one of them created? It's been a career for me, spanning the better part of the last decade. Many of these folks that label themselves full stack devs are anything but. Most wouldn't know a database from a hole in the ground, and that's particularly likely if they're on an H1B visa. The pertinent point here, is that I used the word "most". It does NOT mean ALL. The other thing that continues to amaze me is just how butt-hurt people get when a group is maligned in any way, but without any regard to facts that might be a reason for such maligning. Seems to me that thinking has been dropped out of the education system, and far too few people are willing to do it any more.
My point was to avoid generalizations and that stating that all full stack developers lack this ability as a fact is just wrong. I certainly hope you aren't suggesting I was butt-hurt. My skin is as thick as most people's heads. 🙂 I was simply calling BS on declared fact that was not correct. Calling fake news and fake news.
I whole heartedly agree that a majority of those folks are clueless when it comes to databases (if not the rest of the stack). And much like you I also get called in to help unravel a stinking pile of poop left behind by some moreoff who shouldn't have been in the database in the first place.
Since we are all on the same team here let's call it a Friday and go get a beer!!!
_______________________________________________________________
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/
April 13, 2018 at 1:17 pm
Since we are all on the same team here let's call it a Friday and go get a beer!!!
yeah BUT IT BETTER NOT BE THE WRONG BRAND OF BEER!!!!
Viewing 15 posts - 31 through 45 (of 191 total)
You must be logged in to reply to this topic. Login to reply