[ALG] zeg nee tegen Stored Procedures *

[wasigh]

Als programmeur en mens ben ik een man van principes. Daarnaast ben ik purist. Ik wil niet zomaar programma's schrijven. Nee, ik wil mooie, handige, goed onderhoudbare programma's schrijven. Daarom schrijf ik de programma's met 1 belangrijk principe:
KISS! Keep It Simple Stupid. En probeer ik niet te schrijven met: "whatever get's the job done" in mijn achterhoofd.

Voor mijn werk bouw ik websites ik doe dat niet alleen ik heb ook nog collega's en deze collaga's houden er van om stored procedures te gebruiken. Vanwege de snelheid van executie en snelheid van schrijven. Ik ben hier echter helemaal tegen.

De taak van een database is het opslaan en beschikbaar maken van gegevens en de integreteit van deze data garanderen. Alle bewerkingen met deze data horen niet in een database thuis maar in code zegt de purist in me, Verder vindt ik dat je alle bewerkingen op data op 1 plek moet houden zodat het makkelijk te onderhouden blijft en dat je het ook makkelijker in een versie beheer pakket kunt gebruiken. Mede om die reden vindt ik ook het gebruik van DTS packages niet geschikt. Data bewerken, maitjes sturen, FTP-en dat zijn dingen die een programma moeten doen en niet het DMS. Mijn laatste argument tegen StoPro's en DTS is het moeizame onderhoud. Wanneer er wijzigingen zijn in de logica of database moet men en de code en de database wijzigen, testen en debuggen. Dit alles weegt mijn inziens niet op tegen de eventuele tijdswinst.

Daarom roep ik iedereen op: Zeg nee tegen stored procedures!

[gorgi_19]

Eventjes wat extra informatie rondom deze discussie:

Rob Howard, voormalig programma manager van ASP.Net - team
http://weblogs.asp.net/rhoward/archive/2003/11/17/38095.aspx

Dit stuk is vervolgens flink bekritiseert door Frans Bouma, maker van oa. de O/R mapper LLBLGen Pro
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Een hoop argumenten voor en tegen SP's worden hierin (en de hieropvolgende 'reactie-blogs' van ze) genoemd

[P_de_B]

De tijdswinst in ook nog een nihil als je parameterized queries gebruikt.

DTS packages vind ik nog wel handig, ik gebruik een aantal packages om externe data te laden, dat gaat via een DTS package in mijn ogen beter dan via een programma.

[foske]

maar ik ben eigenlijk ook wel benieuwd naar jouw mening Gorgi

[Verwijderd]

Ik wil alleen even opmerken dat de snelheid winst echt gigantisch kan zijn. Zeker als je een query zeer regelmatig gebruikt. Maar los daarvan kan het zeer veel tijd winst geven wanneer de database server niet op de computer staat die de gegevens op vraagt. Want je kunt dan door logica in SP's veel dataverkeer tegen gaan.

Ik moet er zelf niet aan denken dat ik geen SP's meer zou mogen gebruiken...

[Verwijderd]

ik heb ze nooit echt gebruikt.

Voor de rest schijnt Dynamic SQL ook vrijwel hetzelfde te kunnen voor zover ik weet.

[ Voor 34% gewijzigd door Verwijderd op 29-08-2004 18:39 ]

[wasigh]

Verwijderd schreef op 29 augustus 2004 @ 18:30:
Ik wil alleen even opmerken dat de snelheid winst echt gigantisch kan zijn. Zeker als je een query zeer regelmatig gebruikt. Maar los daarvan kan het zeer veel tijd winst geven wanneer de database server niet op de computer staat die de gegevens op vraagt. Want je kunt dan door logica in SP's veel dataverkeer tegen gaan.

Ik moet er zelf niet aan denken dat ik geen SP's meer zou mogen gebruiken...

Maar volgens mijn kun je dat ook dat door goede querie's en views te gebruiken. Snelheid vindt ik niet eens zo'n interressant punt. Het gaat er mij principieel om dat een database niet bedoeld is voor het implementeren van logica en dat je het daarom niet moet doen. Database is voor data en het programma is voor de bewerkingen op die data == Simple

[EfBe]

They're bad, m'kay!

Stored procedures zijn alleen handig als je veel data moet processen met lange routines. Dit levert voordeel op, omdat je de routine op de server executeert en dus niet de data helemaal overtrekt naar de client. Echter, niets houd je tegen die query te genereren op de client en parametrized te sturen naar de server.

[Verwijderd]

wasigh schreef op 29 augustus 2004 @ 18:35:
Maar volgens mijn kun je dat ook dat door goede querie's en views te gebruiken.

Nou views zijn toch wel wat beperkter dan SP's en is het vaak voldoende, maar af en toe kan het gebruik van SP's je zoveel tijd en moeite besparen dat het eigenlijk zonde zou zijn om het niet te gebruiken.

Snelheid vindt ik niet eens zo'n interressant punt.

De applicaties die ik meestal ontwikkel zijn vaak voorzien van een zeer grote database en dan is het simpelweg niet acceptabel wanneer het werken met de UI traag is.

Het gaat er mij principieel om dat een database niet bedoeld is voor het implementeren van logica en dat je het daarom niet moet doen. Database is voor data en het programma is voor de bewerkingen op die data == Simple

Dat klopt wel, maar het is vaak zo dat het mooiste niet het beste is. Dus hoe ranzig het ook is om de database van logica te voorzien is het vaak gewoon zeer logisch en zijn ze daarvoor ook ooit geintroduceerd.

[misfire]

Stored procedures bieden geen snelheidswinst op moderne databases, omdat alle SQL code aan dezelfde caching en optimalisatie wordt onderworpen. Het enige verschil in executietijd is de hoeveelheid data over de lijn: bij een stored procedure hoef je alleen de naam van de proc te sturen, custom SQL stuurt de hele SQL string. Dit verschil is echter verwaarloosbaar in de totale roundtrip.

Stored procedures zijn met name interessant voor DBA's. Een DBA is vaak niet bekend in de applicatie taal en kan in de SQL precies zien wat er met de database gebeurt. Door alleen rechten op de procs te geven kan er geen "onbekende" SQL op de database worden losgelaten. DBA's vinden dit heel handig.

Stored procs hoeven geen onderhoudsprobleem te betekenen. Een database aanpassing is zowieso een onderhoudsprobleem. Als je automatische SQL scripts gebruikt voor CRUD operaties, dan kun je ook automatisch stored procs genereren en je hebt een vergelijkbaar onderhoudsscenario. Als meerdere applicaties gebruik maken van dezelfde database dan hoef je de SQL code maar op één plek te onderhouden en heb je in principe onderhoudswinst, maar je kunt natuurlijk ook applicatie componenten hergebruiken om hetzelfde effect te bereiken.

Ik heb zelf een paar applicaties gemaakt met stored procedures en zonder en mij maakt het eigenlijk niet zo veel uit. Met tooltjes als CodeSmith kun je vrij makkelijk de triviale procs laten genereren. Echt *nodig* vind ik stored procs ook niet. Op de applicatielaag wil je zo veel mogelijk in objecten denken, en een OR mapper biedt dan uitkomst. Maar een OR mapper vs stored procs is volgens mij weer een heel andere discussie...

[whoami]

Stored Procedures; mjah. Ik zeg niet nee, en ik zeg ook niet altijd ja.

Ze zijn handig, maar niet zaligmaken.
IMO hoort business logic niet thuis in een SP (en wel om de redenen die wasigh al aanhaalde), maar in sommige gevallen kunnen ze toch verdomd handig zijn of snelheidswinst opleveren (bij data-intensieve taken). Dan zou ik toch overwegen om een SP te gebruiken.
Op m'n vorige werk gebruikten we intensief SP's, en dat leverde in sommige gevallen toch serieuze snelheidswinsten op.

Echter, hoe sta je dan ook tov triggers? Ik zou zelf ook geen business logic in een trigger steken, maar een trigger kan toch ook handig zijn om bv. historische data ergens te ga gaan opslaan.

Ik dacht dat ik trouwens al eens een soortgelijk topic geopend had.... ff zoeken.

edit:
Blijkbaar niet.... Althans, ik vind het niet terug. 'k Zal gedroomd hebben ofzo

misfire schreef op 29 augustus 2004 @ 18:54:
Stored procedures bieden geen snelheidswinst op moderne databases, omdat alle SQL code aan dezelfde caching en optimalisatie wordt onderworpen

Dat vind ik dus een beetje kort door de bocht. Voor gewone queries is dit idd min of meer waar, maar als je nu een bepaalde data-intensieve procedure hebt, dan kan je er zeker voordeel mee halen door deze als SP te schrijven.

[ Voor 30% gewijzigd door whoami op 29-08-2004 19:28 ]

[alienfruit]

Zelf maak ik niet zo vaak gebruik van stored procedures etc. Triggers daarin tegen is wel handig, bijv. voor versiebeheer e.d. Maar verder ben ik meer van het generen van de SQL queries in het programma zelf, het liefst nog gegeneerd door de DAL, zodat je zonder problemen van database kan overstappen. Hiervoor gebruik ik zelf DataAbstracts voor (www.remobjects.com) werkt gemakkelijk en mooi.

[Olaf van der Spek]

Maar soms lijken SPs me wel handig, vooral als je dezelfde DB vanuit meerdere talen benaderd. Dan moet je of logica dubbel in meerdere talen schrijven, SPs gebruiken of een layer bovenop de DB bouwen, maar dat laatste is volgens mij nogal veel werk om vanuit meerdere talen dan weer makkelijk te benaderen.

[misfire]

Dat vind ik dus een beetje kort door de bocht. Voor gewone queries is dit idd min of meer waar, maar als je nu een bepaalde data-intensieve procedure hebt, dan kan je er zeker voordeel mee halen door deze als SP te schrijven.

Of je SQL code in een stored procedure stopt of vanaf de applicatie stuurt maakt niet uit voor performance. Het maakt natuurlijk wel uit of je bepaalde dingen in SQL op de databaselaag oplost of op de applicatielaag, maar daar hoef je geen stored procs voor te gebruiken.

[Olaf van der Spek]

misfire schreef op 29 augustus 2004 @ 19:59:
Of je SQL code in een stored procedure stopt of vanaf de applicatie stuurt maakt niet uit voor performance. Het maakt natuurlijk wel uit of je bepaalde dingen in SQL op de databaselaag oplost of op de applicatielaag, maar daar hoef je geen stored procs voor te gebruiken.

In een SP kun je toch veel meer dan in SQL of niet?

[whoami]

misfire schreef op 29 augustus 2004 @ 19:59:
[...]
Of je SQL code in een stored procedure stopt of vanaf de applicatie stuurt maakt niet uit voor performance.

Dat weet ik ook wel, en dat zei ik ook niet.

Het maakt natuurlijk wel uit of je bepaalde dingen in SQL op de databaselaag oplost of op de applicatielaag, maar daar hoef je geen stored procs voor te gebruiken.

Wat bedoel je dan?

Ik had het over data-centrische taken. Procedures die heel intensief met data uit de DB werken schrijf je imo beter in een SP om zo roundtrips te gaan besparen.

Dingen op een pure manier oplossen is mooi, maar niet altijd de beste manier.

[ Voor 7% gewijzigd door whoami op 29-08-2004 20:13 ]

[EfBe]

misfire schreef op 29 augustus 2004 @ 18:54:
Stored procedures zijn met name interessant voor DBA's. Een DBA is vaak niet bekend in de applicatie taal en kan in de SQL precies zien wat er met de database gebeurt. Door alleen rechten op de procs te geven kan er geen "onbekende" SQL op de database worden losgelaten. DBA's vinden dit heel handig.

No offence, maar: lekker belangrijk wat die DBA vindt. Het punt is: de DBA is de beheerder van de database, maar niet de ontwikkelaar van de API. Tevaak wordt de DBA de persoon die bepaalt op welke wijze er met de data wordt omgegaan in een applicatie, terwijl de DBA een ondergeschikte rol zou moeten spelen.

Stored procs hoeven geen onderhoudsprobleem te betekenen. Een database aanpassing is zowieso een onderhoudsprobleem. Als je automatische SQL scripts gebruikt voor CRUD operaties, dan kun je ook automatisch stored procs genereren en je hebt een vergelijkbaar onderhoudsscenario. Als meerdere applicaties gebruik maken van dezelfde database dan hoef je de SQL code maar op één plek te onderhouden en heb je in principe onderhoudswinst, maar je kunt natuurlijk ook applicatie componenten hergebruiken om hetzelfde effect te bereiken.

Dit is onzin. Als jouw tabel 5 keer wijzigt, heb jij 5 versies van je proc in de db staan. Je moet dus elke keer de procs weghalen die je hebt gegenereerd. Dit kan lastig zijn. Een procedure heeft verder als nadeel dat het een static interface heeft: je kunt niet even een filter aanpassen voor een specifieke situatie. Uiteraard komen nu de mensen die met nullable parameters dit op gaan lossen maar dit is maar schijn: je procedure wordt erg ingewikkeld daardoor en veelal veel trager.

Dit houdt dus in dat je procedure logica in feite onder meerdere interfaces wordt opgeslagen: filter on A, filter on A and B, filter on A and B + C etc. etc. Een ontwikkelaar die in een BL component een filtered blokje data nodig heeft, moet dat DAAR bepalen, niet via het aanmaken van een proc, of erger: moeten debateren met een DBA omdat de DBA niet een proc wil aanmaken want dat wordt een zootje. Wijzigt de logica van het BL component, dan is dat dus alleen een wijziging van het BL component, niet ergens anders. Wanneer je een proc gebruikt, moet je goed documenteren waar deze proc nog meer gebruikt wordt.

Met name dat laatste is funest. Het is niet zo moeilijk dat te documenteren, dat weet een 3-jarig kind. Het probleem begint wanneer het systeem 2 jaar in productie is en er 3 clients op draaien. In die 2 jaar zijn er wellicht legio wijzigingen geweest. Houdt iedereen die wijzigingen bij in de documentatie? Ik moet de 1e organisatie nog tegenkomen die dat doet.

Op de applicatielaag wil je zo veel mogelijk in objecten denken, en een OR mapper biedt dan uitkomst. Maar een OR mapper vs stored procs is volgens mij weer een heel andere discussie...

Ja, die worden elke maand gevoerd, op de meest vage fora. Het is wel grappig om te lezen vaak dat de mensen die pro-procs zijn zich gedragen als, (no offence), streng-gelovigen: zonder enig argument claimen dat X en Y waar is. Ach ja, het is leuk tijdverdrijf, alleen soms wordt het wat vervelend

[EfBe]

OlafvdSpek schreef op 29 augustus 2004 @ 20:00:
[...]
In een SP kun je toch veel meer dan in SQL of niet?

Nee. Jij kunt je volledige sqlserver bak beheren met louter ADO.NET Procedures zijn niets anders dan batches met SQL statements.

[zeroxcool]

Beetje lastige keuze inderdaad. Zoals EfBe al aangeeft zijn ze voor data intensieve werkzaamheden handig qua performance winst. Verders gebruik ik ze eigenlijk nooit, aangezien je ze makkelijk met 'in-code' functions kunt vervangen.

Overigens vind ik talen om standaard SQL heen sowieso nogal onzin. Dingen als triggers zijn wel handig, maar zeker ook weer niet broodnodig. Ook triggers kun je in een 'in-code' functie zetten.

[Sjaaky]

whoami schreef op 29 augustus 2004 @ 19:21:
Ik dacht dat ik trouwens al eens een soortgelijk topic geopend had.... ff zoeken.

[rml][ Alg] Business Logic in de database[/rml] ?

[Verwijderd]

Ik maak me zelf ook schuldig aan veel gebruik van stored procedures, het is er zeg maar ingeslopen en op uitzonderingen na moet ik eerlijk bekennen geen reden te hebben waarom ik ze gebruik.

Voor bepaalde zaken zijn ze gewoon ranzig zo veel sneller, zoals recursieve taken. Ik zou die vanuit mijn applicatie moeten doen, en bijv. 50x een database connectie aanroepen, een call maken, data versturen, data ontvangen, etc. Nu kan ik in mijn applicatie 1x deze routine doen en de overige recursieve aanroepen worden via de stored procedure afgehandeld.

Of full text search taken, die doe ik ook via stored procedures. De voordelen die ik altijd heb meegekregen waren cached execution plans (maar die zijn dus ook niet altijd optimaal of op zijn snelst en afhankelijk van je input). Er was nog meer, maar het daagt me even niet

Ik zag in de blog van Frans ook zijn opmerking staan van, jongens doe nu geen zaken als
str = "select * from table where id = " + id

Maar gebruik dynamic queries, maar wat moet ik verstaan onder dynamic queries? Heeft iemand daar goede voorbeelden van voor me?

[ Voor 15% gewijzigd door Verwijderd op 29-08-2004 21:12 ]

[Not Pingu]

Hebben we het hier dan over gebruik van de speciale functies van SPROCS, of specifiek over het opslaan van SQL queries als SPROC ipv. platte tekst?

Ik ben het met Scott Galloway eens dat dit niet iets is waar je binair over moet denken. Ik heb op FBouma's blog ooit eens een stukje tekst met de volgende strekking gelezen:
"Vroeger was ik fan van Sprocs en gebruikte ik altijd Sprocs. Tegenwoordig ben ik fan van Dynamic SQL en gebruik ik altijd Dynamic SQL"
Je zult dat vast wel doen om 'de discussie aan te zwengelen' of meer van die bla, maar ik vind het niet erg professioneel om zo zwart-wit tegen zaken aan te kijken.

Mijn ervaring is dat Sprocs en stored queries in Access heel fijn zijn als je een applicatie maakt met een hoge distributiegraad, zoals een forumsysteem ofzo, en je wilt meerdere DBMS'en ondersteunen. Het is dan heel fijn om de DBMS-specifieke queries ook in het DBMS zelf te kunnen opslaan zodat je in je DAL alleen maar de namen van de sprocs hoeft aan te roepen.
Dan hoef je in je Access database maar een aantal queries neer te plempen en een setup-scriptje schrijven voor SQL Server en dan heb je de SQL mooi in het DBMS waar het bij hoort. Dat maakt het voor je gebruikers meteen ietsje makkelijker om je systeem te installeren.

Maar het is lastig te beheren, dat wel. Ik ben nu bezig met een registratiesysteem voor de organisatie van een hardloopwedstrijd in het dorp (vrijdag is het zover!) en ik maak daarin gebruik van MSDE met SPROCS en hoewel het een snelheidswinst oplevert is het een hel om iedere keer nieuwe sprocs over te zetten van mijn ontwikkel-PC naar mijn server. Je kunt wel iedere keer een SQL script schrijven maar dat is ook geen pretje als je veel moet updaten.


Overigens wordt er veel gesproken over de theoretische verschillen in snelheid tussen sprocs en dynamic SQL. Waarom draait iemand niet gewoon een paar benchmarks, dan heb je gelijk enige concrete aanwijzingen van welke van de twee oplossingen het snelst is in welke situatie?

Verwijderd schreef op 29 augustus 2004 @ 20:45:

Ik zag in de blog van Frans ook zijn opmerking staan van, jongens doe nu geen zaken als
str = "select * from table where id = " + id

Maar gebruik dynamic queries, maar wat moet ik verstaan onder dynamic queries? Heeft iemand daar goede voorbeelden van voor me?

Gezien het bad-practice voorbeeld denk ik dat ie het over parametrized queries heeft.

[ Voor 52% gewijzigd door Not Pingu op 29-08-2004 21:38 ]

[gorgi_19]

Mijn ervaring is dat Sprocs en stored queries in Access heel fijn zijn als je een applicatie maakt met een hoge distributiegraad, zoals een forumsysteem ofzo, en je wilt meerdere DBMS'en ondersteunen

Dit snap ik niet Je kan dit toch ook perfect in je applicatie oplossen? Daar hebben ze hele mooie patterns voor uitgevonden waarbij je het heel netjes voor elkaar kan krijgen. Neem bijvoorbeeld asp.net forums; daar hebben ze een aparte dll gebakken, welke als enige taak heeft om connectie te maken met de database. Je hoeft in principe dus geen enkele SPROC / whatever te gebruiken; je levert een apart bestandje mee waarin alles in staat. Dit roep je aan door middel van een configuratiebestand; dit kan allemaal geregeld worden bij installatie.

Maar het is lastig te beheren, dat wel. Ik ben nu bezig met een registratiesysteem voor de organisatie van een hardloopwedstrijd in het dorp (vrijdag is het zover!) en ik maak daarin gebruik van MSDE met SPROCS en hoewel het een snelheidswinst oplevert

Snelheidswinst t.o.v. wat? Het gros van de SP's zal nauwelijks snelheidswinst opleveren t.o.v. parametrized queries. Sowieso blijf je bezig met SP's schrijven voor iedere kleine afwijking van een query.

Sowieso: Drop all je SP's; Generate een new SQL Script in Enterprise Managers; selecteer hierbij alleen je SP's en je probleem hoort in principe ook opgelost te zijn. Alle oude SP's mogen immers verwijderd worden.

Waarom draait iemand niet gewoon een paar benchmarks, dan heb je gelijk enige concrete aanwijzingen van welke van de twee oplossingen het snelst is in welke situatie?

Die zijn gedraaid; de verschillen waren marginaal, omdat de execution plans van beide gecached waren.

[ Voor 10% gewijzigd door gorgi_19 op 29-08-2004 21:46 ]

[alienfruit]

Mijn ervaring is dat Sprocs en stored queries in Access heel fijn zijn als je een applicatie maakt met een hoge distributiegraad, zoals een forumsysteem ofzo, en je wilt meerdere DBMS'en ondersteunen. Het is dan heel fijn om de DBMS-specifieke queries ook in het DBMS zelf te kunnen opslaan zodat je in je DAL alleen maar de namen van de sprocs hoeft aan te roepen.

Mijn DAL gegeneert dus de DBMS-specifieke queries en zelfs geoptimaliseert voor die DBMS. Natuurlijk moet de DAL wel een "add-on" hebben voor de DBMS, maar ja dat blijf je altijd hebben

[Verwijderd]

Ik zelf maak misschien wel teveel gebruik van stored procedures, maar wat ik zelf wel een handige toepassing vind van sp's is het invoeren van records. Ik heb in een eerder project van mij veel gebruik gemaakt van sp's als deze:

SQL:

INSERT INTO tabel VALUES (@p1, @p2)

SELECT @@IDENTITY

Hierdoor hoef je niet weer een nieuwe query te versturen om het nieuwe ID op te vragen alleen is het nadeel al die parameters....

[Not Pingu]

gorgi_19 schreef op 29 augustus 2004 @ 21:41:
[...]

Dit snap ik niet Je kan dit toch ook perfect in je applicatie oplossen? Daar hebben ze hele mooie patterns voor uitgevonden waarbij je het heel netjes voor elkaar kan krijgen. Neem bijvoorbeeld asp.net forums; daar hebben ze een aparte dll gebakken, welke als enige taak heeft om connectie te maken met de database. Je hoeft in principe dus geen enkele SPROC / whatever te gebruiken; je levert een apart bestandje mee waarin alles in staat. Dit roep je aan door middel van een configuratiebestand; dit kan allemaal geregeld worden bij installatie.

Dat aparte bestandje doet het em dus: ik wil niet voor elk DBMS een aparte DAL implementatie te hoeven schrijven.
Ik maak gebruik van een soort DatabaseHelper _{(niet volgens het Factory pattern oid want eerlijkgezegd ben ik half-n00b als het op complexe dingen aankomt, ik heb ASP.Net ook niet op school geleerd maar ben er zelf ingedoken)} die afhankelijk van het geselecteerde type DBMS danwel een Oledb- danwel een SqlConnection etc. maakt en zo ofwel simpele queries kan uitvoeren onafhankelijk van het DBMS, ofwel stored procedures kan aanroepen als het om ingewikkelde SQL gaat en je niet dezelfde SQL aan verschillende DBMS' kan voeren.

In dat geval wil ik die SQL absoluut niet in mijn applicatie hebben, maar lijkt mij het DBMS de juiste plaats om die queries op te slaan. Maar dat kan misschien mijn denkfout zijn

[gorgi_19]

Verwijderd schreef op 29 augustus 2004 @ 21:55:
Ik zelf maak misschien wel teveel gebruik van stored procedures, maar wat ik zelf wel een handige toepassing vind van sp's is het invoeren van records. Ik heb in een eerder project van mij veel gebruik gemaakt van sp's als deze:

SQL:

INSERT INTO tabel VALUES (@p1, @p2)

SELECT @@IDENTITY

Hierdoor hoef je niet weer een nieuwe query te versturen om het nieuwe ID op te vragen alleen is het nadeel al die parameters....

SQL:

Insert INTO TabelNaam (Kolom1, Kolom2) Values (@Kolom1, @Kolom2); Select @@Identity

zoiets?

[ Voor 70% gewijzigd door gorgi_19 op 29-08-2004 22:02 ]

[gorgi_19]

Dat aparte bestandje doet het em dus: ik wil niet voor elk DBMS een aparte DAL implementatie te hoeven schrijven.

Dat doe je nu toch ook? Je schrijft voor iedere applicatie nu ook eigen SQL Scripts; je slaat deze alleen op in SP's of stored queries. Een losse dll lijkt me dan ook weinig kwaad kunnen.

Compleet mixen; overal SQL statements door je hele applicatie heen plaatsen, ben ik met je eens dat dat niet netjes is. Alles gecentraliseerd opslaan in 1 bestand heb ik weinig problemen mee.

[ Voor 24% gewijzigd door gorgi_19 op 29-08-2004 22:04 ]

[Verwijderd]

Je hebt gelijk, maar volgens mij wordt dat lastig als je meerder tabellen moet inserten...

[whoami]

Ik vind eigenlijk dat er nogal veel heisa rond gemaakt wordt.
De een vind SP's prettiger werken, de andere queries in de app-code zelf. Ik moet eigenlijk eerlijk gezegd zeggen dat ik geen specifieke voorkeur heb. Meestal gebruik ik de 2, afhankelijk van de taken die moeten uitgevoerd worden, en de 'guidelines / policies' van het bedrijf.
SP's hebben IMHO niet echt veel nadelen tov queries; het grootste nadeel dat ik me nu kan indenken is dat je niet echt een built-in version support hebt.

[gorgi_19]

Verwijderd schreef op 29 augustus 2004 @ 22:04:
Je hebt gelijk, maar volgens mij wordt dat lastig als je meerder tabellen moet inserten...

Ook dat kan je scheiden dmv ; Ik zeg trouwens niet dat je nooit sp's moet gebruiken. sp's niet per definitie het antwoord is op alle problemen en hoeven ook niet te allen tijde gebruikt te worden.

Voor simpele CRUD-statements zal in de meeste gevallen een parametrized query voldoen en je ook nog een stuk extra flexibiliteit geven.

Oftewel; per geval bekijken.

[ Voor 4% gewijzigd door gorgi_19 op 29-08-2004 22:08 ]

[whoami]

Ik vind vooral voor select-statements parametrized queries interessanter dan SP's, en dan wel om de flexibiliteit.

[Verwijderd]

Maar in principe zou bijv. mijn onderstaande stored procedure dus een goed voorbeeld zijn van bad practice. Immers gebruik ik if end if constructies, case constructies en zo heb ik er nog meer staan. Dit zijn dus stored procedures die keer op keer opnieuw moeten worden bepaald door SQL Server? .. is dat correct?

Ja hij is lang

code:

SET QUOTED_IDENTIFIER ON 
GO
SET ANSI_NULLS ON 
GO



-- Code     : UP002
-- Functie  : Retrieves the content of a webpage
------------------------------------------------------------------------------
ALTER        PROCEDURE dbo.upu_Instance_PageContent
    @PageID             int,
    @ObjectType         tinyint = 0,
    @Status             tinyint = 2,
    @Detail             tinyint = 2,
    @PositionNumber     int = 0,
    @UserID             int = 0
AS
-- Initialiseren omgeving
SET NOCOUNT ON
-- Variabelen
DECLARE @lError                 int
DECLARE @lToday                 datetime
-- 
SELECT  @lToday = GETDATE ()
-- Code
-- Page resultset

-- detail 1 = verkrijg alle content van alleen pageid en niet de children
IF (@Detail = 1) BEGIN
print 'detail = 1'
    IF (@Status = dbo.fnd_Instance_Status_Published ()) BEGIN
    print 'status = published'
        SELECT  PageID = P.InstanceID,
                ObjectType = OBJ.Type,
                OBJ.ObjectName,
                P.Label,
                PC.Data,
                PropertyLabel = PROP.Label,
                P.Version,
                P.LastVersion,
                V.Status, -- was P.Status
                V.VersionID,
                V.VersionDate,
                P.StartDateTime,
                P.EndDateTime,
                IsLastVersionPublished = CASE
                                            WHEN (P.Version = P.LastVersion) THEN 1
                                            ELSE 0
                                        END
        FROM    dbo.Instance P
        JOIN    dbo.Content PC          ON (PC.InstanceID = P.InstanceID)
        JOIN    dbo.Version V           ON ((V.InstanceID = P.InstanceID) AND (V.Version = P.Version))
        JOIN    dbo.Property PROP       ON (PROP.PropertyID = PC.PropertyID)
        JOIN    dbo.Object OBJ          ON (OBJ.ObjectID = P.ObjectID)
        WHERE   (P.InstanceID = @PageID)
        AND     ((1 = 0)
                OR (P.InstanceID NOT IN (   SELECT  JI.InstanceID_1
                                            -- 1 = Pagina, 2 = Gebruikersgroep
                                            FROM    dbo.JoinInstance JI
                                            -- Gebruikersgroep
                                            JOIN    dbo.Instance I_UG       ON (I_UG.InstanceID = JI.InstanceID_2)
                                            JOIN    dbo.Object O_UG         ON ((O_UG.ObjectID = I_UG.ObjectID)
                                                                                AND (O_UG.Type = dbo.fnd_Object_Type_Gebruikersgroep ()))
                                        ))
                OR (P.InstanceID IN (       SELECT  JI.InstanceID_1
                                            -- 1 = Pagina, 2 = Gebruikersgroep
                                            FROM    dbo.JoinInstance JI
                                            JOIN    dbo.Instance I_UG       ON (I_UG.InstanceID = JI.InstanceID_2)
                                            JOIN    dbo.Object O_UG         ON ((O_UG.ObjectID = I_UG.ObjectID)
                                                                                AND (O_UG.Type = dbo.fnd_Object_Type_Gebruikersgroep ()))
                                            -- 1 = Gebruikersgroep, 2 = Gebruiker
                                            JOIN    dbo.JoinInstance JI_B   ON (JI_B.InstanceID_1 = JI.InstanceID_2)
                                            JOIN    dbo.Instance I_U        ON (I_U.InstanceID = JI_B.InstanceID_2)
                                            JOIN    dbo.Object O_U          ON ((O_U.ObjectID = I_U.ObjectID)
                                                                                AND (O_U.Type = dbo.fnd_Object_Type_Gebruiker ()))
                                            WHERE   (I_U.InstanceID = @UserID)
                                    ))
                )
        ORDER BY PC.InternalObjectOrder
    END
    ELSE BEGIN
    print 'status <> depublished'
        SELECT  PageID = P.InstanceID,
                ObjectType = OBJ.Type,
                OBJ.ObjectName,
                P.Label,
                VC.Data,
                P.Version,
                P.LastVersion,
                V.Status, --- P.Status
                V.VersionID,
                V.VersionDate,
                P.StartDateTime,
                P.EndDateTime,
                PropertyLabel = PROP.Label,
                IsLastVersionPublished = CASE
                                            WHEN (P.Version = P.LastVersion) THEN 1
                                            ELSE 0
                                        END
        FROM    dbo.Instance P
        JOIN    dbo.Version V           ON ((V.InstanceID = P.InstanceID) AND (V.Version = P.LastVersion))
        JOIN    dbo.VersionContent VC   ON (VC.VersionID = V.VersionID)
        JOIN    dbo.Property PROP       ON (PROP.PropertyID = VC.PropertyID)
        JOIN    dbo.Object OBJ          ON (OBJ.ObjectID = P.ObjectID)
        WHERE   (P.InstanceID = @PageID)
        ORDER BY VC.InternalObjectOrder
    END
END
ELSE BEGIN
print 'detail <> 1'
    IF (@Status = dbo.fnd_Instance_Status_Published ()) BEGIN
    print 'status = published'
        SELECT  I.InstanceID,
                ObjectType = OBJ.Type,
                OBJ.ObjectName,
                I.Label,
                V.Status, -- was I.Status
                I.Version,
                V.VersionID,
                V.VersionDate,
                OC.Data,
                JIN.Priority,
                JIN.PositionId,
                JIN.JoinInstanceId,
                P.Label AS PositionLabel,
                I.StartDateTime,
                I.EndDateTime,
                OBJ.IsPageObject,
                PropertyLabel = PROP.Label,
                Template = T.TemplateFile,

                IsLastVersionPublished = CASE
                                            WHEN (I.Version = I.LastVersion) THEN 1
                                            ELSE 0
                                        END
        FROM    dbo.Instance I
        JOIN    dbo.Object OBJ          ON (OBJ.ObjectID = I.ObjectID)
        JOIN    dbo.Content OC          ON (OC.InstanceID = I.InstanceID)
        JOIN    dbo.Property PROP       ON (PROP.PropertyID = OC.PropertyID)
        JOIN    dbo.Version V           ON ((V.InstanceID = I.InstanceID) AND (V.Version = I.Version))
        
        LEFT JOIN ( SELECT  JIN1.JoinInstanceID,JIN1.InstanceID_1,JIN1.InstanceID_2,JIN1.TemplateID,JIN1.PositionID,JIN1.Priority
                FROM    dbo.JoinInstance JIN1
                ) AS JIN                    ON ((JIN.InstanceID_2 = I.InstanceID) AND (JIN.InstanceID_1 = @PageID))
        LEFT JOIN   dbo.Position P              ON (P.PositionID = JIN.PositionId)
        LEFT JOIN       dbo.Template T              ON (T.TemplateID = JIN.TemplateID)
        WHERE (ISNULL (JIN.InstanceID_1, 0) = @PageID)
        
        AND     (OBJ.IsPageObject = 0)
        AND     ((@ObjectType = 0) OR (OBJ.Type = @ObjectType))
        AND     (V.Status = 2) -- was I.Status
        AND     ((I.StartDateTime IS NULL) OR (I.StartDateTime <= @lToday))
        AND     ((I.EndDateTime IS NULL) OR (I.EndDateTime >= @lToday))
        AND     ((P.PositionID = @PositionNumber) OR (@PositionNumber = 0))
        
        AND     ((1 = 0)
                OR (I.InstanceID NOT IN (   SELECT  JI.InstanceID_1
                                            -- 1 = Instance uit hoofdquery, 2 = Gebruikersgroep
                                            FROM    dbo.JoinInstance JI
                                            -- Gebruikersgroep
                                            JOIN    dbo.Instance I_UG       ON (I_UG.InstanceID = JI.InstanceID_2)
                                            JOIN    dbo.Object O_UG         ON ((O_UG.ObjectID = I_UG.ObjectID)
                                                                                AND (O_UG.Type = dbo.fnd_Object_Type_Gebruikersgroep ()))
                                        ))
                OR (I.InstanceID IN (       SELECT  JI.InstanceID_1
                                            -- 1 = Instance uit hoofdquery, 2 = Gebruikersgroep
                                            FROM    dbo.JoinInstance JI
                                            JOIN    dbo.Instance I_UG       ON (I_UG.InstanceID = JI.InstanceID_2)
                                            JOIN    dbo.Object O_UG         ON ((O_UG.ObjectID = I_UG.ObjectID)
                                                                                AND (O_UG.Type = dbo.fnd_Object_Type_Gebruikersgroep ()))
                                            -- 1 = Gebruikersgroep, 2 = Gebruiker
                                            JOIN    dbo.JoinInstance JI_B   ON (JI_B.InstanceID_1 = JI.InstanceID_2)
                                            JOIN    dbo.Instance I_U        ON (I_U.InstanceID = JI_B.InstanceID_2)
                                            JOIN    dbo.Object O_U          ON ((O_U.ObjectID = I_U.ObjectID)
                                                                                AND (O_U.Type = dbo.fnd_Object_Type_Gebruiker ()))
                                            WHERE   (I_U.InstanceID = @UserID)
                                    ))
                )
        
        ORDER BY JIN.Priority,
                I.InstanceID,
                OC.InternalObjectOrder
    END
    ELSE BEGIN
    print 'status <> 2'
        SELECT  I.InstanceID,
                ObjectType = OBJ.Type,
                OBJ.ObjectName,
                I.Label,
                --I.Priority,
                V.Status, -- I.Status
                I.Version,
                V.VersionDate,
                V.VersionID,
                VC.Data,
                JIN.Priority,
                JIN.PositionId,
                JIN.JoinInstanceId,
                P.Label AS PositionLabel,
                --PropertyLabel = PROP.Label,
                --I.PositionID,
                I.StartDateTime,
                I.EndDateTime,
                --PositionNumber = POS.Number,
                OBJ.IsPageObject,
                PropertyLabel = PROP.Label,
                Template = T.TemplateFile,
                IsLastVersionPublished = CASE
                                            WHEN (I.Version = I.LastVersion) THEN 1
                                            ELSE 0
                                        END
        FROM    dbo.Instance I
        JOIN    dbo.Object OBJ          ON (OBJ.ObjectID = I.ObjectID)
        JOIN    dbo.Version V           ON ((V.InstanceID = I.InstanceID) AND (V.Version = I.LastVersion))
        JOIN    dbo.VersionContent VC   ON (VC.VersionID = V.VersionID)
        JOIN    dbo.Property PROP       ON (PROP.PropertyID = VC.PropertyID)
        --JOIN  dbo.Position POS        ON (POS.PositionID = I.PositionID)
        LEFT JOIN ( SELECT  JIN1.JoinInstanceID,JIN1.InstanceID_1,JIN1.InstanceID_2,JIN1.PositionID,JIN1.TemplateID,JIN1.Priority
                FROM    dbo.JoinInstance JIN1
                ) AS JIN                    ON ((JIN.InstanceID_2 = I.InstanceID) AND (JIN.InstanceID_1 = @PageID))
        LEFT JOIN   dbo.Position P              ON (P.PositionID = JIN.PositionId)
        LEFT JOIN       dbo.Template T              ON (T.TemplateID = JIN.TemplateID)
        WHERE (ISNULL (JIN.InstanceID_1, 0) = @PageID)
        --WHERE (I.ParentID = @PageID)
        AND     (OBJ.IsPageObject = 0)
        AND     ((@ObjectType = 0) OR (OBJ.Type = @ObjectType))
        AND     ((I.StartDateTime IS NULL) OR (I.StartDateTime <= @lToday))
        AND     ((I.EndDateTime IS NULL) OR (I.EndDateTime >= @lToday))
        AND     ((P.PositionID = @PositionNumber) OR (@PositionNumber = 0))
        --AND       ((POS.Number = @PositionNumber) OR (@PositionNumber = 0))
        ORDER BY JIN.Priority,
                I.InstanceID,
                VC.InternalObjectOrder
    END
END
-- Einde Code
RETURN (0)



GO
SET QUOTED_IDENTIFIER OFF 
GO
SET ANSI_NULLS ON 
GO

[gorgi_19]

Kijk eens naar het execution plan in QA

Als ik me goed herinner, kan je zo een SP opdelen in 'kleinere' SP's en deze dan oproepen, zodat gedeeltes wel gecached kunnen worden, terwijl het grotere geheel dat niet kan.

Ik zie trouwens dat je al een conditie maakt op basis van een input parameter; het lijkt me dat dit statement dan ook makkelijk te scheiden is in 2 statements?

En zo een enorme lap code was trouwens niet echt nodig geweest; de helft was ook al genoeg om het duidelijk te maken Sowieso er is zonder indenting nauwelijks uit te komen.

[ Voor 47% gewijzigd door gorgi_19 op 29-08-2004 22:16 ]

[wasigh]

ja dat IMHO een bad practice: te lang, niet onderhoudbaar en vol "logica" die volgens mij niet in de database hoort te zitten.

[Verwijderd]

wasigh schreef op 29 augustus 2004 @ 22:16:
ja dat IMHO een bad practice: te lang, niet onderhoudbaar en vol "logica" die volgens mij niet in de database hoort te zitten.

Ja dat klopt helemaal, hij is voor mij en mijn collega's perfect onderhoudbaar omdat we er vanaf weten en omdat de code in zijn originele staat netjes is opgebouwd (ipv wat dit forum dus doet, alles op elkaar plempen), maar ik denk dat een nieuwe collega een rolberoerte krijgt. En inderdaad er zit business logic in, dat kan ik dan maar beter in de applicatie definieren.

Ik moet zeggen het stored procedure gebeuren zat me al veel langer dwars. Oa sterk vanwege het onderhoud. Deze stored procedure is namelijk onderdeel van een applicatie op ASP licentie basis.

Elke klant krijgt zijn eigen database ivm contractuele voorwaarden, maar dit betekend ook dat elke klant dezelfde stored procedures krijgt, het is een restore van een database van een andere klant en die wordt dan leeggemaakt. Als er dus een bug wordt gevonden betekend dit dat ik voor alle klanten met eenzelfde systeem de stored procedures moet gaan aanpassen. Niet alleen extreem tijdsintensief (lees 80 clients op een produkt) maar ook nog eens foutgevoelig het blijft namelijk 80x de kans op mensenwerk fouten.

We hebben al eens gekeken naar de mogelijkheden om de stored procedures in de master database te plaatsen want dat is de enige manier om vanuit een andere database een stored procedure aanroepen in de master database. Dus een idee van shared stored procedures, maar uiteraard krijg je zo een shitload aan zooi in je master.

Maar als dus blijkt dat de performance verhalen al niet meer kloppen tja.. dan lijkt het me slim om stored procedures te droppen.

Alleen zaken zoals dit, zou ik het nog graag voor gebruiken

PHP:

SET @lPreviousID = -1
    SET @lCurrentID = 0
    WHILE   (@lCurrentID > @lPreviousID) BEGIN
        SET @lPreviousID = @lCurrentID
        -- Volgende record ophalen
        SELECT  @lCurrentID  = MIN (I.InstanceID)
        FROM    Instance I
        WHERE   (I.ParentID = @InstanceID)
        AND     (I.InstanceID > @lPreviousID)
        SET @lError = @@ERROR
        IF (@lError <> 0) BEGIN
            RAISERROR ('Fout bij ophalen Instance! Fout: %d', 16, 1, @lError)
            ROLLBACK TRAN trInstanceDelete
            RETURN (-1)
        END
        -- Controleren of er een nieuwe gevonden is
        SET @lCurrentID = ISNULL (@lCurrentID, 0)
        IF ((@lCurrentID > 0) AND (@lCurrentID > @lPreviousID)) BEGIN
            -- Delete children
            EXEC    upu_Instance_Delete @InstanceID = @lCurrentID
        END
    END

[ Voor 63% gewijzigd door Verwijderd op 29-08-2004 22:28 ]

[JaQ]

Verwijderd schreef op 29 augustus 2004 @ 22:20:
[...]

We hebben al eens gekeken naar de mogelijkheden om de stored procedures in de master database te plaatsen want dat is de enige manier om vanuit een andere database een stored procedure aanroepen in de master database. Dus een idee van shared stored procedures, maar uiteraard krijg je zo een shitload aan zooi in je master.

Toch is dat wel de oplossing. In Oracle heb je iets dat Virtual Private Database heet. Je maakt policies aan die er voor zorgen dat ahv een database user bepaalde data en procedures / functies / packages beschikbaar voor een beperkte dataset. Je hebt dus fysiek 1 tabel, waar meerdere users op querien, maar die toch verschillende data zien (leg ik dit duidelijk uit zo? hoop het maar... Het gaat in ieder geval een stukkie verder dan "simpelweg" grants uit te delen)

De "ranzige" oplossing met views voor een database user / role om zaken wel of niet beschikbaar te stellen moet verboden worden. Sterker nog, views moeten uberhaupt verboden worden (behalve inlined views dan in queries en materialized views voor datawarehousing)

Persoonlijk vind ik dat de database verantwoordelijk moet zijn voor het bewaken van de integriteit van je data. Dit betekend dus dat er logica in je database kan zitten. Dingen als een email adres valideren is absoluut applicatie laag werk. Dingen als sequences ophogen, foreign (check, unique) keys controleren is definitief database werk. Business rules zijn een discutabel punt. Er zijn gevallen waar je die in je applicatie wilt hebben en soms toch ook niet. Juist als je meerdere applicaties op dezelfde database plakt, is het verstandig om de business rules in de database te hangen naar mijn mening. App. 1 kan namelijk de dataset voor app. 2 vernaggelen, omdat er andere business rules schijnen te gelden. Gecentraliseerd werken dus.

In oracle is het naar mijn mening definitief sneller om met dbms_sql (of dbms_native) te werken dan met een normale query in een stored procedure. De exacte reden kan je ongetwijfeld vinden op otn.oracle.com .

[wasigh]

Met meerdere applicaties op 1 database heb je inderdaad een punt. Daar had ik nog niet over nagedacht.

[d00d]

Ook ik ben een purist en een man van princiepes, daarom zeg ik ja tegen sp's.
Het ligt er natuurlijk wel aan waar je ze voor wilt gebruiken. In een Winforms app met 100-en gebruikers zie ik grote voordelen in sp's omdat je niet je app hoeft te compileren/distribueren wanneer zich een simpele wijziging voordoet in de business logic. Ok, je gebruikt hiervoor natuurlijk een middle tier, maar dan nog is het eenvoudiger om de sp te updaten.

In het algemeen bieden sp's voor mij meer code-reuse, betere exec tijden en in het algemeen ook nog eens een extra 'level of abstraction'. Ik zie zo vaak dat een klant een dure database koopt (wat SQL Server is) en vervolgens alleen maar tabellen gebruikt zodat ze compatible blijven met andere databases.

Ik zou zeggen gebruikt alles. views, constraints, primairy keys, foreign keys, checks, UDF's en dus ook sp's.

[whoami]

wasigh schreef op 30 augustus 2004 @ 00:20:
Met meerdere applicaties op 1 database heb je inderdaad een punt. Daar had ik nog niet over nagedacht.

Mjah.... Je kan dan ook zeggen dat die verschillende applicaties allemaal dezelfde DAL gebruiken. Je queries zitten dan wel niet in de DB, maar die applicaties gebruiken dan allemaal dezelfde DLL.

[Maasluip]

Jemig, is dit een nieuw onderwerp voor een holy war?

In bepaalde gevallen zijn stored procedures toch echt wel van voordeel hoor. Ik zou bijvoorbeeld niet willen dat ik mijn applicatie moet veranderen, compileren en moet uitrollen aan alle gebruikers omdat ik een query verander. Dan liever een SP in de DB die ik even aanpas en compileer, hoef ik me er niet mee bezig te houden waar op welke PC's allemaal de applicatie draait.

Ook zeg je tot zekere hoogte dat als SP's slecht zijn, serverside processing slecht is. Als ik een VB applicatie maak die veel met een database werkt en veel werk op databaserecords verricht wil ik dat graag in de database laten doen. Waarom? Geen load op de lokale PC, betere sessiecontrole, duidelijker programmeerwerk.

Vooral dat laatste: zonder SP zou ik het volgende moeten doen:
• In VB een selectie op de DB om mijn data te halen
• In VB nog een selectie om andere data te halen
• ... nog meer selecties
• In VB de data bewerken
• In VB de data naar de DB terugschrijven
• In VB data naar een andere tabel terugschrijven
• ... alle andere data naar alle andere tabellen terugschrijven

terwijl dit met een SP zo gaat:
• In VB SP aanroepen
• In de DB de SP uitvoeren

Vind ik toch prettiger.

[EfBe]

Gunp01nt schreef op 29 augustus 2004 @ 21:27:
Hebben we het hier dan over gebruik van de speciale functies van SPROCS, of specifiek over het opslaan van SQL queries als SPROC ipv. platte tekst?

Ik denk procs voor CRUD operaties in het algemeen.

Ik ben het met Scott Galloway eens dat dit niet iets is waar je binair over moet denken. Ik heb op FBouma's blog ooit eens een stukje tekst met de volgende strekking gelezen:
"Vroeger was ik fan van Sprocs en gebruikte ik altijd Sprocs. Tegenwoordig ben ik fan van Dynamic SQL en gebruik ik altijd Dynamic SQL"
Je zult dat vast wel doen om 'de discussie aan te zwengelen' of meer van die bla, maar ik vind het niet erg professioneel om zo zwart-wit tegen zaken aan te kijken.

Als je mij dingen wilt toedichten, kom dan aub met een link, anders zou het fijn zijn dat je je mond houdt. Woorden als 'fan' zal ik niet in de mond nemen en 'altijd' ook niet. Zie hierboven waar ik bv een situatie aankaart waarin procedures heel handig kunnen zijn.

Mijn ervaring is dat Sprocs en stored queries in Access heel fijn zijn als je een applicatie maakt met een hoge distributiegraad, zoals een forumsysteem ofzo, en je wilt meerdere DBMS'en ondersteunen. Het is dan heel fijn om de DBMS-specifieke queries ook in het DBMS zelf te kunnen opslaan zodat je in je DAL alleen maar de namen van de sprocs hoeft aan te roepen.

?? Tja, en dan wil je een rowset returning proc porten naar Oracle en moet je je dal code aanpassen want je krijgt een cursor terug ipv een anonieme rowset.

Dan hoef je in je Access database maar een aantal queries neer te plempen en een setup-scriptje schrijven voor SQL Server en dan heb je de SQL mooi in het DBMS waar het bij hoort. Dat maakt het voor je gebruikers meteen ietsje makkelijker om je systeem te installeren.

Die logica kan toch ook in je programmatuur? Volgens mij maakt het daar deel van uit, niet van de database.

Overigens wordt er veel gesproken over de theoretische verschillen in snelheid tussen sprocs en dynamic SQL. Waarom draait iemand niet gewoon een paar benchmarks, dan heb je gelijk enige concrete aanwijzingen van welke van de twee oplossingen het snelst is in welke situatie?

http://weblogs.asp.net/fbouma/archive/2003/05/14/7008.aspx
http://weblogs.asp.net/fbouma/articles/7049.aspx

Verwijderd schreef op 29 augustus 2004 @ 22:11:
Maar in principe zou bijv. mijn onderstaande stored procedure dus een goed voorbeeld zijn van bad practice. Immers gebruik ik if end if constructies, case constructies en zo heb ik er nog meer staan. Dit zijn dus stored procedures die keer op keer opnieuw moeten worden bepaald door SQL Server? .. is dat correct?

Correct. Deze proc moet elke keer weer gecompileerd worden, het cached execution plan kan niet worden hergebruikt.

We hebben al eens gekeken naar de mogelijkheden om de stored procedures in de master database te plaatsen want dat is de enige manier om vanuit een andere database een stored procedure aanroepen in de master database. Dus een idee van shared stored procedures, maar uiteraard krijg je zo een shitload aan zooi in je master.

Huh? EXEC databasename.dbo.procname param1... paramn
of EXEC sp_executesql ... (deze is beter, want deze cached het execution plan van aangeboden sql)

whoami schreef op 29 augustus 2004 @ 22:06:
Ik vind eigenlijk dat er nogal veel heisa rond gemaakt wordt.
De een vind SP's prettiger werken, de andere queries in de app-code zelf.

Het punt is dat er veel onzin gebruikt wordt om een ander bv het gebruik van procs op te dringen door belachelijke bedrijfspolicies. Als ontwikkelaar kom je daar soms mee in aanraking en het is dan knap lastig die 'myths' dan te ontkrachten. We zitten in het jaar 2004, het wordt tijd dat het eens afgelopen is met die op onzin gebaseerde aannames.

[ Voor 31% gewijzigd door EfBe op 30-08-2004 10:00 ]

[EfBe]

d00d schreef op 30 augustus 2004 @ 01:19:
Ook ik ben een purist en een man van princiepes, daarom zeg ik ja tegen sp's.
Het ligt er natuurlijk wel aan waar je ze voor wilt gebruiken. In een Winforms app met 100-en gebruikers zie ik grote voordelen in sp's omdat je niet je app hoeft te compileren/distribueren wanneer zich een simpele wijziging voordoet in de business logic. Ok, je gebruikt hiervoor natuurlijk een middle tier, maar dan nog is het eenvoudiger om de sp te updaten.

Oh? En wat als er meerdere apps op die db draaien? of wat als die proc een extra parameter krijgt?

In het algemeen bieden sp's voor mij meer code-reuse, betere exec tijden en in het algemeen ook nog eens een extra 'level of abstraction'.

Is dat gebaseerd op 'gevoel' of heb je ook feiten om dit te onderbouwen? Dat extra level of abstraction is niet te ontkennen, het extra level of misery ook niet: stel jij wijzigt een proc omdat een situatie dat nodig heeft (extra parameter). Die proc wordt wellicht 3 keer gebruikt. Nu moet jij dus op 3 plekken de call wijzigen, want er is een extra parameter. Je moet dan ook op meerdere plekken iets wijzigen want zowel in je dal als in je proc moet je dingen aanpassen. Lijkt me leuk voor de testers.

Ik zie zo vaak dat een klant een dure database koopt (wat SQL Server is) en vervolgens alleen maar tabellen gebruikt zodat ze compatible blijven met andere databases.

Err... de kracht van die database zit in het systeem dat die tables beheert, transaction support en wat al niet meer.

Maasluip schreef op 30 augustus 2004 @ 09:33:
Ook zeg je tot zekere hoogte dat als SP's slecht zijn, serverside processing slecht is. Als ik een VB applicatie maak die veel met een database werkt en veel werk op databaserecords verricht wil ik dat graag in de database laten doen. Waarom? Geen load op de lokale PC, betere sessiecontrole, duidelijker programmeerwerk.

Vooral dat laatste: zonder SP zou ik het volgende moeten doen:
• In VB een selectie op de DB om mijn data te halen
• In VB nog een selectie om andere data te halen
• ... nog meer selecties
• In VB de data bewerken
• In VB de data naar de DB terugschrijven
• In VB data naar een andere tabel terugschrijven
• ... alle andere data naar alle andere tabellen terugschrijven

terwijl dit met een SP zo gaat:
• In VB SP aanroepen
• In de DB de SP uitvoeren

Vind ik toch prettiger.

SQL is een set-based taal. Als jij vanuit je applicatie iets moet updaten in de database, kun je gewoon een query uitvoeren die dat voor je doet. Het leuke is, je hoeft maar 1 keer de generator te maken die dat voor je genereert at runtime en de volgende keer kun je met simpele code je multi-table filtered update query uitvoeren moet een paar regels code.

[ Voor 30% gewijzigd door EfBe op 30-08-2004 10:09 ]

[seweso]

Abstraction ís de toekomst, daar kun je volgens mij moelijk omheen omdat dit een trend is die al ingezet is vanaf de stap van machine-taal naar assembler. Dit betekent dat je als programmeur steeds complexere taken kan laten uitvoeren zonder je druk te hoeven maken met de achterliggende techniek. Net als met elke low-level techniek kun je met SP vast wel snelheids-winsten behalen, maar tegen welke prijs? En kun je die snelheids-winst ook niet op een andere manier halen? Hardware word steeds goedkoper/sneller, hierdoor zal in feite elke optimalisatie die je ooit hebt gemaakt vanzelf een keer verwaarloosbaar en totaal nutteloos worden. Goede en begrijpbare business-logic daarentegen kent daarentegen geen tijd en kan vaak in de toekomst gebruik maken van allerlei optimalisaties en vernieuwingen die in het database-platform aangebracht worden.

SP's zijn simpelweg vergankelijk...

[Verwijderd]

EfBe schreef op 30 augustus 2004 @ 09:51:
Correct. Deze proc moet elke keer weer gecompileerd worden, het cached execution plan kan niet worden hergebruikt.

Daar was ik dus al bang voor

Waar ik alleen een beetje van baal is dat je zo weinig mogelijkheden hebt naast stored procedures om recursieve calls uit te voeren. Voor een programma dat gecompiled is alla, maar voor een systeem ontwikkeld in PHP, CF, ASP, loop je al snel tegen de situatie aan dat je recursief templates gaat aanroepen, en mensen die hier ervaring mee hebben weten het resultaat voor server load wel

Recursieve calls bijvoorbeeld om een structuur in de vorm van een sitemap op te halen, waar je dus parent child relaties hebt. Ik zou niet voor elke parent een call willen gaan doen.

[EfBe]

Verwijderd schreef op 30 augustus 2004 @ 10:29:
[...]
Waar ik alleen een beetje van baal is dat je zo weinig mogelijkheden hebt naast stored procedures om recursieve calls uit te voeren. Voor een programma dat gecompiled is alla, maar voor een systeem ontwikkeld in PHP, CF, ASP, loop je al snel tegen de situatie aan dat je recursief templates gaat aanroepen, en mensen die hier ervaring mee hebben weten het resultaat voor server load wel


Recursieve calls bijvoorbeeld om een structuur in de vorm van een sitemap op te halen, waar je dus parent child relaties hebt. Ik zou niet voor elke parent een call willen gaan doen.

Recursive calls in procs zijn ook niet zaligmakend. T-SQL ondersteunt eigenlijk geen recursie (komt met yukon) (call related context op stack) en een recursieve call kan maar 32 niveaus diep. Dat is op zich niet zo belemmerend in veel gevallen, maar veelal geeft het meer aan dat je SQL code niet zo goed is. SQL is geen imperatieve taal, een 'loop' in SQL is bijna altijd onnodig, daarvoor heb je de set in SQL, de basis van de taal, waarop je een operatie uitvoert. Je kunt bv die set laten creeren door een UDF en het resultaat, een table variable, gebruiken in de FROM clause van een select.


(edit) ik had nog een gedeelte getikt over een boom opslag in SQL maar omdat ik preview deed omdat ik 2 procs had gepost, en toen juist react werd geupdate heb ik die tekst niet meer.

[ Voor 8% gewijzigd door EfBe op 30-08-2004 12:27 ]

[Olaf van der Spek]

whoami schreef op 30 augustus 2004 @ 08:22:
Mjah.... Je kan dan ook zeggen dat die verschillende applicaties allemaal dezelfde DAL gebruiken. Je queries zitten dan wel niet in de DB, maar die applicaties gebruiken dan allemaal dezelfde DLL.

En als een paar apps nu eens geen DLLs kunnen gebruiken?

[Onno]

...bijvoorbeeld omdat ze op een ander OS draaien?


Ik gebruik zelf regelmatig stored procedures, omdat ik bepaalde bewerkingen vanuit compleet verchillende omgevingen uitvoer. Niet alleen voorkom ik zo code duplicatie, maar ook kan ik nauwkeuriger (maar vooral eenvoudiger) beperken wat een applicatie mag en wat niet dan met alleen constraints, triggers, etc.


Ik schrijf immers de SPs, en het enige wat zo'n (soms untrusted) applicatie kan is die SPs gebruiken.


(veel argumenten die aangevoerd worden in die aangehaalde discussies zijn trouwens specifiek toegespitst op MSSQL, dat is een beetje jammer in een [ALG]emene discussie )

[ Voor 17% gewijzigd door Onno op 30-08-2004 12:21 ]

[whoami]

Onno schreef op 30 augustus 2004 @ 12:10:
...bijvoorbeeld omdat ze op een ander OS draaien?

Wie zegt dat de DAL op de client moet draaien?
Je kan je DAL op dezelfde machine als je DB laten draaien. Met een coarse-grained webservice interface heb je al een hoop problemen opgelost.

[Tomatoman]

Wat mij betreft moet je de database zien als de fysieke dataopslag en het DBMS (database managementsysteem) - dat onder andere stored procedures uitvoert - als een aparte layer. Database en DBMS zijn in de praktijk weliswaar nauw met elkaar verweven, maar voor de programmaopbouw kun je ze als twee losstaande layers zien. Ik vind het daarom ook geen probleem om stored procedures te gebruiken, ze zijn gewoon een apart deel van de data access layer.

OlafvdSpek schreef op 30 augustus 2004 @ 11:39:
[...]


En als een paar apps nu eens geen DLLs kunnen gebruiken?

Elke serieuze programmeertaal kan tegenwoordig overweg met DLL's.

[Verwijderd]

whoami zegt iets waar nog weinig op in gaan. Met SP heb je geen versie controlle. Zelf hou ik het liefst al mijn queries gescheiden door ze in aparte .sql bestanden op te slaan. Een simpele (in portable c geschreven) preprocessor vult daar parameters in en de complete query stuur je naar de DBMS.

[D4Skunk]

Dit is volgens mijn persoonlijke mening een vraag die onmogelijk te beantwoorden is, net zoals bv de vraag "welke programmeertaal is de beste ?".


Momentaal draaien mijn klanten op een zelf-geschreven applicatieframework, dat bij CRUD dynamisch queries genereert dmv de commandbuilder in .NET, en een architectuur heeft met .Net plugin-dlls specifiek voor elke applicatie.
In deze plugins is een trigger-interface voorzien, die bij elke CRUD kan aangeroepen worden. Bijna alle business logic (99,9%) zit dus in de plugin ( geschreven in .NET, en niet in T-SQL).


Persoonlijk ben ik dus voorstander van de Bouma-aanhangers, zij het met een paar uitzonderingen : maintenance en performance.


Een irl voorbeeld van zo'n geval is een SP voor het indelen van de klanten in categoriën adhv hun omzet.
Dit is een update statement, dat heel eenvoudig te schrijven is in sql, en ook nog eens sneller loopt. Voor de plugin was slechts 1 lijn code nodig, en de rest van het programmeerwerk beslaat twee views en de updatequery.


De 'niet-sql'-aanpak was : elke individuele klant ophalen, evalueren en vervolgens terug wegschrijven. Iedereen met een beetje ervaring kan inzien dat dit sowiezo trager zou lopen en meer tijd zou vergen om te programmeren/onderhouden.


Maintenance was hier de doorslaggevende factor, performantiewinst was gewoon een bijkomend voordeel. Performantie is nl. niet erg relevant voor een functie die maar 1 keer per jaar moet uitgevoerd worden.


Samengevat : gebruik SP's alleen wanneer er :
- 'minder of eenvoudigere code' kan gebruikt worden
- relevante (=veel gebruikte code ) performance-winst is
- een combinatie van beide

[whoami]

* whoami is het eens @D4Skunk.

[Verwijderd]

Lekkere discussie


Eerst dit:


Opmerkingen/discussie over de snelheid tussen SQL statements in je applicatie en SP's zijn zoals ze nu gevoerd worden beetje nutteloos om er vanuit die optiek tegen aan te kijken.
De snelheid winst met SP's wordt pas echt behaald als je grote databewerkingen doet aan de server kant omdat daar meestal hardware staat die ze sneller kan verwerken. Als je snelle DB's systemen hebt kun je dus nog steeds een snelle applicatie hebben op een traag systeem. Anders moet er steeds dynamic SQL gegeneerd worden. De uitvoering is even snel als een PROC alleen het generen ervan kost tijd.


Ik gebruik zelf ook SP's.


De data in de database wordt vaak door meerdere applicaties gebruikt. Als er dan een aanpassing gedaan moet worden dan hoef je maar 1x de SQL code in de SP te wijzigen en daarna een minimaal werk in je applicaties.


Maar ik vind dat het totaal afhankelijk is van de oplossing die je probeert te gebruiken. In sommige gevallen zal het zo zijn dan je veel SP's gebruikt en een andere keer zal het zo zijn dat je geen SP's gebruikt. Denk bijvoorbeeld ook maar eens aan thinclients. Of webservices met databases erachter. Of applicaties die op systemen staan die niet altijd verbonden zijn met de database.


Je kan dus niet zeggen dat SP's slecht zijn of goed, of dat je ze altijd moet gebruiken of nooit. Elk geval/oplossing is anders. Soms zijn SP's handig en soms niet.


Maar omdat het geen slechte gewoonte is om consistent te zijn kan je voor kiezen of ze altijd wel te gebruiken of nooit.

[ Voor 12% gewijzigd door Verwijderd op 30-08-2004 14:12 ]

[Infinitive]

Misschien dat het verstandig is om het type applicatie in de discussie te brengen. Ik hoor namelijk mensen praten over meerdere apps die de database benaderen. In een enterprise-scenario mag dit echter nooit voorkomen: je applicaties praten op een of andere (indirecte) manier met je BL, maar nooit rechtstreeks met de DAL of database. Het zal me alleen niets verbazen als je in de praktijk te maken hebt met legacy apps die roet in het eten gooien, maar daar heb ik persoonlijk gelukkig nog niet mee te maken gehad.


Ben je echter met 1 of 2 tier applicaties bezig, dan bestaat er alleen maar zoiets als een database. Tja, als je dan wat processing op de server wilt doen blijven alleen faciliteiten van je dmbs over.

[Verwijderd]

Verwijderd schreef op 30 augustus 2004 @ 13:55:
De snelheid winst met SP's wordt pas echt behaald als je grote databewerkingen doet aan de server kant omdat daar meestal hardware staat die ze sneller kan verwerken. Als je snelle DB's systemen hebt kun je dus nog steeds een snelle applicatie hebben op een traag systeem.

Als je data hebt die op client systemen geprocessed kan worden en meerdere clients doen dit tegelijk heb je wel automatisch parallel execution.

[Verwijderd]

Verwijderd schreef op 30 augustus 2004 @ 14:16:
[...]


Als je data hebt die op client systemen geprocessed kan worden en meerdere clients doen dit tegelijk heb je wel automatisch parallel execution.

Als meerdere clients dezelfde data bewerken dan heb je sowieso een probleem als je geen SP's gebruikt. Maar neem aan dat je bedoelt dat clients verschillende brokken data processen. In dat geval gaat nog steeds op dat het goedkoper is om hiervoor een aan de database kant zwaardere hardware neer te zetten dan meerdere zwaardere clients. Je kan beter een dure server hebben met constante load van 60% dan 100 duurdere clients met 99% van de tijd een load van 1% en 1% van de tijd een load van 99%.


Ik hou ook meer van dynamic SQL dan SP's, liefste natuurlijk objecten opslaan in DB of object-mapping. Ik hou van thin clients voor databewerkingen, maar zie ook de vele nadelen van SP's. Daarom elke keer de afweging maken.

[ Voor 15% gewijzigd door Verwijderd op 30-08-2004 14:35 ]

[Verwijderd]

Maar aan de andere kant kun je bij data intensieve operaties ook weer denken om deze bij de client neer te leggen, daar heb je immers meer mogelijkheden om die data te bewerken. Vooral string functies in MSSQL zijn maar erg beperkt.


Dan blijven stored procedures alleen nog over voor database specifieke acties, zoals voor MSSQL full text search

[Verwijderd]

Verwijderd schreef op 30 augustus 2004 @ 14:37:
Maar aan de andere kant kun je bij data intensieve operaties ook weer denken om deze bij de client neer te leggen, daar heb je immers meer mogelijkheden om die data te bewerken. Vooral string functies in MSSQL zijn maar erg beperkt.


Dan blijven stored procedures alleen nog over voor database specifieke acties, zoals voor MSSQL full text search

Ik heb zelf nog nooit string bewerkingen gedaan in applicaties, althans niet bij de dataverwerking. Zie daar ook niet de noodzaak van in.

[EfBe]

Verwijderd schreef op 30 augustus 2004 @ 14:33:
[...]
Als meerdere clients dezelfde data bewerken dan heb je sowieso een probleem als je geen SP's gebruikt.

Waarom? Denk je dat concurrency problemen verdwijnen bij het gebruik van procs? Lijkt me niet.

Maar neem aan dat je bedoelt dat clients verschillende brokken data processen. In dat geval gaat nog steeds op dat het goedkoper is om hiervoor een aan de database kant zwaardere hardware neer te zetten dan meerdere zwaardere clients. Je kan beter een dure server hebben met constante load van 60% dan 100 duurdere clients met 99% van de tijd een load van 1% en 1% van de tijd een load van 99%.

Maar client hardware is veel goedkoper en: al aanwezig. De gemiddelde kantoorklerk tikt zn worddocs op een machine waar je erg veel dingen op kunt draaien zonder dat je daar ook maar iets van merkt

[Verwijderd]

EfBe schreef op 30 augustus 2004 @ 15:00:
[...]


Waarom? Denk je dat concurrency problemen verdwijnen bij het gebruik van procs? Lijkt me niet.

Mij ook niet. Laat alleen liever locks e.d. aan het DBMS over en niet aan mijn applicatie.


[...]


Maar client hardware is veel goedkoper en: al aanwezig. De gemiddelde kantoorklerk tikt zn worddocs op een machine waar je erg veel dingen op kunt draaien zonder dat je daar ook maar iets van merkt :)[/quote]


Wat is duurder 10x client pc of 1x server. Als je een bedrijf het met 500 pc's en je kan per pc 500 euro besparen door een lichtere machine te nemen, kun je een paar goede servers voor neer zetten en nog geld over houden.


btw. Je O/R tool is vet!

[whoami]

Verwijderd schreef op 30 augustus 2004 @ 15:29:
[...]


Mij ook niet. Laat alleen liever locks e.d. aan het DBMS over en niet aan mijn applicatie.

Of je dat nu doet dmv sp's of queries, imo blijft dat het zelfde hoor.

[EfBe]

Verwijderd schreef op 30 augustus 2004 @ 15:29:


(EfBe: >>
Maar client hardware is veel goedkoper en: al aanwezig. De gemiddelde kantoorklerk tikt zn worddocs op een machine waar je erg veel dingen op kunt draaien zonder dat je daar ook maar iets van merkt <<
Wat is duurder 10x client pc of 1x server. Als je een bedrijf het met 500 pc's en je kan per pc 500 euro besparen door een lichtere machine te nemen, kun je een paar goede servers voor neer zetten en nog geld over houden.

In theorie heb je gelijk inderdaad. Het punt is echter dat de praktijk anders is: de desktop pc's die men tegenwoordig koopt (de 500euro pc's of zelfs nog minder) hebben dermate veel rekenkracht dat ze makkelijk bv client-side sorting kunnen doen. VOor 500 werkplekken scheelt dat dus 500x een sort actie op de server. Het lullige is dat server hardware wel degelijk er duur is, wanneer je een wat grotere koopt.


Het valt natuurlijk ook te bezien wat je aan netwerkbelasting trekt, want dat is vaak de limiterende factor: 500pc's die een 1000 row recordset overhalen om daar 10 rijen van te bekijken, halen dus 500x990 rijen teveel op. Dat kan het netwerk natuurlijk wel negatief belasten, maar hoeft dus niet. Het is dus maar net waar dat break-even punt ligt. Voor sommige, zware, processen is het dus zaak niet die miljoenen rows over te halen naar de client voor wat processing, maar voor andere wel.


Sommige O/R mappers hebben hier dus ook nadeel van. Ik sprak laatst met THomas Tomiszec van EntityBroker en hij had een voorbeeld waarbij hij een hele site in een CMS wilde deleten, daarbij moest hij dus ALLE entities instantiaten op de client, processen en daarna deleten. Dit omdat hij geen sql direct op de server wilde draaien/kon draaien. Tja, het is wellicht sneller om dan gewoon een server-side delete query te draaien (vandaar dat wij dat ook ondersteunen). Met updates en met name bulk updates idem dito.

btw. Je O/R tool is vet!

Dank je!

[Verwijderd]

EfBe schreef op 30 augustus 2004 @ 15:39:
[...]


In theorie heb je gelijk inderdaad. Het punt is echter dat de praktijk anders is: de desktop pc's die men tegenwoordig koopt (de 500euro pc's of zelfs nog minder) hebben dermate veel rekenkracht dat ze makkelijk bv client-side sorting kunnen doen. VOor 500 werkplekken scheelt dat dus 500x een sort actie op de server. Het lullige is dat server hardware wel degelijk er duur is, wanneer je een wat grotere koopt.


Het valt natuurlijk ook te bezien wat je aan netwerkbelasting trekt, want dat is vaak de limiterende factor: 500pc's die een 1000 row recordset overhalen om daar 10 rijen van te bekijken, halen dus 500x990 rijen teveel op. Dat kan het netwerk natuurlijk wel negatief belasten, maar hoeft dus niet. Het is dus maar net waar dat break-even punt ligt. Voor sommige, zware, processen is het dus zaak niet die miljoenen rows over te halen naar de client voor wat processing, maar voor andere wel.

Ja precies, ene geval wel andere niet. Denk dat je daar ook mooi mee aangeeft dat er op de stelling van de TS geen antwoord is dat onomstootbaar is. Soms zijn SP's praktisch en soms niet.


Misschien geeft dit ook aan welke problemen onze sleur-en-pleur programmeerhoudingen met zich meebrengen.


[quote]


Sommige O/R mappers hebben hier dus ook nadeel van. Ik sprak laatst met THomas Tomiszec van EntityBroker en hij had een voorbeeld waarbij hij een hele site in een CMS wilde deleten, daarbij moest hij dus ALLE entities instantiaten op de client, processen en daarna deleten. Dit omdat hij geen sql direct op de server wilde draaien/kon draaien. Tja, het is wellicht sneller om dan gewoon een server-side delete query te draaien (vandaar dat wij dat ook ondersteunen). Met updates en met name bulk updates idem dito.


[...]


Tja, dat is goede...


Ik denk op mijn beurt weer dat als je met O/R tools werkt, en dus ook met hun limitaties te maken krijgt dat moet je daar je applicatie op aanpassen. In zo'n geval zou ik er dan voor kiezen om voor elke site een aparte database te maken (zoals Exact dit doet voor elke klantadministratie). Dit dus om aan te geven dat door het gebruik van O/R mapping tools in sommige gevallen dingen anders aan moet pakken.

[ Voor 3% gewijzigd door Verwijderd op 30-08-2004 15:53 ]

[Skinny]

Wij hebben nu een centrale database draaien met een aantal sp's voor het uitvoeren van handelingen op bijna alle tabellen. Hierin zitten vaak enige checks en bij bepaalde update's worden meerdere tabellen tegelijk bijgewerkt. Waarom hier sp's ? Omdat meerdere applicaties in meerdere talen met deze database moeten werken. Door nu alleen deze sp's toe te staan voorkom je dat e.o.a. pino met SQL gaat lopen rotzooien.

[misfire]

Jezus hoeven jullie overdag niet te werken ofzo, wat een hoop extra zooi, zo kan ik niet netjes aansluiten. Toch even reageren op reacties op mijn posts van een paar pagina's terug, want ik zie een aantal argumenten in mijn oorspronkelijke verhaal niet direct terug in de rest van de posts.

whoami schreef op 29 augustus 2004 @ 20:12:

Wat bedoel je dan?


Ik had het over data-centrische taken. Procedures die heel intensief met data uit de DB werken schrijf je imo beter in een SP om zo roundtrips te gaan besparen.

Je hoeft niet persé een SP te gebruiken om roundtrips te besparen. Je kunt ook een SQL batch naar de database toe sturen en dan heb je precies hetzelfde effect. Het issue wat hier wordt aangegeven dat je SQL code in de applicatie moet managen, en niet in een SP op de database moet stoppen. Vanuit het oogpunt van performance is het niet nodig om een SP in te zetten ipv de SQL van de applicatielaag te laten komen.

EfBe schreef op 29 augustus 2004 @ 20:14:
[De DBA vindt het belangrijk dat SQL code die op de DB wordt uitgevoerd voor hem inzichtelijk is.]
No offence, maar: lekker belangrijk wat die DBA vindt. Het punt is: de DBA is de beheerder van de database, maar niet de ontwikkelaar van de API. Tevaak wordt de DBA de persoon die bepaalt op welke wijze er met de data wordt omgegaan in een applicatie, terwijl de DBA een ondergeschikte rol zou moeten spelen.

Vind jij het vreemd dat de DBA de persoon is die bepaalt hoe er met de database wordt omgegaan? Ik vind het niet vreemd dat de DBA kritisch is. Als de database server crasht, of hij wordt veel te traag, of er gebeuren gekke dingen met de data, dan is hij wel verantwoordelijk. Daar komt nog bij dat de database server in zijn lifecycle vaak door verschillende applicatie platforms wordt aangesproken: VB, Java, .NET, Python, TclTk, Cobol, whatever. Moet een DBA daar allemaal in thuis zijn om te begrijpen wat er op de database af komt? SP's bieden dan iets uniforms, wat hij los van de rest van de code kan inspecteren, testen en autoriseren.


Ik snap je opmerking over de API ook niet. Een API is de interface naar boven toe. De API van je DAL wordt niet beïnvloed door het gebruik van SP's, want de DAL moet dit juist abstraheren. Het is natuurlijk nog steeds nuttig om een DAL laag in je applicatie te hebben, ook al gebruik je SP's, maar een DBA heeft nooit invloed op je API, tenzij hij bepaalde constraints op de functionele data wil (en dat is een heel andere discussie dan inline SQL vs SP).

[Stored procs hoeven geen onderhoudsprobleem te betekenen. Een database aanpassing is zowieso een onderhoudsprobleem. Als je automatische SQL scripts gebruikt voor CRUD operaties, dan kun je ook automatisch stored procs genereren en je hebt een vergelijkbaar onderhoudsscenario. Als meerdere applicaties gebruik maken van dezelfde database dan hoef je de SQL code maar op één plek te onderhouden en heb je in principe onderhoudswinst, maar je kunt natuurlijk ook applicatie componenten hergebruiken om hetzelfde effect te bereiken.]
Dit is onzin.

Dat is helemaal geen onzin, ik noem toch argumenten, die jij niet weerlegt. Ik vind het ook geen stijl van reageren.

Als jouw tabel 5 keer wijzigt, heb jij 5 versies van je proc in de db staan. Je moet dus elke keer de procs weghalen die je hebt gegenereerd. Dit kan lastig zijn.

Zoals ik in mijn oorspronkelijke verhaal al betoogde heb je zowieso al fiks wat onderhoud als je database aanpassingen maakt. Procs weghalen hoeft niet eens want je kunt ze gewoon updaten. En zelfs droppen is geen punt, je hoeft echt geen raketgeleerde te zijn om dat gewoon in het proc scriptje te stoppen, tools als VS.Net doen het zelfs al automatisch voor je.

Een procedure heeft verder als nadeel dat het een static interface heeft: je kunt niet even een filter aanpassen voor een specifieke situatie. Uiteraard komen nu de mensen die met nullable parameters dit op gaan lossen maar dit is maar schijn: je procedure wordt erg ingewikkeld daardoor en veelal veel trager. Dit houdt dus in dat je procedure logica in feite onder meerdere interfaces wordt opgeslagen: filter on A, filter on A and B, filter on A and B + C etc. etc.

En je hebt zeker wel een dynamische interface op je API ofzo? Dan schrijf je toch gewoon meer proc's voor die andere situatie. Op je applicatielaag maak je er ook meerdere methodes voor, dus dan heb je dáár het onderhoudsprobleem, met als enige verschil dat je niet ff opnieuw je scripts kunt runnen om te kijken of je sql nog valide is.

Wijzigt de logica van het BL component, dan is dat dus alleen een wijziging van het BL component, niet ergens anders. Wanneer je een proc gebruikt, moet je goed documenteren waar deze proc nog meer gebruikt wordt.


Met name dat laatste is funest. Het is niet zo moeilijk dat te documenteren, dat weet een 3-jarig kind. Het probleem begint wanneer het systeem 2 jaar in productie is en er 3 clients op draaien. In die 2 jaar zijn er wellicht legio wijzigingen geweest. Houdt iedereen die wijzigingen bij in de documentatie? Ik moet de 1e organisatie nog tegenkomen die dat doet.

Het documentatie probleem los je toch niet op door géén stored procs te gebruiken??? Die legio wijzigingen zijn net zo goed een ramp in applicatie code, misschien zelfs nog erger omdat het daar minder opvalt als SQL code volgens het copy pasta patroon wordt ontwikkeld, waarbij natuurlijk bij wijzigingen de ene lap code wel wordt aangepast, en de andere niet.


Ik werk nu in een integratieproject van 7 database systemen variërend van 15 tot 2 jaar oud, en ze worden allemaal door een andere applicatielaag ontsloten, met C++, Fortran, Delphi, Java EJB/CMP. Sommige databases hebben zelfs geen constraints op de tabellen (alles nullable) omdat ze ontworpen zijn met de gedachte dat de applicatielaag de vrijheid moest hebben om alles te doen en de verantwoordelijkheid had om het te checken. Geen van de systemen maakt gebruik van stored procs, en geen van de systemen is goed gedocumenteerd. Het is gewoon één grote onderhoudsnachtmerrie, die eerder kleiner was geweest met sp's, maar zeker niet groter.

[Ik heb zelf een paar applicaties gemaakt met stored procedures en zonder en mij maakt het eigenlijk niet zo veel uit. Met tooltjes als CodeSmith kun je vrij makkelijk de triviale procs laten genereren. Echt *nodig* vind ik stored procs ook niet.]
Het is wel grappig om te lezen vaak dat de mensen die pro-procs zijn zich gedragen als, (no offence), streng-gelovigen: zonder enig argument claimen dat X en Y waar is. Ach ja, het is leuk tijdverdrijf, alleen soms wordt het wat vervelend

Hum ik ben dus niet pro-procs, zoals de dikke letters wellicht laten zien. Maar sommige streng-gelovigen kunnen alleen zwart wit denken, dus het feit dat ik er niet tegen ben zal me wel een "pro-procs fundamentalist" maken.


Ik ben overigens wel pro-OR mapper, maar dat is vanwege de toegevoegde abstractie en productiviteitswinst. Bovendien kun je met een goede OR mapper nog steeds stored procedures gebruiken.

[alienfruit]

Vind jij het vreemd dat de DBA de persoon is die bepaalt hoe er met de database wordt omgegaan? Ik vind het niet vreemd dat de DBA kritisch is. Als de database server crasht, of hij wordt veel te traag, of er gebeuren gekke dingen met de data, dan is hij wel verantwoordelijk. Daar komt nog bij dat de database server in zijn lifecycle vaak door verschillende applicatie platforms wordt aangesproken: VB, Java, .NET, Python, TclTk, Cobol, whatever. Moet een DBA daar allemaal in thuis zijn om te begrijpen wat er op de database af komt? SP's bieden dan iets uniforms, wat hij los van de rest van de code kan inspecteren, testen en autoriseren.

Nou dan moet die DBA maar de technische documentatie van het programma doornemen, hierin wordt vaak ook de werking van de queries e.d. besproken. Ik vind niet dat een applicatie platform alleen maar stored procedures moet gebruiken, omdat de DBA anders niet weet wat er met zijn server gebeurt. Dat vind ik ook vreemd...

[Bobco]

alienfruit schreef op 30 augustus 2004 @ 20:57:
[...]


Nou dan moet die DBA maar de technische documentatie van het programma doornemen, hierin wordt vaak ook de werking van de queries e.d. besproken. Ik vind niet dat een applicatie platform alleen maar stored procedures moet gebruiken, omdat de DBA anders niet weet wat er met zijn server gebeurt. Dat vind ik ook vreemd...

Voor grote databases is het niet ongebruikelijk dat queries of door de DBA worden geschreven of ter goedkeuring aan de DBA moeten worden voorgelegd. Een grote database (en dan bedoel ik zowel in aantallen tabellen als hoeveelheid data) op een efficiente manier benaderen is een vak op zich. Voor kleinere databases is een goede programmeur die wat verstand heeft van SQL ook nog wel in staat om redelijke dingen te maken, voor het zwaardere werk moet je behoorlijk verstand hebben van een database ( en dan met name allerlei implementatie en TDM achtige zaken) om de zaak goed aan de praat te houden.

Om nog een beetje terug te komen op de start van het topic: al deze 'dynamische' SQL gaat er wel vanuit dat de optimizer van de database slim genoeg is om een snelle access methode uit te vogelen. Ik kan me echter al de boze DBA voorstellen die er opeens achterkomt dat zijn o zo mooi getunede database voor geen meter meer performed omdat applicatie X om de 14 minuten een table scan doet op de tabel met de meeste rows....

[whoami]

Als je iets afweet van SQL en hoe de databank in elkaar steekt (zowel fysisch als logisch), dan zou je geen trage queries mogen/moeten kunnen schrijven.
Trouwens, als developer test je dat toch echt wel hoor. Dat is één van je taken.

[Bobco]

whoami schreef op 31 augustus 2004 @ 20:07:
Als je iets afweet van SQL en hoe de databank in elkaar steekt (zowel fysisch als logisch), dan zou je geen trage queries mogen/moeten kunnen schrijven.
Trouwens, als developer test je dat toch echt wel hoor. Dat is één van je taken.

Voor grotere organisaties is dat helaas niet haalbaar. Vaak worden databases benaderd door meer dan 1 applicatie en dan vaak ook nog tegelijkertijd. In dat soort situaties is een developer absoluut niet in staat om de impact op de performance van de database in te schatten of te meten.

[whoami]

Verschillende DB's zouden allemaal dezelfde DAL moeten gebruiken als ze dezelfde DB benaderen.

[misfire]

alienfruit schreef op 30 augustus 2004 @ 20:57:Nou dan moet die DBA maar de technische documentatie van het programma doornemen, hierin wordt vaak ook de werking van de queries e.d. besproken. Ik vind niet dat een applicatie platform alleen maar stored procedures moet gebruiken, omdat de DBA anders niet weet wat er met zijn server gebeurt. Dat vind ik ook vreemd...

Je zet nu mijn verhaal op zijn kop. Ik zeg niet dat je sp's moet doen puur en alleen omdat een DBA dat wel, en je eigenlijk om andere redenen liever iets anders zou willen. Ik zeg alleen dat stored procs handig zijn voor een DBA.

Het is natuurlijk altijd een totaal-afweging die je maakt, waarbij je óók de belangen van de DBA betrekt, dus niet: "lekker belangrijk die DBA". Deze discussie ging over voor- en nadelen van stored procs. Dit is er één.

Je zult bij een DBA inderdaad altijd een formele beschrijving van de SQL die je op de database server los laat moeten deponeren, anders kan hij nooit verantwoording nemen over wat er op de database gebeurt. Je zou alle SQL code in de technische documentatie kunnen copy-pasten, en dan kan de DBA het daar vandaan halen. Ik zet liever geen productiecode in de documentatie, want dat is alleen maar slechter onderhoudbaar, ik zou liever een bepaalde structuur in de code aanbrengen waardoor het dáár makkelijk is terug te vinden. Stored procs zijn dan misschien nog niet zo'n hele vervelende oplossing.

Nogmaals ik vind het echt niet erg als je geen stored procs gebruikt, net zo min als dat je ze wel gebruikt. Ik vind het verschil gewoon niet zo groot, het gaat er alleen over op waar je de SQL code opslaat. In de totaal plaatje van afhankelijkheden maakt dit echter niet zo veel uit. Je businesslaag is toch altijd afhankelijk van je datalaag. Als je een nieuwe filter query opstelt dan moet je opnieuw naar je indexen kijken. Als je een kolom van je tabel wijzigt dan heb je onderhoud op je businesslaag. In welke file je je SQL plaatst verandert daar weinig aan.

Een hoop van de nadelen die hier worden aangedragen vind ik daarom een beetje aangedikt. Stored procedures zijn heus wel te versioneren en te documenteren. Het kost iets meer discipline dan inline sql, maar je hebt wel early syntax checking en een blije DBA. Onderhoudsproblemen los je op door SQL code automatisch te genereren, niet door ipv 2 kleine files 1 grote file hoeven aan te passen.

[Bobco]

whoami schreef op 31 augustus 2004 @ 20:18:
Verschillende DB's zouden allemaal dezelfde DAL moeten gebruiken als ze dezelfde DB benaderen.

Is ook niet echt handig in een multi-language omgeving. Als ik je goed begrijp moet er dus een universele benaderingslaag zijn, ook al hebben de verschillende applicaties totaal verschillende manieren van databenaderen (transacties vs batch, bijvoorbeeld). Die DAL moet al die dingen in zich hebben en op het moment dat er iets in 1 van de gebruikende applicaties wijzigt waardoor de DAL wijzigt moeten er x applicaties opnieuw getest worden.

[MSalters]

Ik vind persoonlijk de ontwikkeling in DB2/MSSQL wel interessant, een .NET CLR in je database. Hoezo SP, gewoon alle code bij elkaar. Geen probleem meer met SPs die zogenaamd in je database zitten, maar toch de voordelen van een enkel proces.

[whoami]

De .NET CLR zit in de DB, waardoor je SP's in C#/VB.NET kunt maken. Echter, als je echt data-intensieve SP's moet maken, maak je die best nog in T-SQL.

[EfBe]

MSalters schreef op 31 augustus 2004 @ 20:57:
Ik vind persoonlijk de ontwikkeling in DB2/MSSQL wel interessant, een .NET CLR in je database. Hoezo SP, gewoon alle code bij elkaar. Geen probleem meer met SPs die zogenaamd in je database zitten, maar toch de voordelen van een enkel proces.

Inderdaad. Ik vermoed dat dit echter de nodige problemen zal gaan geven: DBA's willen veelal niet vreemde code in hun db's en als daar ineens een paar MB C# wordt neergepoot kan dat op problemen stuiten, want de DBA, kent deze C# ? Ik weet niet zeker of dit de reden is dat bv Java voor procs in Oracle niet zo vaak gebruikt wordt, maar het zou me niet verbazen.

[Brothar]

Het is al weer jaren geleden dat ik een Oracle-cursus heb doorlopen, en ik kan me herinneren dat ik destijds ook van mening was dat het gebruik van stored procedures ongewenst was, omdat daarmee wellicht een "zoekplaatje" v.w.b. de code ontstond: moet ik in het programma zoeken, of in een stored procedure ?

In wezen, het topic tot nog toe lezende, neig ik er naar toe om tóch code zowel in een programma als in stored procedures te plaatsen.
Een belangrijke overweging is de opmerking hiervoor geplaatst dat stored procedures van belang zijn bij meerdere programma's.

Daarnaast denk ik dat er heel wezenlijk een scheiding moet worden aangebracht v.w.b. de functionaliteit van de desbetreffende code.
Ik stel me hierbij voor ( - ik probeer een voorbeeld te verzinnen -) :
- een stukje code waarin bijvoorbeeld een postcode wordt gecontroleerd. Omdat het gaat om "database-functionaliteit" zou ik dat plaatsen in een stored procedure (- voorzover het natuurlijk niet automatisch in een constraint zit). Het voordeel is uiteraard dat ook andere toepassingen diezelfde functionaliteit kunnen benutten.
- een stuk code waarin diezelfde postcode wordt bewerkt, of wordt gebruikt om het volledige adres op het beeldscherm weer te geven. In wezen gaat het hier om een bewerking van een database-gegeven, en stop je dat in programma-code, ook al omdat die functionaliteit niet universeel hoeft te zijn.

Essentieel daarbij is dan - maar dat vind ik überhaupt essentieel - de documentatie.
De database heeft dan zijn eigen documentatie, evenals iedere applicatie.

[ Voor 3% gewijzigd door Brothar op 31-08-2004 21:25 ]

[Verwijderd]

Brothar schreef op 31 augustus 2004 @ 21:24:
Ik stel me hierbij voor ( - ik probeer een voorbeeld te verzinnen -) :
- een stukje code waarin bijvoorbeeld een postcode wordt gecontroleerd. Omdat het gaat om "database-functionaliteit" zou ik dat plaatsen in een stored procedure (- voorzover het natuurlijk niet automatisch in een constraint zit). Het voordeel is uiteraard dat ook andere toepassingen diezelfde functionaliteit kunnen benutten.
- een stuk code waarin diezelfde postcode wordt bewerkt, of wordt gebruikt om het volledige adres op het beeldscherm weer te geven. In wezen gaat het hier om een bewerking van een database-gegeven, en stop je dat in programma-code, ook al omdat die functionaliteit niet universeel hoeft te zijn.

Dit zijn zaken die je natuurlijk ook perfect kunt afhandelen in je DAL

[misfire]

EfBe schreef op 31 augustus 2004 @ 21:06:Inderdaad. Ik vermoed dat dit echter de nodige problemen zal gaan geven: DBA's willen veelal niet vreemde code in hun db's en als daar ineens een paar MB C# wordt neergepoot kan dat op problemen stuiten, want de DBA, kent deze C# ? Ik weet niet zeker of dit de reden is dat bv Java voor procs in Oracle niet zo vaak gebruikt wordt, maar het zou me niet verbazen.

Ik dacht dat de DBA niet belangrijk was? .NET assemblies (of Java code) op de database zijn niet bedoeld als vervanging van de business laag. Het is bedoeld om data operaties te ondersteunen met logica die niet zo makkelijk in SQL kan worden uitgedrukt, maar wel in talen als C#. De .NET assemblies draaien ook niet in hetzelfde applicatie domein als SQL server, dus je zult toch stevig moeten marshallen, goedkoop is deze truc daarom niet. In de praktijk is het toepassingsgebied niet zo groot en de extra complexiteit behoorlijk, misschien dat het daarom in Oracle nu ook niet zo veel gebeurt.

Ik weet nog wel een feature van SQL Server Yukon waar DBA's met hun ogen van gaan rollen: XQuery statements! Een boomstructuur in een kolom, waar je op kunt loopen met closures. Het kan nog lachen worden met de nieuwe SQL Server. Waar ik wel benieuwd naar ben is Object Spaces (concurrentie voor EfBe? ).

[Verwijderd]

misfire schreef op 31 augustus 2004 @ 22:33:
Waar ik wel benieuwd naar ben is Object Spaces (concurrentie voor EfBe? ).

Dan heb ik slecht nieuws voor je want ObjectSpaces is gedropped uit .NET 2.0, voornaamste reden was (als ik het met goed kan herinneren) dat de technologie teveel zou "concurreren" met o.a. WinFS en dat MS liefst met een "unified" oplossing voor O/R mapping wilde komen. De kwaliteit van ObjectSpaces zal ook vast wel een argument geweest zijn om opnieuw te beginnen.

Omdat WinFS nu ook al niet in de Longhorn Client timeframe uitkomt kun je zoals het er nu voorstaat nog tot (tenminste) 2007 wachten voordat je iets concreets van MS kan verwachten op het gebied van O/R mapping. Jammer maar helaas: op het gebied van O/R mapping heeft Java (EJB/JDO) nog veel voorsprong op .NET

[Verwijderd]

Oh ja, en om ook nog ontopic te blijven ook nog even een reactie op de oproep van de topicstarter om geen sp's meer te gebruiken.

wasigh schreef op 29 augustus 2004 @ 18:05:
De taak van een database is het opslaan en beschikbaar maken van gegevens en de integreteit van deze data garanderen.

Ik zie niet in hoe SP's geen goede bijdrage zouden kunnen leveren aan de gestelde taak. Net als views bieden ze de mogelijkheid op een complexe database met vele tientallen tabellen een API te creeeren die:

- Het voor ontwikkelaars zonder volledige kennis van de onderliggende tabelstructuur relatief eenvoudig maakt bepaalde data te selecteren (via 1 view die misschien wel data uit 10 verschillende tabellen samenvoegt) of data toe te voegen (via 1 stored procedure die data valideert en daarna toevoegt aan een aantal verschillende tabellen).

- Het via beveiligingsinstellingen mogelijk maakt de eigenlijk tabelstructuur volledig
onbereikbaar te maken, waardoor elke SELECT of INSERT via de geeigende weg (view of SP) zal moeten plaatsvinden, waardoor de integriteit van de database maar ook de performance/uptime (in een grote/complexe database kan een foute SELECT een server volledig op zijn knieeen brengen) beter gegarandeert kan worden.

- Het databaseschema te veranderen zonder dat de applicaties aangepast moeten worden.

Door een aantal mensen is gesteld dat dezelfde voordelen via een DAL bereikt zouden kunnen worden. Het grootste bezwaar tegen dit argument is echter dat het platformheterogeniteit volledig negeert. Het is binnen een bedrijf immers niet vreemd als een database tegelijkertijd wordt aangesproken door applicaties geschreven in C#, Java, en VB. Het klopt dat SOAP hier een oplossing voor zou kunnen zijn, hierdoor zou echter de complexiteit van de applicatie toenemen en de performance (drastisch) afnemen.

Kortom, ik ben het absoluut niet eens met de stelling. In iedere serieuze applicatie waarbij integriteit en beveiliging van data belangrijk is en waar sprake is van een complexe databasestructuur zijn sp's (en views) onmisbaar!

[Verwijderd]

EfBe schreef op 30 augustus 2004 @ 09:51:
Huh? EXEC databasename.dbo.procname param1... paramn
of EXEC sp_executesql ... (deze is beter, want deze cached het execution plan van aangeboden sql)

Dan heb je een shared procedure, maar hoe ga je nu tables in andere databases managen via deze shared stored procedure? Dat is het hele probleem eigenlijk.

[EfBe]

misfire schreef op 31 augustus 2004 @ 22:33:
[...]
Ik dacht dat de DBA niet belangrijk was?

Als beheerder, niet als beslisser . Ik had het over de realiteit, waarin veel DBA's gewoon dat soort beslissingen kunnen nemen, helaas.

.NET assemblies (of Java code) op de database zijn niet bedoeld als vervanging van de business laag. Het is bedoeld om data operaties te ondersteunen met logica die niet zo makkelijk in SQL kan worden uitgedrukt, maar wel in talen als C#. De .NET assemblies draaien ook niet in hetzelfde applicatie domein als SQL server, dus je zult toch stevig moeten marshallen, goedkoop is deze truc daarom niet.

Volgens mij draaien de assemblies wel degelijk in-process. Het is anders nauwelijks nuttig.

In de praktijk is het toepassingsgebied niet zo groot en de extra complexiteit behoorlijk, misschien dat het daarom in Oracle nu ook niet zo veel gebeurt.

Hmmm, maar roundtrip besparende code in de database is wel degelijk nuttig, zeker als je bv UDT's gebruikt die je dus met je javacode makkelijker kunt gebruiken.

Ik weet nog wel een feature van SQL Server Yukon waar DBA's met hun ogen van gaan rollen: XQuery statements! Een boomstructuur in een kolom, waar je op kunt loopen met closures. Het kan nog lachen worden met de nieuwe SQL Server.

Mwah... vroegâh, toen ik nog in 4GL programmeerde, werkte ik op uniVerse databases, is nu van IBM geloof ik. Dat is een database die tables in table fields toestaat, dus 3D tables zegmaar alleen dan geen cubes. Na een tijdje kom je er wel achter dat je het jezelf alleen maar moeilijk maakt

Waar ik wel benieuwd naar ben is Object Spaces (concurrentie voor EfBe? ).

Objectspaces is dead en gemoved naar WinFS, dat volgens de laatste berichten in 2007 pas komt....

[EfBe]

Verwijderd schreef op 01 september 2004 @ 03:10:
Ik zie niet in hoe SP's geen goede bijdrage zouden kunnen leveren aan de gestelde taak. Net als views bieden ze de mogelijkheid op een complexe database met vele tientallen tabellen een API te creeeren die:

- Het voor ontwikkelaars zonder volledige kennis van de onderliggende tabelstructuur relatief eenvoudig maakt bepaalde data te selecteren (via 1 view die misschien wel data uit 10 verschillende tabellen samenvoegt) of data toe te voegen (via 1 stored procedure die data valideert en daarna toevoegt aan een aantal verschillende tabellen).

Voor de discussie is het denk ik zinnig een onderscheid te maken tussen view en stored procedure.

Een stored procedure kan een abstractie niveau creeeren voor developers, klopt. Dat kan een DAL tier of BL facade tier ook, of een webservice.

- Het via beveiligingsinstellingen mogelijk maakt de eigenlijk tabelstructuur volledig
onbereikbaar te maken, waardoor elke SELECT of INSERT via de geeigende weg (view of SP) zal moeten plaatsvinden, waardoor de integriteit van de database maar ook de performance/uptime (in een grote/complexe database kan een foute SELECT een server volledig op zijn knieeen brengen) beter gegarandeert kan worden.

Inserts via views spitsen zich toe op 1 table per view. (en veel databases ondersteunen geen updatable views). De security opmerking is ook onzin, want wat wil je beveiligen en tegen wie? Je DB die benaderd wordt door een zekere app? Of wil je dat je ontwikkelaars zekere paden bewandelen bij het opvragen van data? In dat laatste geval kan ik begrijpen dat je een centrale versie van je DAL wilt, echter, daar kleven serieuze problemen aan die al eerder zijn aangekaart. En wat houd je tegen om bv je BL code ook in de DB te stoppen zodat je GUI ontwikkelaars het weer makkelijker hebben?

- Het databaseschema te veranderen zonder dat de applicaties aangepast moeten worden.

Dit zijn maar beperkte wijzigingen. Voorbeeld: jij renamet een column in een table. Jouw stored proc die de select doet levert die column af, maar jouw grid die de datatable bind waar die column ingezet wordt heet nu anders. Het groepje wijzigingen dat kan worden doorgevoerd zonder dat je je client code moet aanpassen is maar zeer gering en ik weet niet of dat nou de ellende rechtvaardigt die je doormoet wanneer je een proc wilt wijzigen omdat dat nodig is voor je client code.

Door een aantal mensen is gesteld dat dezelfde voordelen via een DAL bereikt zouden kunnen worden. Het grootste bezwaar tegen dit argument is echter dat het platformheterogeniteit volledig negeert. Het is binnen een bedrijf immers niet vreemd als een database tegelijkertijd wordt aangesproken door applicaties geschreven in C#, Java, en VB. Het klopt dat SOAP hier een oplossing voor zou kunnen zijn, hierdoor zou echter de complexiteit van de applicatie toenemen en de performance (drastisch) afnemen.

Je bedoelt webservices of het idee erachter? Als een database door zowel java als .net als php als asp / vb moet worden benaderd dan heb je een probleem en zijn procs wellicht een oplossing om de pijn wat te verzachten. Echter, wanneer je in zo'n situatie zit, kijk niet raar op als de materie gewoon onbeheerbaar wordt. Immers: een noodzakelijke proc wijziging voor de php applicatie heeft effect op alle andere applicaties, zodat je de enige juiste mogelijkheid moet kiezen: een nieuwe proc. En je ellende is geboren.

Kortom, ik ben het absoluut niet eens met de stelling. In iedere serieuze applicatie waarbij integriteit en beveiliging van data belangrijk is en waar sprake is van een complexe databasestructuur zijn sp's (en views) onmisbaar!

Ik zie de link tussen coplexe database structuur en sp's niet echt. Complex is btw niet een database van tientallen tables maar van 500 of meer. Daarvoor je procs schrijven is ondoenlijk. Dus ga je ze genereren, wat een goede dal at runtime doet, maar dan wel zonder de fixed api limitatie.

[StevenK]

Waarom zou je 'nee' zeggen tegen geoptimaliseerde, gecompileerde code ?

[gorgi_19]

StevenK schreef op 01 september 2004 @ 09:55:
Waarom zou je 'nee' zeggen tegen geoptimaliseerde, gecompileerde code ?

quote: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

There is no precompilation of stored procedure code in SqlServer. It caches execution plans for each query, also ad-hoc queries. Even better: it will parametrize queries which don't even have parameters to keep the execution plan in the cache!

Oftewel: Parametrized queries en SP's verschillen in dit opzicht niet en dat is de issue hier ook niet

[ Voor 3% gewijzigd door gorgi_19 op 01-09-2004 09:59 ]

[StevenK]

gorgi_19 schreef op 01 september 2004 @ 09:58:
[...]


[...]

Oftewel: Parametrized queries en SP's verschillen in dit opzicht niet en dat is de issue hier ook niet

Toch wel aardig dat MS zichzelf tegenspreekt. In veel studieboeken van MS staat dat SP's compiled zijn, in de manual van, in dit geval SQL2000, staat dat ze slechts geparsed en gecached zijn (en dit laatste alleen na de eerste aanroep).

I stand corrected.

[gorgi_19]

In zekere zin zijn ze ook compiled:

A stored procedure is a group of Transact-SQL statements compiled into a single execution plan.

[StevenK]

Maar in dezelfde handleiding van SQL Server lees ik ook:

stored procedure
A precompiled collection of Transact-SQL statements stored under a name and processed as a unit. SQL Server supplies stored procedures for managing SQL Server and displaying information about databases and users. SQL Server-supplied stored procedures are called system stored procedures.

[EfBe]

Een proc wordt pas geprocessed at runtime, sqlserver slaat geen gecompileerde procs op, ivm het optimaliseren van de sql at runtime.

[StevenK]

EfBe schreef op 01 september 2004 @ 12:50:
Een proc wordt pas geprocessed at runtime, sqlserver slaat geen gecompileerde procs op, ivm het optimaliseren van de sql at runtime.

Maar toch is het irritant dat de MS documentatie zichzelf daarover behoorlijk tegenspreekt.

(ik durf FB niet tegen te spreken, dat is me nog nooit goed bevallen)

[EfBe]

StevenK schreef op 01 september 2004 @ 13:11:
[...]
Maar toch is het irritant dat de MS documentatie zichzelf daarover behoorlijk tegenspreekt.

Klopt, maar die documentatie spreekt zichzelf wel vaker tegen

(ik durf FB niet tegen te spreken, dat is me nog nooit goed bevallen)

Als je argumenten hebt, be my guest

[StevenK]

EfBe schreef op 01 september 2004 @ 13:23:
[...]

Klopt, maar die documentatie spreekt zichzelf wel vaker tegen


[...]

Als je argumenten hebt, be my guest

Tja, ik weet ook dat jij je alleen maar arrogant opstelt als je heel erg zeker bent van je zaak

Ik ben in deze gewoon iets teveel op de MS documentatie afgegaan

[Verwijderd]

EfBe schreef op 01 september 2004 @ 09:20:
[...]

Voor de discussie is het denk ik zinnig een onderscheid te maken tussen view en stored procedure.

In het door mij geschetste API verhaal zie ik de views als de (get) properties van de API en de sprocs als de methods, vandaar dat ik ze beide noem. Daarnaast gelden veel van de argumenten die hier aangedragen worden tegen sprocs ook in meer of minder mate voor views ( hoort niet bij de kerntaak van de database, kan ook in de DAL, moeilijk te versioneren, leidt tot een onderhoudsprobleem) en kun je sprocs gebruiken als "parameterized views". Ik vind het derhalve niet vreemd om de twee samen te pakken.

Een stored procedure kan een abstractie niveau creeeren voor developers, klopt. Dat kan een DAL tier of BL facade tier ook, of een webservice.

Inderdaad, mijn stelling is echter dat vanwege de heterogeniteit van platforms waarmee de gemiddelde enterprise database te maken krijgt het geen slecht idee is (een deel van) de bewaking van de integriteit van de data in sprocs te doen.

Zoals je zelf zegt:

Als een database door zowel java als .net als php als asp / vb moet worden benaderd dan heb je een probleem en zijn procs wellicht een oplossing om de pijn wat te verzachten.

Well then I guess they aren't all bad, mkay Sterker nog, moet je er bij het opzetten van een echt belangrijke database niet juist rekening mee houden dat deze in zijn levensduur door meerdere platforms geraadpleegd zal moeten gaan worden? Is dat niet veel meer voor de hand liggend dan dat een database ineens naar een andere db-server (bijv. Oracle -> MSSQL) geport moet worden? Met dat laatste wordt door architecten vaak wel rekening gehouden, met dat eerste in mijn ervaring vaak te weinig.

Dat T-SQL (naar mijn weten ook in Yukon) geen namespace-achtig construct kent waardoor je de sprocs op een nette manier hierarchisch kunt onderverdelen vind ik jammer want het leidt ertoe dat je in feite een groot 'object' krijgt met vele honderden of soms zelfs duizenden 'methods'. Als je dit echter opvangt in je guidelines en er continue naar streeft om de hoeveelheid sp's zo minimaal en overzichtelijk mogelijk te houden door bijvoorbeeld:

- UPDATE en INSERT statements samen te voegen in een Save sproc
- Zoveel mogelijk met "overloading" (= parameters met default waardes) te werken
- Een hierarchische naamgeving te gebruiken zoals "Companies_People_Competences_Save"

Dan is het zeker niet onmogelijk een nuttige abstractielaag te ontwikkelen die de complexiteit in de DAL vermindert en de integriteit op een goede manier bewaakt.

Ik wil daarmee niet zeggen dat dit in alle gevallen de beste oplossing is en dat je altijd sprocs moet gebruiken, ik ben het er echter absoluut niet mee eens dat sprocs inherent slecht zouden zijn, iets wat een goede programmeur zou moeten vermijden. Dat soort stellingen, die elke nuance ontberen, vind ik sowieso onzin.

[EfBe]

StevenK schreef op 01 september 2004 @ 13:58:
[...]

Tja, ik weet ook dat jij je alleen maar arrogant opstelt als je heel erg zeker bent van je zaak

Mja, maar wellicht weet ik het ook gewoon, en als jij dat dan arrogant vindt... wellicht is het dan zaak om iets aan te nemen van een ander

Ik ben in deze gewoon iets teveel op de MS documentatie afgegaan

Dat doen er wel meer (zoals ikzelf) . Het is jammer dat die documentatie vaak door 2 groepen lijkt te worden geschreven: een deel marketing en een deel echte technische info.

[StevenK]

EfBe schreef op 01 september 2004 @ 17:09:
[...]

Mja, maar wellicht weet ik het ook gewoon, en als jij dat dan arrogant vindt... wellicht is het dan zaak om iets aan te nemen van een ander

Doe toch niet zo bescheiden. Bij je eerste MS cursus had je al vaker gelijk dan de docent lief was

Als je terugleest, zie je trouwens ook dat ik ergens al m'n ongelijk had bekend.

[Verwijderd]

Genoeg geslijmd nu .. back ontopic

[misfire]

EfBe schreef op 01 september 2004 @ 09:07:
[...]
Als beheerder, niet als beslisser . Ik had het over de realiteit, waarin veel DBA's gewoon dat soort beslissingen kunnen nemen, helaas.

Hum om toch maar op iedere slak zout te leggen, maar jij vindt dus dat een DBA wel mag beslissen om geen .NET assemblies in Yukon te laden, maar niet dat er stored procs gebruikt worden? Lijkt me allebei wel een beslisser rol.

[...]
Volgens mij draaien de assemblies wel degelijk in-process. Het is anders nauwelijks nuttig.

Er is een apart (managed) app domain voor de assemblies. Dat is ook Zoek maar eens wat voorbeelden op dan zie je vrij snel hoe het werkt. Het voornaamste verschil is dat je lokaal communiceert met de database, dus je hoeft niet door een driver/netwerk, maar verder is het echt een uitstapje naar .NET (en weer terug naar de native sql engine).

Hmmm, maar roundtrip besparende code in de database is wel degelijk nuttig, zeker als je bv UDT's gebruikt die je dus met je javacode makkelijker kunt gebruiken.

Dergelijke UDT's heb je in de praktijk dus niet zo heel vaak nodig of zijn om andere redenen niet handig. Je zou bijvoorbeeld een object als UDT kunnen nemen waar bijvoorbeeld drie properties op kunnen worden gezet. Dit object wordt dan naar het veld geserialiseerd en omgekeerd tijdens het uitlezen. In het geserialiseerde object als veld kun je echter niet indexeren op één van de drie velden, en je moet overal de objectdefinitie gebruiken om de velden te benaderen. Het geserialiseerde object beslaat bovendien meer ruimte dan alleen de som van zijn velden. Het is vaak gewoon simpeler, en altijd sneller/efficiënter om 3 kolommen met een "primitief" datatype te maken.

[...]
Objectspaces is dead en gemoved naar WinFS, dat volgens de laatste berichten in 2007 pas komt....

Damn thx dat wist ik nog niet, het is de laatste tijd ook moeilijk om bij te houden wat Microsoft allemaal schrapt in haar volgende producten.

Even ontopic trouwens: ik zie regelmatig het argument "automatisch genereren" voorbij komen als nadeel voor een stored proc. Ten eerste kun je stored procs ook automatisch genereren. Ten tweede gaat de discussie niet over automatisch genereren van SQL, maar welk plek waar de SQL staat (in de applicatiecode of in aparte stored procedures) de beste is. Het is dan natuurlijk niet eerlijk om een automatisch gegenereerde situatie te vergelijken met een situatie waarbij je alles met de hand zou doen.

[EfBe]

StevenK schreef op 01 september 2004 @ 19:30:
[...]

Doe toch niet zo bescheiden. Bij je eerste MS cursus had je al vaker gelijk dan de docent lief was

oooooh! Ben jij DIE Steven K! Leuk om je hier tegen het lijf te lopen

Als je terugleest, zie je trouwens ook dat ik ergens al m'n ongelijk had bekend.

Weet ik

[EfBe]

misfire schreef op 01 september 2004 @ 21:33:
[...]
Hum om toch maar op iedere slak zout te leggen, maar jij vindt dus dat een DBA wel mag beslissen om geen .NET assemblies in Yukon te laden, maar niet dat er stored procs gebruikt worden? Lijkt me allebei wel een beslisser rol.

Nee ik vind dat DBA's niets moeten beslissen. Ik veronderstelde alleen iets wat kan gaan gebeuren (wat ik denk dat er gebeuren gaat), niet wat er moet gebeuren.

[...]
Er is een apart (managed) app domain voor de assemblies. Dat is ook Zoek maar eens wat voorbeelden op dan zie je vrij snel hoe het werkt. Het voornaamste verschil is dat je lokaal communiceert met de database, dus je hoeft niet door een driver/netwerk, maar verder is het echt een uitstapje naar .NET (en weer terug naar de native sql engine).

Ok, bedankt voor de info. Ik heb me nog niet echt verdiept in de inner 'guts' van Yukon, (beta ligt hier wel ergens maar geen hardware over)

Damn thx dat wist ik nog niet, het is de laatste tijd ook moeilijk om bij te houden wat Microsoft allemaal schrapt in haar volgende producten.

Gaat in hetzelfde tempo als vroeger hoor, alleen nu weet je eerder wat er op stapel stond, vroeger wist je dat gewoon niet