October 22, 2024 at 5:10 am
SQL Server is the backbone of the product I've been developing for most of my career. I'm also in the 61 club. I've even mentioned that retirement is on my agenda in hopes of easing the transition for the product team and avoiding the total loss of my 30+ years of accumulated technical and business knowledge. The response was: You're never going to retire and you're never going to die so let's not talk about that again.
Besides my eventual removal from the picture, the product itself is built out of pieces developed in now-dead languages or using tools installable only on now-dead operating systems. These are all facts that I'm predicting will someday bring about the end of the product, perhaps suddenly. Our systems people are doing their part, upgrading O/S and related software, forcing SQL Server upgrades. The product team is doing what it can, limited as it is to two developers and no dedicated Q/A.
The sky is not falling today; I'm pretty sure it won't be a single planet-killer meteor. But I believe it's inevitable and the time for action may have already passed.
I understand Grant's article is being presented from a personal point of view with the goal of keeping yourself relevant. But how do you play your part in avoiding becoming extinct on a product or corporate level without being seen as Chicken Little?
Sitting in Greece as I type this, so I'm sure that's playing a part. Cassandra wasn't listened to either. Yet, Troy fell.
I don't have a good answer for you. I'd simply point to real world events. An editorial I wrote a few weeks back covered the collapse of the Amateur Radio Relay Leagues computing systems following a ransomware attack. They too were running on dead operating systems using dead databases and dead software. Recovery was extremely difficult (months, not weeks) in some cases, and seems to be impossible for others. "If it ain't broke, don't fix it" does make an assumption. The assumption is, if it does break, it can be fixed, or at least easily replaced. Maybe proposing a recovery test. "How long will it take us to come back online if we lost it all." Assuming your test actually comes back online, the amount of time that takes can give you and the business a realistic assessment of just how scary a position you're currently in... or not. Maybe it's all fine. Maybe.
But, even with that information in hand, you may still be Cassandra. But based on what you're saying, you're absolutely not Chicken Little.
Good luck.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 22, 2024 at 7:14 am
As another over 65 with many years of SQL developing and DBA, I'm now lucky enough to work for a company that has decided to go over to AWS, S3 and Athena and take its staff along for the ride so training etc is there, even for those of us who have downsized to three or four days per week.
It's a fine adventure though I wish Fabric had been a couple of years sooner as the decision may have swung that way instead.
Never too old to learn!
October 25, 2024 at 8:26 pm
My thoughts:
I picked up SQL Server a point release after the author (6.1 v 6.0) While I had databases in school, I did not really know SQL. I had used Access at a previous position and relied heavily on the query builder to create my SQL. It was not until I had trouble getting the builder to do exactly what I wanted it to do that I really pressed in on learning SQL. Now I can say that I can make it do whatever I need it to do.
I say all that to say that business runs on data. While newer concepts are cool and can even be useful, I do not think we have much to worry about - which ever path we take - pressing in on the newer stuff like Fabric, etc or relying on tried and true methods. We need to be able to find that one set of records from among the million candidates. I believe our skills are transferable - someone will have to know how to traverse the fabric and that person will be a developer.
October 25, 2024 at 8:27 pm
My thoughts:
I picked up SQL Server a point release after the author (6.1 v 6.0) While I had databases in school, I did not really know SQL. I had used Access at a previous position and relied heavily on the query builder to create my SQL. It was not until I had trouble getting the builder to do exactly what I wanted it to do that I really pressed in on learning SQL. Now I can say that I can make it do whatever I need it to do.
I say all that to say that business runs on data. While newer concepts are cool and can even be useful, I do not think we have much to worry about - which ever path we take - pressing in on the newer stuff like Fabric, etc. or relying on tried and true methods. We need to be able to find that one set of records from among the million candidates. I believe our skills are transferable - someone will have to know how to traverse the fabric and that person will be a developer.
October 26, 2024 at 3:03 am
I started out with SQL Server 6.0 many moons ago, as well as Ingress II, Informix 8, and shortly thereafter Oracle 7.3, all of it except for SQL Server running on some flavor of Unix, and everything using a standard C syntax. I still remember using the Microsoft Jet Engine to translate between SQL 6.5 and eventually 7.0 and Informix 8 because we didn’t have another way to do that. I recall writing a COM wrapper which spit out queries in HTML, PDF, Word, and Excel formats, because nothing else did that. Fast forward a decade or so and everything was stable, and I had no more need for the Jet Engine or a COM wrapper because everything just talked natively with ODBC and OLAP and reporting were built into all the RDBMS platforms, and they all had graphical IDEs with managed code, no more writing C in a text editor. Another decade later and some of the old players were gone, replaced by Postgres and NoSQL databases, as well as Hadoop and others giving us “Big Data”. The main jump in the past decade has been splitting compute away from storage, but we’re using SQL more than we ever have to do things with the data, and thanks to Hadoop, we’re also using Java and going back thirty years and using Python once again, it’s not just that new programming language running Yahoo!, and MapReduce isn’t just the algorithm Google swiped from Yahoo! to build search results. Also, everything is pretty much all in memory now, whether RAM or an M2 drive, or an SSD SAN. Other than the separation of compute and storage, BLOBs and JSON, and XML are no longer awkwardly packed into relational tables, instead they’re dropped into cheap cloud storage, and an offshoot of Hadoop such as Spark or Snowflake takes all of those formats and uses some form of MapReduce to build them into structured data so we can run SQL queries against the data and perform analytics on large compute clusters. I don’t think SQL and structured data in an RDBMS is going anywhere anytime soon, but if it does, we’ll just start using the Python we used to build interactive websites on yahoo! thirty years ago, right? I’m okay with that. It’s much nicer than trying to debug C in a text editor or having to run a SQL query for several hours only to see it fail on bad data that can’t be cast implicitly. The nice thing about being a dinosaur is that the stuff we used thirty years ago is all sparkly and new again now, and nobody except for Yahoo! knows we already know it and that we’re already experts. Maybe there’s a Python code camp somewhere warm in our future? I would not complain about a quick review and some time in the beach.
Joshua Perry
http://www.greenarrow.net
November 12, 2024 at 6:52 pm
I do not check SQL central every day, so I missed the article when it first appeared. I am in my 7th decade too, and potential dinosaur. Somehow, most of the problems in business practice I have encountered were solvable in relational way. True, executives would like to get rid of old chaps, cause we are slow learning Power BI reports. But so are younger folks, I can see it around. But that is not the point.
The point is relational theory is a branch of mathematics and will be around until somebody proves it is not true, the theory I mean. Pythagoras's theorem never went out of fashion for at least 3,000 years. OK, it is ancient. But Boolean algebra is not that ancient, and is not going anywhere soon. the trouble is, that same kids that do not study relational stuff, often do not even study math at all. manty time s I was horrified learning that the new "data wrangler" sitting next to me does not know what implication or equivalence is.
The rouble is it is relational theory not even taught at schools, or at least not as much as it would be necessary. There are courses Databases 101 where they teach kids - SQL. The theory may become forgotten in some future, nobody is learning it, nobody will be using it, it will simply disappear. That may happen, but not so fast. In different parts of the world, people may have different approach to data business.
I met people who argue that inventing pocket calculators is not a bad thing, since the calculator finds n-th root faster than human. I agree with that. But there is no calculator to speed up database design ,. pen and paper still it is. And knowing the business you are trying to support.
We could be all downsized. The problem is we are the last generation that studied mathematics seriously, as pre-condition to use it in programming, later databases. What happens after that? The same thing that happened once dinosaurs were gone. Some kind of a dark age.
Zidar's Theorem: The best code is no code at all...
November 12, 2024 at 7:23 pm
The problem is we are the last generation that studied mathematics seriously, as pre-condition to use it in programming, later databases.
What's this "we" stuff. I'm a film school drop-out. Ha!
But I see your point. It is part of why the relational database seems to continue to hold on forever.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 12, 2024 at 7:32 pm
'Relational databases' may change over time, but relational thinking is what gives value to data.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 12, 2024 at 7:57 pm
Zidar, I was one of the lucky ones. Have related this before, but anyway, I faced downsizing as I approached retirement. I took their early out offer, started SS and my little pension. Few weeks later got a phone call asking me to return to work. I negotiated a good raise ($6k), some additional benefits like unlimited time off, no meetings, etc, and worked another three years. Downsizing can be a good thing sometimes.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 12, 2024 at 8:10 pm
I hope we all get downsized with the payout, followed by the negotiation to come back like you skeleton567. I like to imagine doubling my salary, cutting my hours and finally getting a team to work with, all with a short time frame to real retirement. On the other hand, they could see the light before that and spoil all that fun!
November 12, 2024 at 8:15 pm
I''m kind of embarrassed that I only discovered C. J. Date aka Chris Date and his writings (and presentations on O'Reilly) this summer, and that only due to Ralph Kimball mentioning him in his first magazine article for DBMS magazine in September 1995 (The Database Market Splits) and A Dimensional Modeling Manifesto, DBMS, Aug 1997 https://www.kimballgroup.com/1997/08/a-dimensional-modeling-manifesto/.
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply