[Alg] SQL queries hardcoden of ergens anders opslaan?

[pjonk]

Zelf heb ik altijd SQL statements gehardcode. Sinds kort werk ik met parameterized queries waardoor ik queries netter en veiliger (tegen SQL injection) kan formuleren, bijv:

code:

SQL = "INSERT INTO MyTable (ID,CurrencyField,TextField,BooleanField,DateTimeField,MemoField)"
SQL = SQL & " VALUES (@id,@cf,@tf,@bf,@dtf,@mf)"
dbObject.SqlQuery = SQL

' Defineer parameters
dbObject.AddParameter "@id", adBigInt, txtID
dbObject.AddParameter "@cf", adCurrency, txtCurrency
dbObject.AddParameter "@tf", adBSTR, txtText
dbObject.AddParameter "@bf", adBoolean, chkBoolean
dbObject.AddParameter "@dtf", adDate, txtDate
dbObject.AddParameter "@mf", adBSTR, txtMemo
dbObject.Execute

Echter aangezien ik nu een soort query template heb en geen strings meer hoef te concatten voor een query zou ik het SQL statement tbv overzichtelijkheid en onderhoudbaarheid ook ergens buiten de code kunnen opslaan. Nu zat ik te denken aan een Resource file, als volgt:

code:

Stringtable
Begin
    1001, "INSERT INTO MyTable
(ID,CurrencyField,TextField,BooleanField,DateTimeField,MemoField)
VALUES (@id,@cf,@tf,@bf,@dtf,@mf)"
end

Maar er zijn misschien wel betere methoden. Daarom zou ik eens willen weten hoe jullie dit aanpakken (Stored Procedures dan even buiten beschouwing gelaten)

[Orphix]

Om wat voor applicatie gaat het? In principe kan je het gewoon hardcoden aangezien de database schema vast blijft liggen. Wanneer dit verandert zal meestal toch een re-compile nodig zijn en kan je ook de queries aanpassen.

Het gaat meer om het idee waar je de queries opslaat. Jij wilt het in een resource file opslaan, maar ik zie niet echt de meerwaarde ervan in. Een query die tussen andere code staat heeft meer context en is makkelijker te begrijpen dan 30 queries onder elkaar in een tekstbestand.

Als je met een aparte laag tussen je front-end en je database, de businesslaag, werkt dan plaats je daar in het algemeen je queries. Als je niet zo'n extra laag hebt is het vooral zorg dat je je queries altijd slechts 1x specificeert. Dit zet je in een methode die je dan vanuit andere methodes aanroept. Op deze manier houdt je controle en zicht op wat je moet veranderen wanneer het database schema verandert.

[pjonk]

Orphix schreef op maandag 07 februari 2005 @ 20:07:
Het gaat meer om het idee waar je de queries opslaat. Jij wilt het in een resource file opslaan, maar ik zie niet echt de meerwaarde ervan in.

Ik momenteel ook nog niet, maar de voornaamste reden is het tegengaan van vervuiling in de code door ellenlange SQL statements die geconcat moeten worden. Dit is een VB6 App en een VB probleem is dat het geen multiline strings ondersteunt, dit werkt niet:

code:

SQL = "INSERT INTO MyTable
  VALUES (@1,@2,@3"

maar dit wel:

code:

SQL = "INSERT INTO MyTable"
SQL = SQL & " VALUES (@1,@2,@3"

En ja dit is meer een VB probleem, want in PHP kon ik mijn SQL queries wel vrij overzichtelijk uitlijnen.

Een query die tussen andere code staat heeft meer context en is makkelijker te begrijpen dan 30 queries onder elkaar in een tekstbestand.

Daar heb je wel een sterk punt.

Als je met een aparte laag tussen je front-end en je database, de businesslaag, werkt dan plaats je daar in het algemeen je queries.

Dit klinkt wel interessant. Waar kan ik voorbeelden vinden van zo'n constructie? De gebruikte taal is voor mij niet van belang het gaat mij meer om het concept.

[Gert]

sql = "blabla" & _
"bla"
zou anders ook moeten werken

[Bergie]

JonkieXL schreef op maandag 07 februari 2005 @ 20:58:
[...]
Dit klinkt wel interessant. Waar kan ik voorbeelden vinden van zo'n constructie? De gebruikte taal is voor mij niet van belang het gaat mij meer om het concept.

Dit staat bekend als het Three-Tier-Model.

Daarin heb je een datalaag, een applicatielaag en een presentatielaag.

[raptorix]

Waarom zou je je queries niet multiline kunnen neerzetten?

Je kan toch een string toch afbrkene met een underscore in vb?

[OZ-Gump]

Het nadeel van het extern opslaan van je queries is dat ze natuurlijk wel weer sneller hackable zijn. Mijn oplossing is meestal, ook omdat je zo'n query vaak meer dan één keer gebruikt, om er public consts van te maken, met een naam die duidelijk is, zoals

C#:

public const string QRY_DELETE_KLANT_BY_ID = "Delete from klant where klant.id = @klantID";

Omdat ik echter met een datalaag werk, kan ik de consts private houden...