Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Not Only SQL Expand / Collapse
Author
Message
Posted Wednesday, October 19, 2011 9:57 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 8:53 PM
Points: 33,204, Visits: 15,353
Comments posted to this topic are about the item Not Only SQL






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1193326
Posted Thursday, October 20, 2011 6:11 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
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.
Post #1193588
Posted Thursday, October 20, 2011 6:35 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, August 18, 2014 9:20 AM
Points: 1,264, Visits: 3,567
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.


______________________________________________________________________________________________
Forum posting etiquette. Get your answers faster.
Post #1193615
Posted Thursday, October 20, 2011 7:15 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
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
Post #1193649
Posted Thursday, October 20, 2011 7:18 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, November 18, 2012 10:58 PM
Points: 63, Visits: 216
"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
Post #1193652
Posted Thursday, October 20, 2011 8:55 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, August 29, 2014 4:17 PM
Points: 1,651, Visits: 4,709
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.
Post #1193803
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse