Avatar billede fldu Nybegynder
13. april 2012 - 11:13 Der er 14 kommentarer og
1 løsning

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

Nogen der kan hjælpe med en løsning til meget lange stored procedures?

pt samler jeg sp koden i en varchar() men da denne har max=8000 giver det problemer.

Nogen forslag?

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

ALTER PROCEDURE [database].[SP_name]
    @dateFrom char(10),
    @dateTo char(10),
    @ccy varchar(7)
   
AS
declare @sql varchar(8000)
set @sql = ''

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


exec (@sql)
Avatar billede Syska Mester
13. april 2012 - 11:21 #1
VARCHAR(MAX)

mvh
Avatar billede fldu Nybegynder
13. april 2012 - 11:29 #2
det var nemt! smid et svar
Avatar billede Syska Mester
13. april 2012 - 11:35 #3
svar
Avatar billede janus_007 Nybegynder
13. april 2012 - 17:03 #4
fldu, du gør det forkert :)

At bruge dynamisk sql i en sproc er kun absolut nødstilfælde.
Avatar billede fldu Nybegynder
14. april 2012 - 15:43 #5
Det dynamiske i

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

eller variablene?
Avatar billede janus_007 Nybegynder
14. april 2012 - 23:51 #6
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.
Avatar billede arne_v Ekspert
15. april 2012 - 02:55 #7
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)
Avatar billede fldu Nybegynder
16. april 2012 - 12:35 #8
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.
Avatar billede arne_v Ekspert
16. april 2012 - 14:21 #9
Og du kan ikke bare bruge det gamle NULL trick?
Avatar billede fldu Nybegynder
16. april 2012 - 14:29 #10
Jeg ved ikke hvad 'det gamle null trick' er?

Er desuden ret ny i jsp, js...
Avatar billede arne_v Ekspert
16. april 2012 - 14:34 #11
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.
Avatar billede fldu Nybegynder
16. april 2012 - 15:01 #12
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?
Avatar billede arne_v Ekspert
16. april 2012 - 15:48 #13
Grundliggende tror jeg at der er noget som skal splittes op.

200 parametre er hverken god SP eller god app kode.
Avatar billede janus_007 Nybegynder
16. april 2012 - 18:53 #14
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?
Avatar billede arne_v Ekspert
13. maj 2012 - 03:02 #15

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!


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.


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


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.


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.


For systemer hvor sikkerhed er vigtigt bygges sikkerhed ind i alle tiers og layers.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester