°Junoland.de HOME     www.Junoland.de     Valid HTML 4.01 Transitional     (c) Copyright 2008 °Andreas Klotz, Cologne, Germany [upd.Oct.2008]     AKL@Junoland.de

Stored Procedures?

Inconvenient and sometimes not as fast as they are supposed to be

Why Stored Procedures?

After 3 monthes of writing Stored Procedues (SP) to my last enterprise project, I can't say that they are that good. I'm glad that I have learned to apply this SQLserver programming language, anyway. For before this, people told me that I have to get more experienced, when I tried to discuss the pros and the cons; now I am not yet an regular expert, but I guess I have seen enough to evaluate it in comparision to other approaches.

Sorry, folks, this I could never understand before, nor do I understand it now.
Eventually, the design of the Stored Procedure-Language (I mean T-SQl of MS-SQLServer) is as primitive as the first BASIC idioms. For example, you have to save intermediate results physically on the server, because there is not a thing like an Array. I've tried to write a CSV-file on the server (funny idea, you might say, but i had to do it for some strange demand of people that need the CSV-way anyhow) - and this takes a hundred times more time than doing it on a client PC with streaming technics.
You have to write your sourcecode in a text-editor-window whithout autocompletion, syntax-highlighting and other IDE-sugar.

But why do the smart professional developer use this language at all?

- I don't know!
May be, it is easier to write loops and do it step by step than doing it by pure brain breaking SQL. But this you could do with much more ease and convenience at your personal computer in the IDE of your choice (Visual Studio (LINQ!) / Eclipse).

May be experts are often using that language while doing server-maintainance-jobs, migratings, upgradings etc. Most of scripts to make such batch-processes are written in TSQL. So they might use this language for all purposes on SQlServer, simply because there are used to it.