Never forget, we’re making buggy whips. And everybody we know drives little buggies and they need our buggy whips. We’ve got a special talent, a unique knowledge set, and it’s fulfilling a defined need. So we’re all set, right?
Well, other than that Stanley Steamer over there. And maybe that Ford. Oh, and there’s a Grant.
I worry about this stuff all the time. I know SQL Server. Before that, back in the day, I worked on Paradox, PAL & OPAL. I learned and programmed in Visual Basic, Java, C# and .Net. I’ve made sure that I’ve explored, let’s see, Hadoop, Mongo, MySQL, and others, structured and unstructured, relational and non, you name it. Why? Because, I want to keep an eye out for the automobiles that are going to ruin my nice little buggy whip manufacturing business. I make money on these buggy whips and that feeds my family.
Now, here’s my current question/thought/worry/thingie… How does business analytics fit into this? Is there a path that I may need to explore that moves me from working primarily within a focused technical sphere to working with PowerWhatever? Is that a path that people take? Or, is that actually leaving the technology path to become primarily business focused? That’s what I’m trying to figure out. Yesterday we did Oracle. Today we’re doing SQL Server. Tomorrow we’re working on Hadoop. Next week… Wouldn’t it be data vNext for the data professional? Or is it that the data pro’s path lies, at least what appears to me, outside of a pure technical scope?
I’m not sure. But it’s something I’ve realized I might need to at least explore a little before I dismiss it out of hand. I may sound a little snide or scornful, but I’m not trying to be. I absolutely recognize the size of the analytics market. It’s vast. And, I’m actively concerned. Does this represent a horseless carriage? I am unsure, but I’m also a little nervous. It feels like I would be abandoning technology, to a degree (recognizing that this too requires technical know-how). Technology (buggy whips!) has been my primary driving force, even when I was in the Navy.
But, we all do have to worry about this. You absolutely don’t want to be trying to sell those buggy whips when everyone is buying cars. If you do think the next step is analytics and you’re ready to go down that analytics path, I can help a little. I’ve got a discount code that will get you into the PASS Business Analytics Conference for a reduced rate. Just enter BFFGF when prompted. This very well could be the right choice to avoid the whole buggy whip problem (until the next time, because it’s buggy whips all the way down). Or, if you just want to get your feet wet, check out the BAC Marathon.
In the meantime, I think I’ll explore how this DocumentDB thing is working. I’m just not sure I want to give up on technology to focus primarily on the business just yet. But I’m seriously curious what others think about this. Is analytics the logical next step for the data pro? Is that a horseless carriage?
Sanity check: you don’t host OLTP databases in Excel.
Just because there’s something new doesn’t mean you’re working with buggy whips. Analytics is a *different* thing, much like tractor trailers don’t present a threat to automobiles. They’re different vehicles to take different things to different markets. The developer out there isn’t saying, “Man, I just can’t decide between PowerBI and SQL Server.”
If you’re worried about buggy whips, think PostgreSQL, Azure SQL Database, Amazon Dynamo, etc.
C’mon, man. Put a little thought into that first. You’ve only been through one Board meeting. 😉
The buggy whip analogy may be wrong, but I agree with the bulk of this post. Too many of us relational guys view these “alternatives” as ridiculous fads and refuse to learn the technology/concepts. The alternatives are winning. I have too many clients that have success with these tools, in spite of the fact that in most cases a relational solution would’ve been better and/or they totally did their document store approach wrong.
One client is implementing “get the nth record/pagination” in a document store. They coded it like a relational guy would with row_number() over() and ranking. Wrong. That should be a new document collection.
What companies like about these alternatives is that there is no expensive licensing, no expensive DBA, no expensive SAN. But mostly they are tired of hearing that simple changes to their relational schema will require downtime, regression, $$$, etc. That’s why, IMHO, more shops are sneaking in the alternatives.
One of my favorite posts EVER is Grant’s rant on this: https://www.scarydba.com/?s=the+curse+of+the+relational
We, as relational guys, should be learning about the alternatives. At a minimum this allows us to make intelligent arguments and see through some of the NoSQL bullshit. Example: A relational guy at the same client “proved” that a SELECT COUNT(*) equivalent query ran 5 orders of magnitude slower on Hadoop than on SQL Server. So what? That’s not a valid Hadoop use case. Relational will always be faster than Hadoop for reporting use cases. They admit this. Where Hadoop shines is the data analytics that can be pushed to the data instead of done in a different tier.
I guess I’m not a fan of this post, sorry Grant.
I – like many others – want to keep current and have the skills and knowledge we need for this job and the next. Figuring out “which” technology to bet on is tough, there is no clear winner, so we try to dip our toe here and there to see what its all about. If our client/employer isn’t using that stuff, then we really struggle to get practical experience.
I want to be a SQL Server guy, plus. Talking about buggy whips makes it sound like the ship is sinking. It’s not, today. Five years? I doubt it. Ten? By then with a fully formed cloud and other stuff maturing? There’s a risk there, for sure.
I really don’t like the fear based sale. Talk to me about why adding X to my resume makes me worth more today or tomorrow, or why sticking with product current could leave me without a job in two years. That is how you convince me to go/try. If you really want to help, survey the universe and show me the options in various sectors (nosql, analytics, etl, etc) and tell me which one looks like the best bet and why.
Finally, I’ll say that the problem I see with BAC isn’t the content (which I’m not qualified to grade as appropriate to the title of the event or not) is that you’re selling it to the SQL Server portion of PASS. Why aren’t you selling it to the BAC community?
Grant, as always, thanks for posting and doing the stuff you do, even if we sometimes disagree.
Andy
Hey guys,
Sorry I haven’t responded. I’ve been holding off to see how many comments come in.
Just some clarity about the buggy whips analogy. No, I don’t think we’re looking at the death of the DBA or relational storage or any of that in the near term. BUT…
Growing up working at a hot-type newspaper, watching the hot-type people get replaced by cold-type, helping the desktop publishing revolution kill off the cold-type people, only to see a pretty hefty percentage of the desktop publishing jobs go away, I’ve watched technologies die. They will. Not saying our is. Just that it’s something I’m always trying to be aware of.
So, is analytics the next step for a technologist? I don’t think so. Flat out. But, I want to see what others think and you guys have delivered.
Brent, agreed. I think DocumentDB and others are more worth my time.
Dave, I agree with you since you agree with me. Ha! I think we need to stay on top of the technologies. The only question is, which technologies are likely to “win.” And, which ones am I best positioned to grow into. I’m unconvinced that analytics is it. Oh, it’s going to be absolutely gigantic, but I’m unclear how I’ll be contributing to it directly.
Andy, I’m not really trying to sell BAC here. I’m bringing it up because there’s at least the suggestion, if not outright statements, that analytics are the next step for X-amount (unclear & undefined) of data professionals. And, I’m not trying to scare anyone into it, beyond my own fears of dead/dieing technology (hot-type reference inserted here). I specifically wanted to hear what people thought. Thanks. No worries on disagreement. That’s fine. Encouraged even. Keep it coming. It’s exactly what’s needed.
However, I suspect, we’re probably not much in disagreement.
Grant, to follow up on that, I’d bet for most “dba types” that getting a grounding in one of the NoSQL’ish/not logged/no guaranteed transaction solutions is the one that most likely to be valuable. How many times have we been asked if we could turn off logging because it wasn’t needed? How many of those DBA types prefer files in the file system vs putting them truly in the db?
Let me try this this – is the role of the DBA going away, or changing to different product/tools? I feel like we’re telling DBA’s they have to morph to a different career track, and that’s much differnet from saying learn this new but mostly similar product/tool that will fit into the silo that you (and your employer) see yourself filling.
Let me be the oddball in the room that’s late to the party.
I work a lot with analytics and SQL Server. I can see some pitfalls in the future of any tool I work with. SQL Server, much like the Hadoop framework and many other up-and-coming tools are just that–tools. You use the best tool for the job.
That said, the need for the relational database is pretty strong. OLAP is pretty strong. But, the need to implement new data sources, run complex algorithms, massive computing and the works is pretty strong too. Many of those mentioned solutions help with that, especially when diving into statistics, predictive analytics and more.
But for me, I don’t really see that as a replacement of something like SQL Server or even that DBA. As someone mentioned, different vehicles for different destinations. I see my solution as a multi-stalled garage where my SQL and Hadoop are side-by-side to help me get to where I need to be depending on the day.
Thanks for the feedback Glen. I don’t disagree.
In 1970 I was piloting Medivac helicopters in Viet Nam. In 1980 I was a Chemical Engineer programming control systems for Exxon. In 1998 I was web programming in Perl. In 2002 I was an MCSE. In 2004 I was a certified SQL Server DBA. By 2007 I was an Oracle DBA on Linux. In 2011 I was a Data Warehouse Architect.
(1) Learn or Die.
(2) Sometimes the grass is not immediately greener. As a BI Analyst I am dinking with SSRS report screen layouts and earning less that my 1985 salary. Got to learn this side of the biz. Managers are super impressed by colorful dashboards.
(3) If you have been a DBA you have a huge advantage in the wider BI realm. Enterprise data is still in RDBMS tables.(No_SQL_Skill=Cripple)
(4) A DBA who knows only transactional systems should stay out of BI until he/she appreciates the distinctly different tuning and data modeling required by DW and analytics.
(4) Statistics and numerical methods are cool.