November 20, 2013 at 8:45 pm
Comments posted to this topic are about the item What is SQL Server not good at?
November 20, 2013 at 10:11 pm
The article link in the post above doesn't work. It takes me to a "Not found" window.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 21, 2013 at 12:49 am
You can find the article in the daily newsletter. Can't find it on the site though.
What's SQL Server not good at?
SSRS and SSIS could certainly improve a lot in regards to usability. Especially SSRS lacks some very basic features, such as a decent configuration of prompts and even "justify text" is missing.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
November 21, 2013 at 2:23 am
I guess it could be a question of emphasis. Surely it would be to the advantage of Microsoft to give a greater impression of openness, clarity and helpfulness if they did highlight (particularly common) abuses and poor uses of various features especially if they offered explanations and alternative solutions.
Let's face it, when it isn't done the perpetrator of such implementations will often blame the tool (in this case SQL Server) instead of a misguided use of it i.e. "it can't be my that's wrong it must be [SQL Server/SSIS/SSRS/.NET/etc.] that's rubbish".
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 21, 2013 at 6:10 am
I think the trouble is that with software, if you can properly state the problem you can usually state the solution in code. It means once you've properly identified a weakness you'll already be halfway to planning the solution. Would you prefer to own up to something people might not even have pinned on you? Or would you just rush to fix it and enjoy the praise for innovation when it's done?
e.g. One of the supposedly inevitable aspects of databases used to be that a lot of locking must occur. What's the solution to too many people and processes reading and altering the same bits of data? Err...don't.. At least find ways to make transactions really quick then keep your fingers crossed. READ UNCOMMITTED is what many still dangerously resort to because of this and even READ COMMITTED doesn't guarantee you consistent data from a given instant in time. Before 2005 do you imagine Microsoft were thinking 'Well, a mostly good solution would be to do like some other DBs and build snapshots in the background and query those". Of course they did but they didn't come out and make a big noise about how the paradigm was fundamentally flawed for high transaction environments. They bided their time till they could get Snapshot Isolation Level implemented. You'd do that yourself if it was your own program and you had pride in it. In a community of eagle-eyed users, you'd be desperate to fix quickly rather than do all the criticism for them.
Adam
November 21, 2013 at 6:35 am
I tend to rely on google and experience, as well as one on one interaction to address the issue that you raised here. It is the nature of the form of documentation that it is a bad place to put what the limitations are. Makes it too easy for competitors to attack your business.
November 21, 2013 at 8:26 am
Even if it's included in BOL, would people read the warnings?
Most people having bad coding habits won't even read basic documentation and go for what they suppose is better with no real bases.
November 21, 2013 at 8:46 am
Luis Cazares (11/21/2013)
Even if it's included in BOL, would people read the warnings?Most people having bad coding habits won't even read basic documentation and go for what they suppose is better with no real bases.
That is probably fair comment regarding a significant number, however, a lot of people do at the very least a little research around features that they are about to utilise, especially on new features or those last used a long time ago. I think it is an inadequate reason not to do it on the basis that most people will not pay any attention to it. It would be there for those of use who do read up. Thus marking as out as being different from the rest of the crowd. Otherwise BOL wouldn't exist either.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 21, 2013 at 9:11 am
MS hardly admits problems.
As a old joke said "...MS is a marketing corporation with serious software issues"
At forums and MSDN they often use the "its by design" or "its a normative variation" excuses.
IMHO MS SQL Server is by far the most reliable product from MS and today its a mature software full of usefull tools.
But if there are something its not good... maybe its not good for the small shop budget.
I work most with web development where MySQL and Postgre earn great popularity and MS SQL got a reputation of too big, and too expensive.
Maybe we can see more SQL Lite brands (for free) in the future.
November 21, 2013 at 9:43 am
To quote the favorite answer of technical people everywhere, "It depends". I can take a simple select statement and if I miss something in the where clause I can tank the server. Does that mean we should put warning signs all over? SQL Server is a tool. I can use a screwdriver to drill a hole but it won't be done neatly or easily. There are too many ways to misuse any tool and get bad results. While I do think that it is nice to know limitations or shortcomings sometimes I feel that I am better off not knowing.
November 21, 2013 at 9:50 am
steve_seeley (11/21/2013)
To quote the favorite answer of technical people everywhere, "It depends". I can take a simple select statement and if I miss something in the where clause I can tank the server. Does that mean we should put warning signs all over? SQL Server is a tool. I can use a screwdriver to drill a hole but it won't be done neatly or easily. There are too many ways to misuse any tool and get bad results. While I do think that it is nice to know limitations or shortcomings sometimes I feel that I am better off not knowing.
Tools can be misused and in some cases downright dangerous in the wrong hands.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
November 21, 2013 at 10:18 am
What SQL Server doesn't do well (or at all) is true active-active clustering for the purpose of load balancing. I think the lack of a solution there is leading people to look at Oracle or (gasp!) Cassandra as better database solutions.
November 21, 2013 at 10:34 am
SQL server is not good at scale-out (in particular), or DR, 2012 always on is getting there but its still complex.
This is because SQL is so tied to the servername and metadata is held outside the database in system databases.
A simple database engine only instance is OK but as soon as you start adding SSIS, SSRS, linked servers etc it gets messy quickly to maintain failover servers.
MS tend to gloss over this.
---------------------------------------------------------------------
November 21, 2013 at 10:47 am
Backup and restore require far too much hands on DBA work. I've mentioned this before here, but back in the 1980's, mainframe DB2 just required a restore database statement to some point in time, and it took care of the rest. The DBMS knew about all of the backup and log files, and did whatever roll back and roll forward that was necessary. Object level recovery should not require a 3rd party vendor product.
Oracle's GoldenGate walks all over replication. It queues up the replicated data, can easily be monitored, and is easily restartable when something goes wrong. It supports many DBMS', and can be used for SQL Server -> SQL Server replication.
The built in monitoring tools are primitive. Quest/Dell even give away a basic version of SQL Spotlight called Spotlight Essentials. Microsoft should include the equivalent of all of the free 'lite' versions.
November 21, 2013 at 10:54 am
Jeff Moden (11/20/2013)
The article link in the post above doesn't work. It takes me to a "Not found" window.
Do you mean the URL to the editorial? Or the one to the article I referenced? Both work for me. They're here:
Editorial: http://www.sqlservercentral.com/articles/Editorial/104983/
Article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply