October 19, 2011 at 9:57 pm
Comments posted to this topic are about the item Not Only SQL
October 20, 2011 at 6:11 am
Steve,
You (shudder) about Oracle the way I use to shudder about SQL Server, OK I still shudder about SQL Server sometimes, but that is a different story. The point I want to make is that they both are still just tools. I have been working in a SQL Server space for the last 4 years after a 15 year experience with Oracle. Once I got past the "It's not Oracle" phase I came to realize and appreciate they are just tools for a "database person" versus an Oracle or SQL Server person.
Happily being paid for "Database" work in Minneapolis.
<><
Livin' down on the cube farm. Left, left, then a right.
October 20, 2011 at 6:35 am
Even (shudder) Oracle is something I'd use if it fits the particular problem I'm trying to solve.
You're done. You've just lost all credibility.
I kid, you're right. They are tools in an administrators belt. To be able to tell your customer you are familiar with an alternative databasing system will show you have a breadth of knowledge which provides more bang for their buck. To be able to understand how an alternative works in order to provide a minimal level of support for a customer's needs, means they are getting more value out of their investment (you). To be familiar enough with alternatives to discuss why they should or should not be pursued will instill confidence in your customer that you know what you're talking about.
You don't have to be an expert but keeping your eyes open and being aware of alternatives is a good thing.
October 20, 2011 at 7:15 am
Tools is tools, true.
On the other hand, specializing generally leads to a much higher degree of skill in the focus area. So, while all problems may look like nails to a hammer-specialist, the ones that actually are nails will be handled more effectively, quicker, and more permanently by that person, than by someone who has generalized into the whole woodshop and added in a metalshop and plumbing skillset on top of it.
So, I specialize in SQL Server, and pay enough attention to other tools to know they exist and the summary of the Cliff's Notes of the Reader's Digest version of what they're good for and why.
If I do ever need to use those things, I'll know they exist, and I have tremendous confidence in my ability to learn them if I need them. Learning them before I find a use for them seems like premature optimization to me. And time spent that I could instead spend on something more important, like learning how to maximize my DPS and tank for my new battleship in EVE Online. 🙂
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 20, 2011 at 7:18 am
"Big Data" I dream about. Being a young, junior DBA/developer/BI analyst, on a small project, I hope to one day dive right into the world of big data. I can't get enough of it.
Currently utilizing SQL Server 08', I see his point on the various tools to use, when appropriate. Although (shudder myself) Excel is much older technology, its capabilities still apply, dependent upon the scenario at hand.
I hope you enjoyed my run-on sentences 🙂
-Stephen
October 20, 2011 at 8:55 am
I agree that, if your application needs to reference very large entity-attribute-value datasets, then it would perhaps be best to move those specific tables out of SQL Server and into a NoSQL alternative that is more specialized for that purpose. Not only are EAV tables difficult to index and query in an optimized way, they tend to fragment more than conventional transactional tables, and they require a great deal of time and I/O to load or merge in an RDMS.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply