[ALG] zeg nee tegen Stored Procedures *

[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

[Delphi32]

Verwijderd schreef op 01 september 2004 @ 14:52:
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?

Je hebt een punt hier. Maar mijn vraag is dan wel: hoe weet jij dat de database die je NU ontwerpt voor een applicatie, straks door meerdere platforms geraadpleegd wordt ZONDER dat de oorspronkelijke code (inclusief BL laag) hergebruikt kan worden? Dit klinkt m.i. iets teveel naar "programming for the future". Ongetwijfeld kan je scenario's uit de kast trekken waaruit blijkt dat multi-platform geen hergebruik van bestaande BL-lagen met zich meebrengt, maar ik kan er tegenover zetten dat er ook scenario's denkbaar zijn waarin dit wel kan. Kern van dit punt: je weet niet wat de toekomst brengen zal. Waarom dan inflexibiliteit en complexiteit inbouwen waar dat nu niet nodig is? Zie ook mn volgende punt:

...er continue naar streeft om de hoeveelheid sp's zo minimaal en overzichtelijk mogelijk te houden door bijvoorbeeld:
...
- Zoveel mogelijk met "overloading" (= parameters met default waardes) te werken

Als er iets is waar ik als ontwikkelaar dus heel slecht mee uit de voeten kan, dan zijn het overloaded procedures en default parameter values. Imho zorgen die juist voor toename van het aantal procedures (dit is wel afhankelijk van de gebruikte taal), toename van het aantal mogelijk op te geven parameters (ik heb ooit een docent gehad die 5 parameters toch echt het maximum vond) en daarmee een verhoogde ondoorzichtigheid en onoverzichtelijkheid. Net wat je niet wilt dus.
Ik zou willen zeggen: bewijzen van de onwerkbaarheid van overloaded procedures en default parameter values liggen ter inzage, maar het project waar ik aan werk is helaas geen open source

[Verwijderd]

Delphi32 schreef op 02 september 2004 @ 00:07:
[...]
Je hebt een punt hier. Maar mijn vraag is dan wel: hoe weet jij dat de database die je NU ontwerpt voor een applicatie, straks door meerdere platforms geraadpleegd wordt ZONDER dat de oorspronkelijke code (inclusief BL laag) hergebruikt kan worden? Dit klinkt m.i. iets teveel naar "programming for the future".

Ik begrijp wat je bedoelt, wanneer is iets "programming for the future" en wanneer is iets een "best practice"? Platformheterogeniteit, abstractie en encapsulatie, betere integriteitsbeveiliging en "division of labor" (richting DBA) zijn in mijn ogen goede argumenten om sprocs te gebruiken. Aan de andere kant zie ik een POTENTIEEL onderhoudsprobleem (dat m.i. dus op een aantal manieren te bestrijden is, zie hierboven) als grootste nadeel, waarbij ik moet zeggen dat ik vind dat dit punt nog onvoldoende onderbouwd is omdat het alternatief, het verspreiden van allerlei SQL in een (al dan niet min of meer automatisch gegenereerde) DAL of -erger nog maar dan moeilijk te voorkomen- in de BLL of zelfs frontend, onderbelicht is gebleven.

Als er iets is waar ik als ontwikkelaar dus heel slecht mee uit de voeten kan, dan zijn het overloaded procedures en default parameter values. Imho zorgen die juist voor toename van het aantal procedures (dit is wel afhankelijk van de gebruikte taal)

Kun je een concreet voorbeeld geven waardoor het gebruik van overloads/defaults een wildgroei van het aantal sprocs veroorzaakt? Ik bedoel met het gebruiken van "overloads" bijvoorbeeld het combineren van UPDATE en INSERT sprocs in een. Afhankelijk van of (bijv.) een identity veld wordt meegegeven kun je bepalen wat moet worden uitgevoerd, bijv:

code:

  PROCEDURE Person_Save
    @id int = NULL,
    @name nvarchar(50)
  AS
    
     IF @id IS NULL BEGIN

         INSERT INTO.....

     END
     ELSE BEGIN

         UPDATE .....
     
     END
  GO

[EfBe]

Verwijderd schreef op 02 september 2004 @ 04:07:
Kun je een concreet voorbeeld geven waardoor het gebruik van overloads/defaults een wildgroei van het aantal sprocs veroorzaakt? Ik bedoel met het gebruiken van "overloads" bijvoorbeeld het combineren van UPDATE en INSERT sprocs in een. Afhankelijk van of (bijv.) een identity veld wordt meegegeven kun je bepalen wat moet worden uitgevoerd, bijv:

code:

  PROCEDURE Person_Save
    @id int = NULL,
    @name nvarchar(50)
  AS
    
     IF @id IS NULL BEGIN

         INSERT INTO.....

     END
     ELSE BEGIN

         UPDATE .....
     
     END
  GO

Dit performt voor geen meter. Elke execution zal de proc's execution plan opnieuw bepalen vanwege de IF. Dit soort logica hoort in je app thuis: DAAR roep je 2 routines aan, OF update, OF insert. Verder is het zo dat je bij dit soort routines dus in een update alle velden update. Bij rows waar een 1MB blob in zit en je een 4 byte integer wilt wijzigen is dat niet echt efficient

[Maasluip]

Bobco schreef op 31 augustus 2004 @ 20:10:
[...]

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.

Daar ben ik het niet helemaal mee eens.

Om te beginnen ging het over trage queries, en als ontwikkelaar moet je voldoende kennis hebben om te kunnen herkennen (en zeker te testen in een statische omgeving!) of een query traag of snel is (simpele eerste criterium: ga je over indexen bij grote tabellen? En een fout die vaak gemaakt wordt is testen met slechts een fractie aan records als in de uiteindelijke situatie). Ik heb genoeg queries en stored procedures gezien dat ik me hoofdschuddend afvroeg welke amateur dit had gemaakt (lees: processtime van een SP van 5 minuten naar 5 seconden gebracht) of zelf de handdoek in de ring heb moeten gooien met de mededeling 'deze requirement is zonder extra indexen niet performant te maken'.
En een extra index aanleggen is natuurlijk ook niet iets wat je zonder nadenken wil doen.

Dat je in een dynamische situatie nog extra problemen kunt hebben is duidelijk, en met een heel (ervaren) projektteam hebben we moeten vaststellen dat locks van queries die op zich niet zo gek lang duren wel tot gevolg kunnen hebben dat de hele applicatie niet meer werkt, maar om nu te zeggen dat een ontwikkelaar zich daar niet van bewust hoeft te zijn vind ik een beetje kortzichtig. Oogkleppen op en ieder zijn eigen hokje lees ik dan, en daar ben ik geen voorstander van.

[Bobco]

Maasluip schreef op 02 september 2004 @ 09:24:
[...]
Daar ben ik het niet helemaal mee eens.

Om te beginnen ging het over trage queries, en als ontwikkelaar moet je voldoende kennis hebben om te kunnen herkennen (en zeker te testen in een statische omgeving!) of een query traag of snel is (simpele eerste criterium: ga je over indexen bij grote tabellen?
[..]
En een extra index aanleggen is natuurlijk ook niet iets wat je zonder nadenken wil doen.
[...]
Oogkleppen op en ieder zijn eigen hokje lees ik dan, en daar ben ik geen voorstander van.

Ik begrijp denk ik wel wat je bedoelt, maar meen standpunt is dat een ontwikkelaar van een applicatie soms niet voldoende zicht heeft op wat er met een database gebeurd in een produktiesituatie waar ook andere applicaties gebruik maken van dezelfde database.

Je noemt zelf het punt van het aanleggen van extra indexen. Een index, IMHO, is een hulpmiddel voor een RDBMS om snel bepaalde rows terug te kunnen vinden. Iedereen weet dat indexen geweldig zijn voor reads, maar minder leuk voor updates. Een extreem voorbeeld: applicatie A doet alleen maar reads, applicaties B t/m G doen alleen maar updates (inserts, deletes,...).

De ontwikkelaar van applicatie A wil natuurlijk overal en nergens indexen, de ontwikkelaars van de andere applicaties zijn daar op tegen. Hier is duidelijk sprake van een belangenconflict en dat moet opgelost worden door een andere partij: de DBA. Die moet kunnen zeggen of er met een bepaald technisch datamodel de gewenste performance gehaald kan worden voor ALLE applicaties.

Een database is voor mij niets anders dan een resource die beheerd wordt door een partij die daar verstand van heeft. Met een goede DBA kun je overleggen over databasestructuren, te verwachten responsetijden en meer van dat soort dingen. Dat is geen kwestie van oogkleppen op en in je hok blijven zitten maar van gespecialiseerde kennis. Je kunt als applicatieontwikkelaar niet goed alle ins en outs van een bepaald RDBMS bijhouden. Voor 'gewone' applicaties hoeft dat ook niet, maar op het moent dat je het laatste stukje performance uit een database wilt persen heb je die kennis wel nodig.

[EfBe]

Voor 'gewone' applicaties hoeft dat ook niet, maar op het moent dat je het laatste stukje performance uit een database wilt persen heb je die kennis wel nodig.

Dit is een totaal andere discussie. Als iedere cycle telt, zijn alle consessies geoorloofd, en gebruik je dus bv geen tier-ed model, maar prak je bv een datareader direct in de gui zodat deze sneller opbouwt.

Jouw situatie die je schetst met een database waar A alleen uit leest en B, C en D in schrijven, is wat Microsoft bv heeft onderzocht en wat als uitgangspunt is genomen voor Yukon: men is beter af in zo'n situatie waarbij men 2 databases gebruikt: 1 voor A en 1 voor B, C en D. Tenzij natuurlijk A direct moet kunnen lezen wat B, C en D schrijven. In dat geval heb je gewoon te leven met de limieten die dat oplevert.

Verder is de dicussie omtrent performance leuk, maar ondergeschikt. Zodra je consessies gaat doen om maar meer performance te halen, betaal je een prijs voor die consessies: minder onderhoudbaarheid en soms hogere complexiteit in je applicatie. Het lullige is dat men dat niet beseft. Men wil EN top performance EN top onderhoudbaarheid EN een erg lage complexiteit. En dat alles ook nog eens supergemakkelijk te realiseren. Echter hoe meer performance je wilt, hoe meer je aan gemak en onderhoudbaarheid moet inleveren.

Constante = performance * onderhoudbaarheid (waarbij performance en onderhoudbaarheid >=1)

Waarom normaliseert men een datamodel uit? voor leesacties (en voor schrijfacties ook) is het niet de snelste benadering. Zomaar een voorbeeld. Men gaat dan wel steevast roepen "Ja maar normaliseren is logisch, dat is correct", maar zo simpel ligt het niet: als elke cycle telt is ook elke consessie geoorloofd, immers performance is het enige doel.

Wil je dus performance, dan ben je klaar met deze discussie. Kom dan echter niet aan met een huilverhaal dat je na 2 jaar 2 dagen per week zit te vloeken omdat het systeem zo verschrikkelijk slecht inelkaar is gezet.

[Verwijderd]

EfBe schreef op 02 september 2004 @ 09:04:

Dit performt voor geen meter.

Dat valt reuze mee hoor, en zoals je zelf een kleine drie uurtjes later zegt:

EfBe schreef op 02 september 2004 @ 11:48:
Zodra je consessies gaat doen om maar meer performance te halen, betaal je een prijs voor die consessies: minder onderhoudbaarheid en soms hogere complexiteit in je applicatie.

[...]

Wil je dus performance, dan ben je klaar met deze discussie.

Begrijp me niet verkeerd, performance is belangrijk. Maar schaalbaarheid, beveiliging en onderhoudbaarheid zijn in de meeste scenarios belangrijker. Het stukje (pseudo) code is een voorbeeld van hoe je de hoeveelheid sprocs kunt verminderen, natuurlijk kun je met een voorbeeld komen waarin dit niet de optimale oplossing is (grote BLOBs) maar dat vind ik erg flauw en niet echt nuttig voor de discussie.

[whoami]

Ff kicken.
Ik kreeg net een mailtje van Red Gate met daarin een link naar dit artikel.

Douglas Reilly stelt hier de standpunten van Rob Howard en EfBe tegenover elkaar.
Er moet wel ff gemeld worden dat die Douglas Reilly zelf ook wel een beetje een SP - advocate is denk ik, en hij komt ook tot een conclusie waar ik het al langer mee eens was:
Stored Procedures moet je niet afzweren, en je moet ze ook niet altijd blind gebruiken. Gebruik SP's wanneer het aangewezen is, en gebruik ad-hoc queries wanneer deze aangewezen zijn. Het is gewoon een afweging die je moet maken.

[curry684]

Zodra je iemand ooit een compleet workflowsysteem in HTML hebt zien rondmailen vanuit stored procedures weet je weer waarom ze kut zijn. Je gaat huilen zodra je serieus 'SELECT '<html><body><h1>' + fieldname + '</h1>' etc. in een SP ziet opduiken.

Stored procedures zijn imho voor maintenance operaties, scheduled jobs en andere terugkerende acties die op z'n tijd al of niet handmatig uitgevoerd moeten worden. Voor applicatiedevelopment is het gewoon een crime in maintenance (altijd leuk als je een localhost, devserver, testserver en productieserver moet updaten met verschillend geversioneerde SP's) en zijn ze gewoon niet op hun plaats. Een database moet data opslaan, de DB-layer van de applicatie moet het beheren. En beheert dus de queries.

[curry684]

Even nog wat meer historische discussiepunten openbreken (ik heb deze discussie vorig jaar gemist obviously wegens 2 weken vakantie ):

DrFrankenstoner schreef op maandag 30 augustus 2004 @ 00:13:
[...]

Sterker nog, views moeten uberhaupt verboden worden (behalve inlined views dan in queries en materialized views voor datawarehousing)

En federated views in SQL Server Enterprise

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.

Dat los je imho op met een 3-tier model, waarbij de applicaties tegen een service aanpraten die de data beheert en als enige ter wereld de database in kan.

[whoami]

curry684 schreef op donderdag 31 maart 2005 @ 16:23:


En federated views in SQL Server Enterprise

Nog nooit van gehoord....
Bedoel je niet 'indexed views' ?

[ Voor 9% gewijzigd door whoami op 31-03-2005 16:27 ]

[P_de_B]

whoami schreef op donderdag 31 maart 2005 @ 16:26:
[...]


Nog nooit van gehoord....
Bedoel je niet 'indexed views' ?

Ik durfde het al niet te vragen

Ik denk dat 'ie partitioned views bedoeld?

[curry684]

Uhm ja 'partitioned views' op 'federated servers', excuses Partitioned views zijn overigens per definitie federated, dus tis een beetje mierenneuken

[whoami]

P_de_B schreef op donderdag 31 maart 2005 @ 16:36:
[...]

Ik denk dat 'ie partitioned views bedoeld?

Dat bedoelde ik eigenlijk ook.

[Verwijderd]

Oh oh...daar gaan we weer

In enigszins gerelateerd nieuws: gisteren is de beta van MySQL 5.0 uitgekomen waarin voor het eerst sprocs, triggers en views zitten. Om David Axmark van MySQL te citeren (ZDNET):

"People have been criticising MySQL since we started [in 1995] for not having stored procedures, triggers and views," said Axmark. "We're fixing 10 years of criticism in one release."

Of, zoals ze bij Slashdot zeggen:

It's like it'll be a real DB!

Slecht of niet, er is blijkbaar wel degelijk behoefte aan deze zaken....

[Verwijderd]

Waarom volledig ja of nee zeggen als er ook een gulde middenweg bestaat? Hoe vaak schrijf je een applicatie die daadwerkelijk generiek op vele verschillende systemen moet draaien? Hoe genereer je primaire sleutels, progmatisch?

Verder loop ik nooit zo warm voor performance. Een dag bezig zijn met optimaliseren kost even veel als een compleet nieuwe server. Bruikbaarheid van de code heeft dus wat mij betreft voorrang.

[Annie]

Verwijderd schreef op donderdag 31 maart 2005 @ 18:24:
Verder loop ik nooit zo warm voor performance. Een dag bezig zijn met optimaliseren kost even veel als een compleet nieuwe server. Bruikbaarheid van de code heeft dus wat mij betreft voorrang.

Je vergeet dat een nieuwe server ook ingericht moet worden. En daarnaast ook meer beheer kost, meer backup-space, misschien extra rackspace, zwaardere airco, extra netwerkinfrastructuur, enz.
Als het zo simpel was zou elke IT manager, zonder er enig probleem van te maken, extra servers aanschaffen. En toch doen ze dat niet.

[Verwijderd]

Wat is er mis met stored procs?

Voorbeeld 1:
Je houdt in je database netjes bij hoeveel fietsen, strandstoelen, parasols, etc. per dag verhuurd zijn. Leuk, maar nu wil de klant een maandoverzicht.
Dan kun je je in 3 bochten wringen om client side die data op te halen en te formatteren, met als gevolg dat de client applicatie overal moet worden geupdate, maar met een stored proc is 't 1 kleine database update en een nieuw rapportje.

Voorbeeld 2:
Stel, je ontwikkeld voor meerdere databases.
InterBase kent geen autoincrementing fields, en MSSQL heeft geen flauw benul van generators. Dan is een stored proc die beide ondersteunt best wel handig.

[JaQ]

mayonaise schreef op donderdag 31 maart 2005 @ 16:19:
Zodra je iemand ooit een compleet workflowsysteem in HTML hebt zien rondmailen vanuit stored procedures weet je weer waarom ze kut zijn.

maar dat is dan ook een prototype van "hoe doe ik het niet". Kijk voor de grap eens naar HTMLDB (van oracle). Daarmee kan je een website bouwen mbv stored procedures (via de al oude web util toolkit voor plsql, oftewel een mod_plsql voor apache). Een stored proc maken die je layout afhandeld (en css etc. etc.) icm met wat tabellen met je data (bv inhoud van css) kan prima en is imho zeker niet fout. Grootste voordeel (en nou ga ik ruzie maken): geen noodzaak voor (o.a.) bloated java programmeur die af lopen te geven op DBA's "omdat die niet kunnen ontwikkelen". _{deze semi-dba voelt zich dus aangesproken en op z'n pik gertapt. Misschien wel omdat ik ook al jaren ontwikkeld heb en tegenwoordig meer analist ben dan DBA} Traditionele DBA's die alleen een database kunnen managen zijn dinosaurussen die bijgeschoold moeten worden en daar is binnen nu en 5 jaar geen plaats meer voor. (imnsho)

mayonaise schreef op donderdag 31 maart 2005 @ 16:19:
Stored procedures zijn imho voor maintenance operaties, scheduled jobs en andere terugkerende acties die op z'n tijd al of niet handmatig uitgevoerd moeten worden. Voor applicatiedevelopment is het gewoon een crime in maintenance (altijd leuk als je een localhost, devserver, testserver en productieserver moet updaten met verschillend geversioneerde SP's) en zijn ze gewoon niet op hun plaats. Een database moet data opslaan, de DB-layer van de applicatie moet het beheren. En beheert dus de queries.

mayonaise schreef op donderdag 31 maart 2005 @ 16:23:

En federated views in SQL Server Enterprise

gepartitioneerde tabellen (in oracle enterprise server) is anders ook niet verkeerd (scheelt weer zo'n klote view )

mayonaise schreef op donderdag 31 maart 2005 @ 16:23:
Dat los je imho op met een 3-tier model, waarbij de applicaties tegen een service aanpraten die de data beheert en als enige ter wereld de database in kan.

[/quote]

en die "service" kan natuurlijk bestaan uit stored procedures Je voert dus geen DML uit, maar roept een SP aan. Ik zeg niet dat het heilig is, maar het is imho ook niet verkeerd.

_{damn... ik moet je wel hebben}

[Verwijderd]

Annie schreef op donderdag 31 maart 2005 @ 22:55:
[...]

Je vergeet dat een nieuwe server ook ingericht moet worden. En daarnaast ook meer beheer kost, meer backup-space, misschien extra rackspace, zwaardere airco, extra netwerkinfrastructuur, enz.
Als het zo simpel was zou elke IT manager, zonder er enig probleem van te maken, extra servers aanschaffen. En toch doen ze dat niet.

idd. Vergeet ook niet dat een beetje server, zeker als ie sneller moet zijn dan de oude (die je als je jouw visie volgt nog niet zo lang hebt), toch al snel zo'n 2000 euro kost minimaal. Zit je op een goede quad DB bak dan is 10.000 meer het minimum.

Als jij 2000 euro per dag verdient, dan wil ik graag eens even met je baas gaan babbelen.

[whoami]

Scott Bellware's commentaar nav de RedGate mail.
Zijn 'point of view' is wel goed, en hij raakt ook de essentie.

[ Voor 27% gewijzigd door whoami op 01-04-2005 09:20 ]

[EfBe]

Niet weer... wanneer gaan mensen eens ophouden met deze non-discussie...
Bedankt voor de link, Whoami, Scott heeft het begrepen.

[Kwistnix]

Er zijn genoeg argumenten tegen het gebruik en genoeg argumenten voor het gebruik van stored procedures, maar mijns inziens is het toch de situatie die dicteert of het gebruik van stored procedures wel of geen goede oplossing is. SP's zijn een middel; geen doel.

[ Voor 3% gewijzigd door Kwistnix op 08-04-2005 17:25 ]

[NMe]

Op verzoek een post van leeko verwijderd, omdat deze hier een nieuw topic over heeft geopend.

[Verwijderd]

Verwijderd schreef op vrijdag 01 april 2005 @ 00:43:
idd. Vergeet ook niet dat een beetje server, zeker als ie sneller moet zijn dan de oude (die je als je jouw visie volgt nog niet zo lang hebt), toch al snel zo'n 2000 euro kost minimaal. Zit je op een goede quad DB bak dan is 10.000 meer het minimum.

Als jij 2000 euro per dag verdient, dan wil ik graag eens even met je baas gaan babbelen.

Ohja dit was tweakers heh, mijn fout. Hier lezen de meeste mensen alles letterlijk waar af en toe ook figuurlijk gelezen dient te worden. Ik gooi deze post maar onder het kopje sarcasme...