ASP: Meer controle door database?

[Urk]

Op m'n werk programmeer ik ASP Web Applicaties, nou krijg ik van m'n manager te horen dat ik meer controle op de applicaties zou moeten uitvoeren door de database zelf i.p.v. op het web of in een query.

Voorbeeldje: Checken of een input veld leeg is:
Ik check dit normaal in de code, mijn baas zegt, doe dat in de database.
Ik kan natuurlijk in de database een rule hebben dat een veld niet NULL mag zijn, maar dan krijg ik een ADODB fout, die kan ik niet zo makkelijk onderdrukken als code.
Het lijkt me dat iets als (even simpel hoor)

If Request.Form("testveld") = "" Then
<genereer een fout en ga terug naar de vorige pagina>
End If

Mijn vraag is eigenlijk, omdat ik een beetje ben gaan twijfelen of ik dit soort dingen direct vanuit de database kan regelen i.pv. in de code?
Dit is toch niet mogelijk of heb ik het fout? M'n baas zegt dus dat ik veel meer vanuit de database kan regelen, maar volgens mij kan dat niet.

[gorgi_19]

Dat makkelijk onderdrukken kan op zich wel met een On Error Resume Next; vervolgens On Error Goto 0 (geloof ik, om deze weer uit te zetten) en vervolgens het Error object uit te lezen.

Persoonlijk vind ik het maar een gedoe om niets af te vangen in de database alles te laten controlen; de applicatie kan dat op zich ook goed. Een check op null waarden wil ik nog wel doen, maar dan houdt het ook echt wel op.
Plus ik kan een stuk secuurder controleren op de geldigheid van waarden. Foutafhandeling doe ik dus altijd in de code zelf...

[whoami]

Urk schreef op 16 oktober 2002 @ 11:50:
Op m'n werk programmeer ik ASP Web Applicaties, nou krijg ik van m'n manager te horen dat ik meer controle op de applicaties zou moeten uitvoeren door de database zelf i.p.v. op het web of in een query.

Voorbeeldje: Checken of een input veld leeg is:
Ik check dit normaal in de code, mijn baas zegt, doe dat in de database.
Ik kan natuurlijk in de database een rule hebben dat een veld niet NULL mag zijn, maar dan krijg ik een ADODB fout, die kan ik niet zo makkelijk onderdrukken als code.
Het lijkt me dat iets als (even simpel hoor)

If Request.Form("testveld") = "" Then
<genereer een fout en ga terug naar de vorige pagina>
End If

Mijn vraag is eigenlijk, omdat ik een beetje ben gaan twijfelen of ik dit soort dingen direct vanuit de database kan regelen i.pv. in de code?
Dit is toch niet mogelijk of heb ik het fout? M'n baas zegt dus dat ik veel meer vanuit de database kan regelen, maar volgens mij kan dat niet.

Jouw baas heeft gelijk.

De databank het werk laten doen (testen op constraints) is veel efficienter. Je moet gewoon alle constraints in de databank steken, dan kan die databank ook gebruikt worden door andere programma's.
Wat jouw programma dan moet doen, is gewoon de foutmeldingen die de databank geeft als er aan een constraint niet voldaan is, opvangen en een user-friendly boodschap tonen.

[whoami]

gorgi_19 schreef op 16 oktober 2002 @ 11:54:

Persoonlijk vind ik het maar een gedoe om niets af te vangen in de database alles te laten controlen;

Het is een gedoe om alles in code te controleren.
Stel dat je 2 sites hebt die gebruik maken van dezelfde databank. Voor deze 2 sites gelden natuurlijk dezelfde constraints. Als er een constraint bijkomt, of aangepast wordt, dan moet jij in uw code alles gaan nagaan en aanpassen, terwijl, als het op databank niveau gedefinieerd is, je slechts uw databank hoeft aan te passen en hier en daar in uw code een error-handler moet bijschrijven.

de applicatie kan dat op zich ook goed. Een check op null waarden wil ik nog wel doen, maar dan houdt het ook echt wel op.
Plus ik kan een stuk secuurder controleren op de geldigheid van waarden. Foutafhandeling doe ik dus altijd in de code zelf...

Je kan het in uw code ook doen, maar het is zeker zo efficient niet.

[Verwijderd]

Op deze manier kun je een error afvang zonder gebruik te maken van
On Error Resume Next.
Dat vind ik persoonlijk niet echt tof, omdat je niet 100% zekerheid hebt.

code:

<%@
         Transaction = Required
%>
<%
Response.Buffer = True

Sub OnTransactionAbort()
     Response.Clear
     
     [   Plaats je error code hier   ]

End Sub
%>

Dit zou altijd moeten werken.

[gorgi_19]

whoami schreef op 16 oktober 2002 @ 11:58:

[...]

Het is een gedoe om alles in code te controleren.
Stel dat je 2 sites hebt die gebruik maken van dezelfde databank. Voor deze 2 sites gelden natuurlijk dezelfde constraints. Als er een constraint bijkomt, of aangepast wordt, dan moet jij in uw code alles gaan nagaan en aanpassen, terwijl, als het op databank niveau gedefinieerd is, je slechts uw databank hoeft
aan te passen en hier en daar in uw code een error-handler moet bijschrijven.
[...]

Bij mij is het andersom... Mijn code staat in principe vast; mijn Data Access Layer gaat in principe alleen wijzigen. Business Logic blijft hetzelfde.

En om voor iedere database apart de constraints te gaan leggen..... Qua performance heb ik voorlopig geen probleem. Het is wel eens leuk om de efficientieverschillen te gaan bepalen tussen deze twee methoden..

[whoami]

gorgi_19 schreef op 16 oktober 2002 @ 12:07:
[...]

Bij mij is het andersom... Mijn code staat in principe vast; mijn Data Access Layer gaat in principe alleen wijzigen. Business Logic blijft hetzelfde.

En om voor iedere database apart de constraints te gaan leggen..... Qua performance heb ik voorlopig geen probleem. Het is wel eens leuk om de efficientieverschillen te gaan bepalen tussen deze twee methoden..

Simpel: bevoorbeeld een unique constraint.
Als jij gaat checken in uw code, dan heb je een extra query nodig.

[gorgi_19]

whoami schreef op 16 oktober 2002 @ 12:09:

[...]


Simpel: bevoorbeeld een unique constraint.
Als jij gaat checken in uw code, dan heb je een extra query nodig.

Even voor de duidelijkheid: Ik gebruik er wel enkele...... Het is niet zo dat ik de database volledig buitenspel zet... De zwaardere controles laat ik door de code uitvoeren. Een voorbeeld: Ik ben nu bezig met een applicatie voor een managementgame.

Een team heeft maar een invoer per ronde (is door middel van een constraint wel aan te brengen, idd.)
De totaal geproduceerde voorraad kan niet groter zijn dan het (aantal machines + nieuwe machines - verkochte machines) maal de productie per machine. Daarnaast mag het productieveld leeg zijn (wordt 0)
Deze laatste voorwaarde / error check laat ik niet door een database oplossen; het zou op zich kunnen, maar 'ik heb de code' al in handen, dus waarom niet..

Verder heb ik het geluk dat ik in .Net kan werken; de Field Validators zijn wat mij betreft ideaal. De enkele zaken die door de client-side validatie heen komen, worden dan serverside wel opgevangen.

De 'eenvoudige' constraints gebruik ik dus wel...

[Crazy D]

Voor simpele dingen, zoals kijken of een veld leeg is, vind ik dat je dat (ook) moet doen in je applicatie (en in het geval van een webapp, eigenlijk zowel client side, server side, als in de database). Maar uiteraard moet het in de db goed staan, als een bepaald veld niet leeg mag zijn, moet die voorwaarde sowieso op de database liggen. Maar, even omgedraait eigenlijk, de database is altijd "de baas". Daar moet alles goed staan, constraints en de hele rattaplan, en het in code controleren vind ik meer een extraatje. Ik gebruik de laatste tijd zoveel mogelijk stored procs die een melding terug geven over wat er niet goed was, dat is vaak toch iets begrijpelijker dat die errors die mssql af en toe tevoorschijn tovert (iig voor een gebruiker dan). En soms doe ik die checks ook wel in code, maar je kan dan als het tegenzit al gauw met een handvol check-queries komen te zitten, die de database (desnoods via een stored proc) toch echt sneller kan dan ik vanuit code (maar ja dat kan ook aan mij liggen ).

[Bobco]

gorgi_19 schreef op 16 oktober 2002 @ 12:15:
[...]
Een team heeft maar een invoer per ronde (is door middel van een constraint wel aan te brengen, idd.)
De totaal geproduceerde voorraad kan niet groter zijn dan het (aantal machines + nieuwe machines - verkochte machines) maal de productie per machine. Daarnaast mag het productieveld leeg zijn (wordt 0)
Deze laatste voorwaarde / error check laat ik niet door een database oplossen; het zou op zich kunnen, maar 'ik heb de code' al in handen, dus waarom niet..
....
De 'eenvoudige' constraints gebruik ik dus wel...

Die eerste constraint vind ik een typische bussiness rule. Het zou zo kunnen zijn dat je bijvoorbeeld iets wilt gaan toevoegen met mogelijke storingen aan machines. Dat zou betekenen dat de bussiness rule aangepast moet worden. Op zich is het correct om de controle of aan deze rule is voldaan in je business logic te leggen en niet in je database.

Mijn uitgangspunt is altijd dat je een systeem moet opzetten rond een datamodel. Dat betekent niet dat je eerst het datamodel helemaal uitwerkt en dan pas aan de rest begint, maar dat je zorgt voor een stabiel datamodel dat zonder conversies een aantal versies van het systeem kan ondersteunen.

Het gaat er dus om om te herkennen welke constraints 'vast' zijn en welke niet. De eerste laat je afhandelen door de database, de tweede door de code. Overigens kan deze code ook prima een stored procedure zijn, op die manier kun je erg makkelijk code tussen verschillende systemen delen.

[whoami]

[nohtml]

Crazy_D schreef op 16 oktober 2002 @ 12:38:
Voor simpele dingen, zoals kijken of een veld leeg is, vind ik dat je dat (ook) moet doen in je applicatie (en in het geval van een webapp, eigenlijk zowel client side, server side, als in de database). Maar uiteraard moet het in de db goed staan, als een bepaald veld niet leeg mag zijn, moet die voorwaarde sowieso op de database liggen.

Idd. De constraint moet er wel zijn, maar zo'n dingen controleer ik ook wel in m'n code.

[Verwijderd]

De constraints op de database moeten er zijn om de integeriteit van de database te bewaren, maar het is meestal zinvol om ook in de code al fouten af te vangen. Als je met een paar regels code de fout kan afvangen is het zonde om een database connectie te gaan opnenen om het daar fout te laten gaan.

Aan de andere kant kan je soms gewoon niet weten of er iets fout is tot je het fout laat gaan. Denk aan het inserten van een username, die blijkt al te bestaan. Natuurlijk kan je dan vantevoren een query gaan doen of een naam al in de database bestaat, maar dan maak je het jezelf nodeloos moeilijk. Zet gewoon een UNIQUE constraint op de kolom, en handel je fout netjes af, en je bent klaar.

Het is lastig om soms precies de lijn te trekken wat je wel in code moet afvangen. Denk er vooral over na waarom je het evt. in je code wil doen, of waarom alleen op de DB. Zolang je een goede reden kan bedenken, zit het wel goed.

NB: Als je op 2 plaatsen checks gaat bouwen, krijg je er wel een probleem bij, nl. onderhoud. Als je de check op plaats 1 aanpast maar plaats 2 niet, ontstaat de grootst mogelijke problemen. Wees je daar wel van bewust, en voer wijzigingen systematisch uit.

HTH

[akakiwi]

Ik heb hier nog nergens voorbij zien komen dat die checks ook allemaal in Javascript te doen zijn. Daarmee ontlast je de server, en houd je de applicatie snel voor de gebruiker.

Zo ondervang ik altijd alles tenminste.

[whoami]

akakiwi schreef op 17 oktober 2002 @ 10:33:
Ik heb hier nog nergens voorbij zien komen dat die checks ook allemaal in Javascript te doen zijn. Daarmee ontlast je de server, en houd je de applicatie snel voor de gebruiker.

Zo ondervang ik altijd alles tenminste.

De TS doet zijn checks nu allemaal clientside, en hij vraagt of het nu beter is om ze door de db te laten doen, zoals zijn baas zegt.
Als je de verschillende reacties doorleest, zul je zien dat bepaalde checks beter clientside kunnen, en andere dan weer best door de databank gedaan worden.

IMHO, alle checks die je kunt doen zonder dat je een databank-connectie nodig hebt (zoals controleren of een veld leeg is), doe je best client-side.
Controles waar je wel een databank-connectie voor nodig hebt (zoals een unieke waarde), laat je best door de db doen.

[akakiwi]

'Tuurlijk.
Misschien een beetje raar door me geformuleerd, maar wat je daar schrijft is precies wat ik met mijn response bedoelde.

[Crazy D]

Clientside als in een webapp waar clientside javascript in de browser is, is imho nooit een veilige check. Checks in javascript doe je imho alleen maar om de gebruiker direct feedback te kunnen geven, ipv dat ie moet wachten tot z'n 56K modempje de pagina gepost heeft, en daarna opnieuw binnenhaalt om de fouten te zien. Die mogen imho nooit definitief zijn. Dus alle checks op verplichte invoer die je clientside doet, moet je sowieso op de server nogmaals checken. (want wat nou als iemand, bewust of onbewust, javascript uit heeft staan....).