August 14, 2019 at 12:37 am
My thought is more like a question. Why can't more features and functionality be added to SQL language and stop creating more languages to learn? If not, let's all go back to C++ and call it a day.
Lordy no. Look at what they've done with some of the new features in the past...
PIVOT... totally crippled compared to what MS Access has.
FORMAT... an average of 43 times slower than CONVERT.
DATE, TIME, and DATETIME2... all direct date math that still exists and is very valuable in DATETIME doesn't work.
DATEDIFFBIG... the "Fix" for the shambles they made of DATETIME2.
XML... always the worst performing thing in any execution plan where it appears.
HIERARCHYID... ridiculous compared to what it could have been.
STRING_SPLIT... Seriously? A splitter with no element ordinals? SERIOUSLY???
MERGE... lots of problems for years and is reportedly still slower than writing an UPSERT.
RECURSIVE CTEs... slower than a speeding WHILE loop.
ALTER INDEX REORGANIZE... removes free space on one side of the FILL FACTOR and does nothing for the other side which, like a bad drug, requires you to use it more the more you use it not to mention explosive log file growth (much worse than REBUILD). It, alone, is why most people think random GUIDs are the worst when it comes to bad page splits when it's actually one of the best (an index based on random GUIDs can easily go for literally months of inserts without even a good page split. GUIDs suck for other reasons, though).
ALTER INDEX REBUILD... it wasn't done right when it was DBCC DBREINDEX and they made little change with the "new" syntax. You can put a new wrapper on it but it's still the same ol' cracker. Peter Norton isn't jealous of this mistake at all.
SHRINKFILE... this is where Peter Norton started to laugh out loud. It could have been done so right and, instead, they used the worst method possible.
MAX DATATYPES... the principle is great but defaulting to INROW was absolutely stupid (and I wrote a presentation to demonstrate).
DEFAULTING TEMPDB TO TF1117 WITH NO WAY TO OPT OUT... I almost broke out my postal uniform and drove to Redmond on this one thanks to the next problem.
IDENTITY_INSERT... try that with a big Clustered Index on a box where TEMPDB is defaulted to TF1117 and discover how fast all your files grow because the whole table is sorted in <drum roll please> TEMPDB.
DTS/SSIS... an easy way for people that know squat about importing and exporting to really mess up especially if you want to move packages through Dev, Test, and Prod or when migrating to a new box with an upgraded version of SQL. And, no, that's not a slam on the good folks that took the time to actually learn how to use it the right way.
WINDOWING FUNCTIONS... great tools but it took them 7 years to make them fully functional.
sys.INDEXES... sys.SYSINDEXES is so much more functional but has been deprecated for years. Why the hell can't they leave useful tools the hell alone?
The list goes on and on.
They're supposed to finally fix BULK INSERT so that it will easily import TRUE CSV and the joke version of CSV that MS EXCEL exports. BULK INSERT is currently the fastest method to import data there is in SQL Server. Let's hope they don't screw that up by using RegEx Replace or something stupid that will slow it down.
And there's still no high performance "Tally-Table-Like" intrinsic function even though it's been held open on CONNECT and the Azure Feedback. Seeing what they did with String_Split(), they'd probably screw that up anyway by doing something stupid like converting it to an rCTE behind the scenes.
And still no BULK EXPORT or supported method to read a directory.
And remember the problems in 2012 where doing an ONLINE REBUILD of a Clustered Index could and did corrupt data?
I've gotten to the point where I actually fear each an every SP and CU and new release. I wish they'd spend a lot more time on fixing a the bastard new functionality they produced as well as fixing a whole lot of the old stuff.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 14, 2019 at 2:06 pm
SQL and HTML/JavaScript are two sides of the same coin. Both languages are easily accessible but broadly misused. Most complaints about "limitations" are actually founded on misconceptions about how the language's intended purpose.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 14, 2019 at 4:23 pm
SQL and HTML/JavaScript are two sides of the same coin. Both languages are easily accessible but broadly misused. Most complaints about "limitations" are actually founded on misconceptions about how the language's intended purpose.
Totally agreed with that. Another problem is that a lot of people won't take the time to actually learn those things. In other words, some of the "limitations" people perceive are self-induced simply by not learning all there is that is offered.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 15, 2019 at 9:19 am
It is because they are successful. DBA aren’t skillful enough to take it to that level and develop an installer or whatever is needed so they are no longer needed.
Or maybe there are DBA who are. And this is the mentality DBA who aren’t quite there should have. It is important to finish what you start...
I'm a DBA, I can code in C#, pascal, 6800 assembly, 8502 assembly in hex, VB script, 6502 assembly and C++. I can write an unmanaged CLR assembly for SQL . I know how C++ MALLOC worked well before C# introduced idispose
DBAs are skillfull and saying otherwise is kinda disrepectfull
my DBA colleague deals with things that I don't know about like GDPR and server hardware (I performance tune bad developer code and write internal apps)
we all as a collective community have more skills than a lot of our bosses know about
MVDBA
August 15, 2019 at 9:30 am
HIERARCHYID... ridiculous compared to what it could have been.
MERGE... lots of problems for years and is reportedly still slower than writing an UPSERT.
RECURSIVE CTEs... slower than a speeding WHILE loop.
lol.. i agreed with all of the points, except for these 3... they save me so much time.. particularly hierarchyid
MVDBA
August 15, 2019 at 10:27 am
There's definitely truth in the idea that a wave of tools aimed at generalist users (e.g. Notebooks like Jupyter and Zeppelin; platforms like DataIku) are continuing to broaden the scope of people doing development stuff. I don't think that moving away from "custom scripting" (whatever that means) is really a significant part of that though. However, all of the important innovations in data management over the last 6-10 years have happened outside the core "SQL DBMS" space. I suspect that will continue to be the case.
August 15, 2019 at 12:14 pm
all of the important innovations in data management over the last 6-10 years have happened outside the core "SQL DBMS" space. I suspect that will continue to be the case.
Not so sure .. how about NoSQL and all the other cool stuff that we got. I think the issue is that Data is less glamorous than front end development. So Dev tools are designed around the "cool guys"
we all know that without our databases kept in top shape that web sites and apps will suffer after 1 year of use
MVDBA
August 15, 2019 at 2:51 pm
However, all of the important innovations in data management over the last 6-10 years have happened outside the core "SQL DBMS" space. I suspect that will continue to be the case.
I generally agree with that but will also state that's a large part of the problem. If they spent a little (a lot, actually) more time fixing some of the stupid and incomplete "improvements" they've made, add some missing functionality that has been asked for for almost 2 decades (they're finally getting that idea with the CSV improvement on BULK INSERT in 2019... let's hope they don't make the rest of BULK INSERT slow in the process), and stop deprecating incredibly useful features, then there might not be such a need to do so much outside the core.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 15, 2019 at 3:19 pm
nova wrote:However, all of the important innovations in data management over the last 6-10 years have happened outside the core "SQL DBMS" space. I suspect that will continue to be the case.
I generally agree with that but will also state that's a large part of the problem. If they spent a little (a lot, actually) more time fixing some of the stupid and incomplete "improvements" they've made, add some missing functionality that has been asked for for almost 2 decades (they're finally getting that idea with the CSV improvement on BULK INSERT in 2019... let's hope they don't make the rest of BULK INSERT slow in the process), and stop deprecating incredibly useful features, then there might not be such a need to do so much outside the core.
"They" being Microsoft? Sure. But I now see that my words were poorly chosen. When I said "outside the core SQL DBMS space" - what I meant was that the leaders in data technology are not Oracle and Microsoft. All the innovative data management software in recent times comes from Amazon, Cloudera, open source and numerous disruptive startups who have made advances that have left the big SQL DBMS vendors well behind. Fixing legacy issues in SQL Server is not going to change that.
August 15, 2019 at 3:46 pm
All the innovative data management software in recent times comes from Amazon, Cloudera, open source and numerous disruptive startups who have made advances that have left the big SQL DBMS vendors well behind. Fixing legacy issues in SQL Server is not going to change that.
Ah... in that case, totally agreed.
However, while that is certainly true and very valuable to companies of that size, most companies will never come close to needing the requirements that Amazon, EBay, and other monster companies need. When it comes to those that can easily use something a bit less expensive, the core RDBMS products are a great fit and the people building those products need to pay a whole lot more attention to them without making them so complicated that smaller companies with smaller or non-existant IT departments can still use them and larger companies still find good value in them.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 15, 2019 at 4:07 pm
However, while that is certainly true and very valuable to companies of that size, most companies will never come close to needing the requirements that Amazon, EBay, and other monster companies need. When it comes to those that can easily use something a bit less expensive, the core RDBMS products are a great fit and the people building those products need to pay a whole lot more attention to them without making them so complicated that smaller companies with smaller or non-existant IT departments can still use them and larger companies still find good value in them.
Huh? There are millions of people using newer data tech like Hadoop, Spark, Tensorflow, Kafka, Redis and packaged solutions like Snowflake, DataIku, DataBricks. Most of their customers are not "monster" companies and the attraction of these products is that cutting edge tech, either cloud or on-prem, is available so cheaply.
August 15, 2019 at 5:07 pm
There's definitely truth in the idea that a wave of tools aimed at generalist users (e.g. Notebooks like Jupyter and Zeppelin; platforms like DataIku) are continuing to broaden the scope of people doing development stuff. I don't think that moving away from "custom scripting" (whatever that means) is really a significant part of that though. However, all of the important innovations in data management over the last 6-10 years have happened outside the core "SQL DBMS" space. I suspect that will continue to be the case.
Maybe all those important innovations outside the core are because that is where the innovation is most needed. Time to catch up?
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
August 15, 2019 at 6:06 pm
TamusJRoyce wrote:It is because they are successful. DBA aren’t skillful enough to take it to that level and develop an installer or whatever is needed so they are no longer needed.
Or maybe there are DBA who are. And this is the mentality DBA who aren’t quite there should have. It is important to finish what you start...
I'm a DBA, I can code in C#, pascal, 6800 assembly, 8502 assembly in hex, VB script, 6502 assembly and C++. I can write an unmanaged CLR assembly for SQL . I know how C++ MALLOC worked well before C# introduced idispose
DBAs are skillfull and saying otherwise is kinda disrepectfull
my DBA colleague deals with things that I don't know about like GDPR and server hardware (I performance tune bad developer code and write internal apps)
we all as a collective community have more skills than a lot of our bosses know about
You listed 8 bit processors. You capitalized malloc, additionally you use malloc in C++.
What am I supposed to think???? Am I supposed to now trust you with the future of our databases? Well heh I guess I would trust you more than "Phil Factor" but man, is this the best its gonna get for me? You know I have trust issues right????
Heh SSC is where the dba's meet their blub paradoxes.
August 15, 2019 at 6:24 pm
Wow! Lots of comments.
I believe that we we can keep SQL and just 1 more language... say Python (or whatever you like). Then we can just continue to enhance these 2 languages and not introduce more and more languages to learn.
Just a thought as a DBA since SQL 7.0 (you can figure out the date). I too have many languages under my belt, but still love SQL development as I don't have to learn a new language every time MS or industry thinks it's time to throw more stuff at us.
Rudy
August 15, 2019 at 7:29 pm
Few other professions are so clearly led by marketing people. The surgeon, for example, who eyes you up whilst fingering a scalpel doesn't often get his expertise and advice from non-medical marketing experts. The bridge you drive over during your commute was designed by engineers who were driven only by professional experience and technical knowledge, not soft-focus stock images in glossy brochures. The IT industry is odd in this way.
Here's the difference... You can't watch a few YouTube videos, ready a few blogs and download some free software and become a surgeon or structural engineer. You can, however, become a developer that way.
Being a developer is a relatively well-paying career with almost no barriers to entry.
Unfortunately, being a "developer" doesn't necessarily equate to being a "good developer". It' just means you are competent enough to not get fired. The problem is further exacerbated by the fact that neither recruiters nor hiring managers are knowledgeable enough, themselves, to differentiate between a hack and someone with real talent. The result... more often than not, companies will favor a candidate who is mediocre at a lot of things over one who has spent years honing their skills as a specialist.
I get sent job postings, from recruiters, on a fairly regular basis. The vast majority are borderline comical. They want a senior DBA with 10 years experience in SQL Server, Oracle, Access, Postgress, MongoDB, Hadoop & NoSQL in addition to being a "full-stack" developer. There is definitely a perverse incentive to put quantity over quality on one's resume.
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply