I was tagged
by master blogger Aaron Bertrand and asked to identify five things
that should be removed from SQL Server. Easy enough, or so I thought...
Tempdb. But I should qualify that a bit. Tempdb is absolutely
necessary for SQL Server to properly function, but in its current state
is easily the number one bottleneck in the majority of SQL Server
instances. Many other DBMS vendors abandoned the "monolithic,
instance-scoped temporary data space" years ago, yet SQL Server soldiers
on, putting more and more "stuff" into tempdb with every new version.
Some form of global tempdb may be required for temp tables and other
database-agnostic features, but for features like the version store,
index rebuilds, and DBCC, we should have a lot more control in order to
build the highest degree of performance and reliability into our
Tempdb should be taken out back, shot a
few times, and rebirthed as a smaller, leaner global store for only
very specific types of data. Everything else should go into
specially-marked, database-scoped filegroups so that DBAs can have
finely-grained control over how and why the space is used.
T-SQL Scalar UDFs. Scalar UDFs suck. There. I said it. And I'll
say it again. Did you know that scalar UDFs suck? I was just reminded of
this fact by a webcast done by Simon Sabin, but I've been saying
it for years. Scalar UDFs, at least of the T-SQL variety, are
painfully slow. And both varieties inhibit parallelism. Since their
SQLCLR counterparts aren't quite as painfully slow I'll leave them out
of this rant, but the T-SQL versions should be removed from the product.
Sure, they seem to be great during development, but as soon as the
application needs to scale they become a nightmare. Such timebombs
should not exist. SQL Server team, please defuse this situation and
replace the current UDFs with inline scalars.
User-Defined Types (again, of the T-SQL variation). User-defined
"alias" types were never exactly a panacea. Oh, joy. Instead of
"VARCHAR(36)" I can refer to "AddressLine". But at least, prior to SQL
Server 2005, they could be bound to "rules" in certain cases. This, in
and of itself, was wrought with problems--I won't bore you with the
details--but then the "rules" were deprecated. So now we're left with
these aliases, and it feels much like the proverbial hammer waiting for a
nail to show up. Every once in a while I'll run into a database where
some well-meaning developer discovered alias types and went crazy. And
then--always after it was too late--discovered the numerous problems
they bring to the table (pun absolutely intended). SQL Server should
toss these out with the rest of the garbage and bring in what should
have been implemented to begin with: ANSI domains.
SQL Server Management Studio. I'm going to have to agree with my
Woody on this one. SQL Server Management Studio should never have
been created. If I told you that I was going to take Microsoft Word,
cripple it until it became a weak text-editor lacking even spell check
support, and sell it as part of some other product, you would tell me I
was insane. Well, that's exactly what Management Studio is. Someone
decided that DBAs don't like working in Visual Studio, so the team
created a dumbed-down version of the shell, popped in a few extensions
for various SQL Server features, and there you had Management Studio.
The only problem? No one asked a real DBA what they thought, and since
all of the BI features are in Visual Studio every DBA I talk to already
has it installed anyway, in the form of BIDS. Management Studio should
be ripped out of Management Studio and brought back to where it makes
sense: As a Visual Studio plugin. This would instantly simplify the
lives of DBAs everywhere by reducing the number of environments they
need to work with, while automatically enabling a number of features,
such as proper support for plugins. A true win-win.
Database Diagrams. I actually had trouble finding five things to
put onto this list. I'm generally pretty happy with SQL Server's
features. So I took a look around and this is the best thing I could
find. Honestly, my overall opinion of database diagrams is kind of
"meh." The feature has never been great. I don't use it, favoring
various third-party products or even Visio when I'm desperate. I don't
know why this feature was never enhanced to become a full ER tool, but
in its current state it's a joke. Might as well just give it up.
that's that. Enjoy.