[alg] minimale inserts, verder alleen updates?

[PanMan]

Hoi!
Ik maak nogal wat DB driven sites. Daarvoor zijn veel backends natuurlijk diverse formuliertjes. En dan met name voor elke table een insert en een update form. Die vrijwel hetzelfde eruit zien, natuurlijk. Nadeel hiervan is dat je bij elke aanpassing aan de db of aan de form, deze aanpassing op 2 plaatsen moet doorvoeren. En voor veranderende velden ook nog 2x in de verwerk pagina's. (en vaak ook nog in de frontend, natuurlijk.)
Nu zit ik voor een nieuw projectje een andere aanpak te overwegen: Alleen een minimale insert, en vervolgens maar 1 formulier ontwerpen voor het edditen van gegevens, aan de hand van het ID van de insert. Als er dan een nieuw item wordt gemaakt, zit je feitenlijk te edditen in al bestaande, lege, gegevens.
Heeft iemand hier nadelen voor? Behalve dat het misschien een theoretisch iets minder mooie oplossing is, lijkt het me wel praktischer werken. (die ene extra query lijkt me totaal verwaarloosbaar, qua load).
(btw, ik maak sites meestal met PHP/MySQL, maar volgens mij is dit voor elke webbased oplossing een 'probleem').

[RobIII]

Volgens mij werk je gewoon een beetje verkeerd
Post gewoon heel de reut naar save.php (in mijn geval save.asp ) en doe daar het volgende:

code:

Als Actie="nieuw" Then
  Insert
Else
  Update
End Als

Ik doe het meestal nog een tikkie anders: Ik heb meestal een StoredProcedure (UpdateMember bijvoorbeeld). Die heeft als parameters het Member ID, Naam, Email enzovoorts. Als het ID>0 dan is het een bestaande member en dien ik 'm te updaten (mits controles als wachtwoord e.d. goed zijn natuurlijk) en is het ID<0 (-1 in mijn geval altijd) dan is het een nieuwe member.
De stored Procedure laat ik dan uitzoeken wat het ID is en afhankelijk daarvan een insert of update doen en het nieuwe/gewijzigde ID teruggeven.

Een "uitgekleed" voorbeeldje:

code:

CREATE PROCEDURE [sp_UpdateProduct]
    @intID as int,
    @strCode as varchar(10),
    @strOmschrijving as varchar(100),
    @intDefAantal as int,
    @cPrijs as money,
    @intBTWCID as int
AS

SET nocount ON

BEGIN TRANSACTION 
IF @intID>0 
BEGIN
    UPDATE tbl_Producten Set
        prod_code = @strCode,
        prod_omschrijving = @strOmschrijving,
        prod_defaultaantal = @intDefAantal,
        prod_btwc_id = @intBTWCID,
        prod_prijs = @cPrijs
    Where prod_ID = @intID
    IF @@error <> 0 GOTO _error
END
ELSE
BEGIN
    INSERT INTO tbl_Producten (
        prod_code, prod_omschrijving, prod_defaultaantal, prod_btwc_id, prod_prijs
    ) VALUES (
        @strCode, @strOmschrijving, @intDefAantal, @intBTWCID, @cPrijs
    )
    IF @@error <> 0 GOTO _error
    SET @intID = @@IDENTITY
END

_exit:
BEGIN
    COMMIT TRANSACTION
    set nocount off
    SELECT @intID AS success
    RETURN
END
_error:
BEGIN
    ROLLBACK TRANSACTION
    set nocount off
    SELECT -1 AS success
    RETURN
END

GO

Het grappige is dat je in je PHP/ASP/Whatever je dus geen zorgen hoeft te maken of het een nieuw of bestaand record is. Je stampt gewoon tegen dezelfde Stored Procedure aan met dezelfde parameters. En je kunt je SP centraal aanpassen (dus maak je er een parameter bij, dan zit je meteen in de buurt van de update en insert). En dan heb ik het nog niet over de overige voordelen van SP's

Nu heb je in MySQL geen stored procedures, maar ik kan me voorstellen dat je gewoon een PHP include maakt met daarin dus functies als UpdateMember(id,name, email...) en dus die functies gewoon aanroept. In die functies doe je dezelfde "If ID>0"-test et voila. Je kunt nu vanuit iedere pagina gewoon tegen die functie aan stampen (mits je de juiste includes meeneemt etc. natuurlijk) alsof het SP's waren.

[ Voor 201% gewijzigd door RobIII op 10-03-2005 16:29 ]

[PanMan]

Met 1 save.php moet je natuurlijk nogsteeds 2 verschillende code's aanpassen voor een verandering in tabelstruktuur, alleen zitten deze nu in hetzelfde bestand..
En, ik had het er vooral over dat je ook maar 1 form hoeft te maken, voor edits, ipv 2 verschillende. Dat los je ook niet op met 1 eenduidige save.

[RobIII]

PanMan schreef op vrijdag 11 maart 2005 @ 01:51:
Met 1 save.php moet je natuurlijk nogsteeds 2 verschillende code's aanpassen voor een verandering in tabelstruktuur, alleen zitten deze nu in hetzelfde bestand..

Daarom zeg ik ook dat je het nog beter in een functie kunt stoppen. Je zult toch Update en Inserts blijven houden en het dus op 2 plaatsen aan moeten passen. Als je dat lekker centraal in een functie (in een include) doet heb je de minste problemen met het aanpassen. Ik zou niet weten hoe je het anders zou moten doen.

PanMan schreef op vrijdag 11 maart 2005 @ 01:51:
En, ik had het er vooral over dat je ook maar 1 form hoeft te maken, voor edits, ipv 2 verschillende. Dat los je ook niet op met 1 eenduidige save.

Pseudo-code voorbeeldje:

code:

<%
MYID = Request.querystring("id")
If MYID > 0 ' Klant ophalen uit database
  Select_from_database_blabla("id = " + MYID )
  'vangen wat je doet als de klant niet bestaat blabla
  MyName= Database_blabla("Name")
  MyAddress = Database_blabla("Address")
else
  MYID = -1
  MyName = "Nieuwe klant"
  MyAddress = "voer uw adres is"
end if
%>

<form name="frmTest" action="save.php" method="post">
     <input type="hidden" name="hdID" value="$MYID">
     Naam : <input name="txtName" type="text" value="$MyName"><br>
     Adres : <input name="txtAddress" type="text" value="$MyAddress "><br>
     ...
     ...
</form>

vervolgens vul je met PHP het ID. Gebruik >0 voor een bestaande persoon, <0 voor een nieuwe. (Ik gebruik altijd -1). Ik zie niet waarom je daar 2 forms voor zou moeten maken. En dat los je dus wel degelijk op met 1 form. Ik gebruik het al jaren zo. 1 form voor inserts en updates.

Iets zegt me (gezien je homepage http://www.panman.nl ) dat je met een WYSIWYG editor ofzo werkt en je code dus niet "zelf" of beter: "met de hand" schrijft. Ik denk dan ook dat je een te "omslachtige" methode hebt aangeleerd. Maar ik kan me natuurlijk vergissen.

Kun je anders eens een voorbeeld geven van hoe je het nu doet en wat je bedoelt?

[ Voor 27% gewijzigd door RobIII op 11-03-2005 02:18 ]

[Gomez12]

Gewoon dynamisch je sql opbouwen, dat je gewoon alle velden definieert in je code en dan adhv update/nieuw of een update statement genereren of een insert statement genereren. Een database verandering is dan maar 1x je velden veranderen en de rest volgt vanzelf ( als je het goed doet )

[Skinkie]

Gomez12 schreef op vrijdag 11 maart 2005 @ 02:35:
Gewoon dynamisch je sql opbouwen, dat je gewoon alle velden definieert in je code en dan adhv update/nieuw of een update statement genereren of een insert statement genereren. Een database verandering is dan maar 1x je velden veranderen en de rest volgt vanzelf ( als je het goed doet )

zou je dus net zo goed semantisch je database kunnen genereren, dan is de vraag, waarom zou je SQL nog willen gebruiken

[Rotjeknor]

PanMan schreef op donderdag 10 maart 2005 @ 16:15:
Nu zit ik voor een nieuw projectje een andere aanpak te overwegen: Alleen een minimale insert, en vervolgens maar 1 formulier ontwerpen voor het edditen van gegevens, aan de hand van het ID van de insert. Als er dan een nieuw item wordt gemaakt, zit je feitenlijk te edditen in al bestaande, lege, gegevens.

Dit is precies de manier waarop ik het al tijden doe. Mijn 'gestandariseerde' manier van werken gaat via 1 form voor add/edit en 1 formulier voor remove. In het form van add/edit is in principe zo goed als alles gelijk voor add/edit, afgezien van bv een vinkje om meerdere keren een item in te kunnen voegen zonder steeds op de overzichtpagina op 'nieuw item' (or whatever) te moeten klikken.

In mijn geval heb ik nog wel aparte afhandeling van de data, alhoewel dat ook eens op de schop moet omdat inderdaad zo goed als alles gelijk is (afgezien van de insert/update dus). Voor mij is echter de consistentie in mijn code erg belangrijk (anders raak ik het spoor bijster), dus als ik dit verander moet het gelijk voor al m'n websites.

[PanMan]

RobIII schreef op vrijdag 11 maart 2005 @ 02:14:

Daarom zeg ik ook dat je het nog beter in een functie kunt stoppen. Je zult toch Update en Inserts blijven houden en het dus op 2 plaatsen aan moeten passen. Als je dat lekker centraal in een functie (in een include) doet heb je de minste problemen met het aanpassen. Ik zou niet weten hoe je het anders zou moten doen.

vervolgens vul je met PHP het ID. Gebruik >0 voor een bestaande persoon, <0 voor een nieuwe. (Ik gebruik altijd -1). Ik zie niet waarom je daar 2 forms voor zou moeten maken. En dat los je dus wel degelijk op met 1 form. Ik gebruik het al jaren zo. 1 form voor inserts en updates.

Iets zegt me (gezien je homepage http://www.panman.nl ) dat je met een WYSIWYG editor ofzo werkt en je code dus niet "zelf" of beter: "met de hand" schrijft. Ik denk dan ook dat je een te "omslachtige" methode hebt aangeleerd. Maar ik kan me natuurlijk vergissen.
Kun je anders eens een voorbeeld geven van hoe je het nu doet en wat je bedoelt?

Ik denk dat je je inderdaad vergist . Ik begrijp dat m'n homepage niet een heel uitgebreide indruk geeft, van mijn werk, maar zolang ik zo genoeg werk heb, heeft die nooit echt veel prioriteit gehad. Ik schrijf iig al mijn code zelf, in Ultraedit.
Dat je toch altijd inserts en updates houd is dus niet helemaal waar: Ik stel dus voor om alleen een minimale insert te doen, waarbij niets wordt opgeslagen behalve een nieuwe row.
Die nieuwe row kan je dan altijd met updates bewerken. En daardoor heb je dus nog maar 1 query die je aan hoeft te passen, en alleen een form voor updates, geen inserts. (want die zijn altijd een heel simpele query, die niet zal veranderen). Zal zo even een voorbeeldje posten.

[RobIII]

PanMan schreef op vrijdag 11 maart 2005 @ 11:34:
Ik denk dat je je inderdaad vergist . Ik begrijp dat m'n homepage niet een heel uitgebreide indruk geeft, van mijn werk, maar zolang ik zo genoeg werk heb, heeft die nooit echt veel prioriteit gehad. Ik schrijf iig al mijn code zelf, in Ultraedit.

Ik ken het probleem ( http://www.devcorner.nl )

PanMan schreef op vrijdag 11 maart 2005 @ 11:34:
Dat je toch altijd inserts en updates houd is dus niet helemaal waar: Ik stel dus voor om alleen een minimale insert te doen, waarbij niets wordt opgeslagen behalve een nieuwe row.
Die nieuwe row kan je dan altijd met updates bewerken. En daardoor heb je dus nog maar 1 query die je aan hoeft te passen, <knip>

Je hebt dan dus nog steeds een insert en een update. Ik zie het alleen maar als overhead als je eerst een "lege" row insert en vervolgens gaat updaten. Zoals al vaker aangegeven hier: Waarom bouw je je query niet dynamisch (maak voor mijn part een array met veldnamen en maak a.d.h. daarvan een update of insert) of gebruik je geen SP?
En hoeveel werk heb je nou werkelijk als er 1 veldje bij komt? In mijn voorbeeld (met de SP) moet je op 2 plaatsen (binnen dezelfde SP!) een veldnaampje typen. Hoewel dat misschien inderdaad meer typewerk is (goh, 15 tekens ofzo...) komt dat de overzichtelijkheid wel ten goede denk ik.

PanMan schreef op vrijdag 11 maart 2005 @ 11:34:
...en alleen een form voor updates, geen inserts. (want die zijn altijd een heel simpele query, die niet zal veranderen). Zal zo even een voorbeeldje posten.

En nogmaals: Ik gebruik ook "maar" 1 form voor inserts én updates. Ik zie niet waar je het idee vandaan haalt om 2 (of meer?) forms te moeten gebruiken voor een insert / update Is toch een kwestie van een ander ID posten (of voor mijn part een "action" ofzo met value "new" of "update").

[ Voor 27% gewijzigd door RobIII op 11-03-2005 11:45 ]

[LuCarD]

Ik heb een class gemaakt die voor insert en update bij dezelfde argumenten krijgt.

PHP:

$dbclass->insert("<TABLENAME>", $array);
// of
$dbclass->update("<TABLENAME>", $array, "<WHERE CLAUSE>");

De array is als volgt opgebouwd.

PHP:

$array = array ("<DB_FIELDNAME>" => $data);

In de in db class word alle strings geescaped en veilig de database in gegooid.

Het grootte voordeel van deze manier bijna rechtstreeks form data in de database kan posten.

[DaCoTa]

Daarnaast kun je met een lege insert geen enkele kolom op de PK na verplicht maken, behalve door het in code op te vangen. Ook heb je nogal wat overhead als je een paar indexen gebruikt die dan twee maal bijgewerkt moeten worden.

[djluc]

Is het gebruiken van een form-class niet gewoon de oplossing op je probleem?