stored procedure >8000 tegn - varchar(8000)++

VARCHAR(MAX)

mvh

det var nemt! smid et svar

svar

fldu, du gør det forkert :)

At bruge dynamisk sql i en sproc er kun absolut nødstilfælde.

Det dynamiske i

set @sql + 'something....'
set @sql + 'something....'
.
.
.
.
.
set @sql + 'something....'

eller variablene?

Dine
set @sql :-)

Tanken med en stored procedure er at den compiles og query optimizeren kender query planen i de fleste tilfælde, men når indholdet er dynamisk ryger den idé ligesom lidt i vasken.

Nu ved jeg ikke hvorfra du kalder din sproc?, men hvis du har mulighed for det, så er du 100xbedre tjent med at skrive din sql i koden/ datalaget eller hvad du har.

Nødstilfælde dækker eks.vis brug af sprocs i programmer hvor man ikke har den store mulighed for at skrive kode.

Der vist mange som vaelger SP fordi den compilede query plan skulle give bedre performance, men det er en elendig grund - det er en myte. Der er ikke nogen naevnevaerdig performance forbedring (fra SQLServer 7.0 og frem hvor SQLServer begyndte at cache andre query plans end SP!).

Der er stadig visse gode grunde til at bruge SP:
- der er maalbare performance forbedringer hvis SP udfoerer flere SQL saetninger p.g.a de faerre roundtrips mellem app og database
- logik i SP's kan bruges fra forskelleige teknologier d.v.a. at man kan udnytte dem fra C#, Java og COBOL
- de kan forbedre database sikkerheden, da en SP kan have adgang til data som det brugte brugernavn ikke har adgang til
- de kan fungere som et public API for databasen som database arkitekter og DBA kan bruge til at aendre i databasen uden at paavirke apps

(generelt vil jeg dog stadig fraaraade brug af SP, da de goer det uhyggeligt dyrt at skifte database leverandoer)

Formålet er en hjemmeside med en masse kriterier for hvilke data på databasen der skal bruges. Jeg bruger Java, jsp, js, og kunne måske lave sproc teksten i denne kode, men da forskellige brugere har forskellige rettigheder til data tror jeg det er nemmest at have det hele i stored procedures.

Og du kan ikke bare bruge det gamle NULL trick?

Jeg ved ikke hvad 'det gamle null trick' er?

Er desuden ret ny i jsp, js...

SELECT ... WHERE ISNULL(@argf1,f1)=f1 AND ISNULL(@argf2,f2)=f2 AND ISNULL(@argf3,f3)=f3

Hvis brueren saa kun angiver f2, saa sender du NULL over for f1 og f3.

men hvis argumenterne kan have forskellige værdier:

SELECT
  if @arg1 =something then
    set @sql + 'something....'
  elseif @arg1 =something else then
    set @sql + 'something else....'
  elseif
  .
  .
  .
  end if
FROM...

WHERE
  if @arg1 =something then
    set @sql + 'something....'
  elseif @arg1 =something else then
    set @sql + 'something else....'
  elseif
  .
  .
  .
  end if

Group by and order by
  if @arg1 =something then
    set @sql + 'something....'
  elseif @arg1 =something else then
    set @sql + 'something else....'
  elseif
  .
  .
  .
  end if

og dermed den dynamiske sql sætning.

ellers skal lade hver mulighed være sin egen variabel og dermed skal jeg tage 200+ variable med i min sproc?

koster det ikke på performance at sende lange og mange argumenter med til sporc?

Grundliggende tror jeg at der er noget som skal splittes op.

200 parametre er hverken god SP eller god app kode.

Først og fremmest er det en myte at det er en myte, jeg har mange gange siddet med sprocs der performede væsentligt dårligere end skrevet sql.
Når det så er sagt så er det vi taler om dynamisk sql, her vil overheadet være væsentligt mindre end en almindelig sproc, hvilket også var derfor jeg anbefalede at skrive sql'en direkte i koden.

Det er til gengæld en myte at der skulle sidde nogle gamle nisser og ændre i dem uden at udvikleren er involveret, det var sådan i gamle dage.. dengang det hed Oracle og Unix og det hele var meget ærefuldt, tiderne har ændret sig og det ved du godt Arne!

Hvis mange forskellige platforme skal tilgå den samme logik er man ovre i en helt anden løsning, n-tier med webservicelag evt.

Mht. logik i sprocs så kan man altid argumentere for at en flad arkitektur konceptuelt vil benytte logik i sprocs, men hvis du blander både applicationlogik og db-logik kan det hurtigt blive svært, man skal ihvertfald holde tungen lige i munden og kende den præcise årsag.

Sikkerhed styres i applikationen, det er uhyrligt svært at overføre windows credentials igennem eks.vis en webapp til db'en, en opgave de fleste opgiver hurtigt igen.

Der er noget at hente i roundtrips, men igen... db-operationer skal være så små som muligt.

Når alt det så er sagt og nogle stadig sidder her og uenige med mine kloge ord, så vil jeg bede dem om at huske på at man aldrig skal udvikle med en masse hvis'er og fremtidsplaner, men derimod udvikle koden så robust og simpel som muligt og stadig med mulighed for udvidelse.

I min optik er en Stored Procedure i 90% af tilfældene noget der skal kaldes fra jobagenten på serveren og her kommer de virkelig til deres ret.

Når vi nu igen igen har målt vores tissemænd, kan vi hjælpe fldu, ik ;-)
------------------------------------------

fldu, du skal stadig løse det i din applikation :) Det giver en langt flottere sql, som du rent faktisk kan læse og eksekvere igennem Management Studio og tilmed måske optimere. En sql/ sproc med et hav af dynamiske variabler eller hundredevis null-tricks er umulig at forstå og giver kun hovedbrud efterfølgende.

K.I.S.S

Hvordan styrer du adgangsbegrænsningen forresten?

Jeg ved at Gartner estimerede Oracle's markeds andel af database markedet for 2011 til 48%.

Saa nej jeg  ved ikke noget om at Oracle var noget man brugte i gamle dage.



Det er et alternativ men koster altsaa et ekstra tier og kraever at alle platformene er egnede til at fungere som web service consumere.

Det er ikke altid en mulighed.



For systemer hvor sikkerhed er vigtigt bygges sikkerhed ind i alle tiers og layers.