What Do We Want?

Question

What Do We Want?

Steve Jones - SSC Editor

SSC Guru

Points: 734418
More actions
April 21, 2010 at 10:35 pm

#223731

Comments posted to this topic are about the item What Do We Want?

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic. Login to reply

crazyEmu Old Hand Points: 322 More actions · Answer 1

How about better admin / monitoring tools. I know that 2008 R2 is a step in the right direction with the UCP… however it is only available for customers with Enterprise… what about those with Standard.

Something like the Oracle Enterprise Manager + Diagnostic pack would be great.

Blog: http://crazyemu.wordpress.com/
Twit: @crazySQL

kennethje SSC Enthusiast Points: 117 More actions · Answer 2

at the risk of sounding not very important:

I'd very much like to see 3 changes in the sql language taken from Oracle (I know, I know, I said the O word)

1. CREATE and ALTER:

instead of CREATE view/table/whatever:

and ALTER view/table/whatever:

in 1 statement

CREATE OR ALTER... (as oracle's CREATE OR REPLACE)

2. cursor functionality:

instead of :

declare @var1 nvarchar(10)

declare cur cursor for select myColumn from myTable

open cur

fetch next from cur into @var1

etc, etc

this is much handier:

declare cur cursor for select myColumn from myTable

for rec in cur

print rec.myColumnName

loop

3. detecting the type from table definition

eg:

MyTable has a myColumn nvarchar(10)

a stupid insert procedure would have to declare the paramter as nvarchar(10)

eg: create myProc (@col1 nvarchar(10)) ...

--> create myProce (@col1 MyTable.MyColumn%TYPE)

when the type of myColumn changes there is no need to change the procedure!

anyway, minor changes but they could make my life a bit easier

george sibbald SSC Guru Points: 104210 More actions · Answer 3

This one is very basic and simple but seems a complete no-brainer to me:

the ability to specify who the owner of the jobs will be when creating\amending maintenance plans.

Then you wouldn't have to go through and amend all the job owners afterwards (and every time you amend a plan). That is sooooooo irritating.

---------------------------------------------------------------------

blandry SSCarpal Tunnel Points: 4821 More actions · Answer 4

For me? Simple...

SQL Prompt and SQL Search from Redgate.

I have never understood why these great interface-enhancing, functionality-expanding, and time-saving interface features have never become a base part of SQL Server.

There's no such thing as dumb questions, only poorly thought-out answers...

WI-DBA SSCrazy Points: 2110 More actions · Answer 5

I would like to see greater admin ability at the database level - and the ability to lock that down to the server level. Many app teams want lots of abilities in their specific databases, but even in 2008, you can't give someone bulk insert privs for a DB. Server Admins manage the disk space, etc and then each database can have an admin as well.

My second choice would be able to have SQL run on Linux or some other barebones OS so the server's sole mission is running SQL.

Cheers
http://twitter.com/widba
http://widba.blogspot.com/

BobAtDBS SSCarpal Tunnel Points: 4588 More actions · Answer 6

I think each time someone types "architecting" in an article they should have to write on a blackboard 100 times "architecting something is the same thing as designing something but the word makes me sound cool".

Damn, I hate that unnecessary non-word.

P.S. Your built in spell check flags "architecting" as wrong. It's not just me.

Student of SQL and Golf, Master of Neither

chrisn-585491 SSCoach Points: 16006 More actions · Answer 7

My second choice would be able to have SQL run on Linux or some other barebones OS so the server's sole mission is running SQL.

:rolleyes:

That's a silly request... MS Server has improved over the years and you can tune it to support roles.

Tom257 SSChampion Points: 11543 More actions · Answer 8

I'd like more features on SSMS

Formatting of t-sql - with the ability to alter the formatting rules

Improvements in intellisense - current version is a good start, but suggests too many wrong items

Code snippets

Something to outline/expand statements and transactions - so you can click a +/- next to a statement to select/hide find the end etc.

Search feature to find functions/procs/columns without having to query sys tables manually

Ability to get object defs/create/alter/drop code from t-sql - instead of having to navigate the object browser and right-click or, if thats too much to ask, just type the name of an object, select it and get the object browser to find that object.

And intellisense when connecting to older versions - I now have 2008 - but most of my work is connected to 2005 databases - no intellisense.

webrunner SSC-Dedicated Points: 31711 More actions · Answer 9

I agree with the SSMS requests - especially built-in intellisense and SQL formatting options.

I would also add a request for some visual aids to see how healthy a database is. I know a lot of this depends on circumstances, but it would be neat to hover the cursor over a database server top-level node and see a bar graph or pie chart of used vs. free space on that server's data drive. And if you hover the cursor over a table, show the number of rows in the table. And if a table has an index with greater than a certain amount of fragmentation (or whatever other statistics would be useful), show that table in a different color - a shade of red or something like that. Similarly, it would be helpful to have a kind of top waits report node where you could see the wait types that were most experienced in a given database, possibly with a way to drill down to see what queries were involved.

I'm not saying I want SQL Server to do everything for me, and I know a lot of these things are available in third-party (and expensive) products, but it would be nice for it to tell me things it can already know on its own, to help narrow down possible issues as soon as the database GUI is brought up, if a DBA (say, for example, me :blush:) has not yet gotten to the state of having a lot of these checks automated. SSMS seems like the best place to add these features.

Just my two cents.

Thanks,

webrunner

-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

jn_gray Valued Member Points: 52 More actions · Answer 10

kenneth-910727, I have to totally disagree with your #3 suggestion. One of the main reasons to use stored procedures in application development is that you can decouple the application from any table/db structure changes through that stored procedure. The field names and even types can change, but as long as it's not material, the application can function with just a stored procedure update without changing the interface (how that stored procedure interacts with the app, which is the parameters). But, if you are strongly coupling your parameter type to the table structure, you might as well just use in-line SQL (bite your tongue!!!!) because you've just tightly coupled your application data layer to your database structure again.

As far as wish lists, I'd love to see better intellisense, not necessarily around the DB table/field/whatever values, but the regular syntax, functions, etc.

Steve Jones - SSC Editor SSC Guru Points: 734418 More actions · Answer 11

blandry (4/22/2010)
For me? Simple...
SQL Prompt and SQL Search from Redgate.
I have never understood why these great interface-enhancing, functionality-expanding, and time-saving interface features have never become a base part of SQL Server.

Prompt, or some things it does are in SQL 2008. Arguably not as well implemented as Prompt, but I'm not sure what to do there. Tell MS to license prompt and then tell RG I need a bonus for the suggestion!

kennethje SSC Enthusiast Points: 117 More actions · Answer 12

well,

another reason is security: don't allow direct table access.

with this in mind and the fact that I never put application logic in the database, I find myself often writing (read generating) simple crud procedures.

that's why I'd like to have that possibility on sqlserver (as I have on oracle)

btw: I never said to remove the current option to specify the type

michael.monroe Old Hand Points: 339 More actions · Answer 13

I think the improvements we would like to see depend a lot on what we've been doing recently. Since I have been working quite a bit with Integration Services, I would like to see some serious work put into it. I have a laundry list that seems to grow every day:

1. Improve the performance of XSLT Transforms in XML data sources - especially when you are mapping into multiple tables from a single XML file.

2. Make attributes in the root node accessible in XML data sources. Most XML messages represent a contract with a data supplier or a web service, and I don't have the luxury of having a new root level added to the XML schema, nor do I want to add that new root node in a script task.

3. Provide a facility for importing and exporting mapping metadata to and from an external source.

4. Provide a package-level report or listing of all suspect mappings.

Terry Mott SSC Journeyman Points: 84 More actions · Answer 14

Nested transactions.

I should be able to begin / commit / rollback a transaction in a stored procedure without worrying about whether an upstream procedure has begun a transaction or not. This has been on my wish list since version 4.7(?).

I know you can get clever with savepoints and do conditional stuff based on @@TRANCOUNT. What I'm talking about is the ability to simply begin and commit / rollback a transaction within a procedure and not care if a higher level transaction exists -- if the lower level transaction is rolled back, its changes go away and the higher level transaction can still be committed. If the lower level transaction is committed and the higher level transaction is rolled back, the lower level's changes are rolled back as well.

IIRC, Oracle had this as far back as version 6, maybe before.