[(MS) SQL] Belang van constraints, indices etc.

[Eelke Spaak]

Ik ben een beetje overwhelmed door alle mogelijkheden van MS SQL Server 2000, omdat ik daar onlangs voor ben gaan ontwikkelen. Voorheen heb ik weleens wat met MySQL geprogrammeerd (i.c.m. ASP en PHP), en ik merk nu dat MS SQL véél meer te bieden heeft. (Misschien zit sommige van deze functionaliteit ook wel in MySQL, maar daar is het me nooit opgevallen en in de meeste tutorials wordt het ook niet behandeld.)

Wat nu mijn punt is: ik gebruik heel veel van die functionaliteit niet. Is het een schande als ik geen constraints specificeer op mijn kolommen? Komt het de performance ernstig ten slechte als ik niet bij elke id-referencing kolom een foreign key specificeer?

En als laatste: ik heb (onwetend als ik ben) een totaal cascade-delete script geschreven in ASP. Daarnet kwam ik erachter dat deze functionaliteit al standaard in MS SQL zit. Is het verstandig dat te gebruiken of is het ook wel goed als ik het gewoon script?

Graag heb ik jullie mening over deze zaken .

[ Voor 3% gewijzigd door Eelke Spaak op 16-05-2004 21:34 ]

[Jaspertje]

Over het laatste: Tuurlijk is het beter om cascade delete in je SQL op te lossen ipv in je ASP. Buiten het feit dat het veiliger is (qua echtheid van je data), is het ook x keer sneller..

[ Voor 6% gewijzigd door Jaspertje op 16-05-2004 21:42 ]

[bigtree]

Vladimir G. schreef op 16 mei 2004 @ 21:33:
[...]En als laatste: ik heb (onwetend als ik ben) een totaal cascade-delete script geschreven in ASP. Daarnet kwam ik erachter dat deze functionaliteit al standaard in MS SQL zit. Is het verstandig dat te gebruiken of is het ook wel goed als ik het gewoon script?

Door je dbms dit te laten regelen, heb je minder kans op een niet-integere database. Ik zou dit door je dbms laten doen.

[curry684]

Vladimir G. schreef op 16 mei 2004 @ 21:33:
Is het een schande als ik geen constraints specificeer op mijn kolommen?

Nee, constraints worden zelden gebruikt en zijn alleen nuttig in zeer specifieke gevallen.

Komt het de performance ernstig ten slechte als ik niet bij elke id-referencing kolom een foreign key specificeer?

Ja, een foreign key met bijbehorende index leggen kan je een factor 10 tot 1000 in snelheid schelen op een tabel met veel rijen. Leg altijd een non-clustered index op een foreign key dus.

En als laatste: ik heb (onwetend als ik ben) een totaal cascade-delete script geschreven in ASP. Daarnet kwam ik erachter dat deze functionaliteit al standaard in MS SQL zit. Is het verstandig dat te gebruiken of is het ook wel goed als ik het gewoon script?

Cascading deletes zijn zelden nuttig of gewenst, in veruit de meeste datamodellen wil je historische data namelijk bewaren tot Sint Juttemis. Mocht je perse cascading deletes willen uitvoeren is dit het snelste en effectiefste via de built-in support daarvoor.

[whoami]

curry684 schreef op 16 mei 2004 @ 21:44:
[...]

Nee, constraints worden zelden gebruikt en zijn alleen nuttig in zeer specifieke gevallen.

Hmm, even nuanceren. Een foreign key is eigenlijk ook een constraint.

Als een veld slechts bepaalde waarden mag bevatten (bv. enkel A, B of C, of getallen die kleiner zijn dan 100), dan is dat ook een constraint, en dergelijke dingen zijn dus wel degelijk nodig.
Als je veld enkel unieke waarden mag bevatten, kan je er ook een unique constraint op leggen, etc....

Constraints worden dus niet zelden gebruikt.

[curry684]

whoami schreef op 16 mei 2004 @ 22:15:
[...]

Hmm, even nuanceren. Een foreign key is eigenlijk ook een constraint.

Als een veld slechts bepaalde waarden mag bevatten (bv. enkel A, B of C, of getallen die kleiner zijn dan 100), dan is dat ook een constraint, en dergelijke dingen zijn dus wel degelijk nodig.
Als je veld enkel unieke waarden mag bevatten, kan je er ook een unique constraint op leggen, etc....

Constraints worden dus niet zelden gebruikt.

Pardon, ik doelde inderdaad op de "kleiner dan 100" constraints die zelden gebruikt worden (omdat ze meestal application-controlled worden geimplementeerd). Een UNIQUE constraint is wel redelijk frequent idd

[whoami]

curry684 schreef op 16 mei 2004 @ 22:18:
[...]

Pardon, ik doelde inderdaad op de "kleiner dan 100" constraints die zelden gebruikt worden (omdat ze meestal application-controlled worden geimplementeerd).

Dan nog vind ik het beter dat die constraint er ook op databank niveau ook ligt.
Dit zorgt er toch voor dat ook er ook dmv andere applicaties zowiezo geen foutieve gegevens kunnen inkomen, en het is een dubbele check zeg maar.

[curry684]

whoami schreef op 16 mei 2004 @ 22:21:
[...]


Dan nog vind ik het beter dat die constraint er ook op databank niveau ook ligt.
Dit zorgt er toch voor dat ook er ook dmv andere applicaties zowiezo geen foutieve gegevens kunnen inkomen, en het is een dubbele check zeg maar.

De vraag was niet wat 'best practice' was maar of het een schande was om het niet te doen

[whoami]

curry684 schreef op 16 mei 2004 @ 22:23:
[...]

De vraag was niet wat 'best practice' was maar of het een schande was om het niet te doen

Ik zou het toch een schande vinden.
Waarom zou je die constraints niet specifieren als ze nodig zijn, en het allemaal op applicatie-level doen? IMHO is het minder veilig als je die beperkingen op app-niveau doet , en als de constraints veranderen, dan hoef je niet in je code te duiken enzo: kans_op_fouten--
(Tenzij die check natuurlijk in je DB zit, en op app-niveau. Dan moet je ook in je code duiken).

[ Voor 11% gewijzigd door whoami op 16-05-2004 22:32 ]

[gorgi_19]

curry684 schreef op 16 mei 2004 @ 22:23:
[...]

De vraag was niet wat 'best practice' was maar of het een schande was om het niet te doen

Schande zou ik het niet noemen, maar imho is de databank verantwoordelijk voor de data rules / data integriteit.

[cameodski]

Volgens mij houdt de optimizer ook rekening met eventuele check constraints, dus het wel aanbrengen ervan, zou dus ook performance winst op kunnen leveren.

[curry684]

gorgi_19 schreef op 16 mei 2004 @ 22:33:
[...]

Schande zou ik het niet noemen, maar imho is de databank verantwoordelijk voor de data rules / data integriteit.

Mjah ik vind ook dat je geen mails moet versturen vanuit stored procedures, maar in de praktijk komt dat ook voor....

Meest gewenste situatie is zelden de meest onderhoudbare variant, en voor veel developers wel de teveel-moeite variant. Helaasch maar realiteit.

[Eelke Spaak]

Nou bedankt voor de reacties in ieder geval . Ik ga mijn database maar even droppen en opnieuw maken; het cascade-script hou ik nog wel even zo omdat het vrij veel moeite vergt om dat opnieuw te gaan implementeren (m.b.v. de built-in MS SQL support).

[cameodski]

Vladimir G. schreef op 17 mei 2004 @ 16:11:
Nou bedankt voor de reacties in ieder geval . Ik ga mijn database maar even droppen en opnieuw maken; het cascade-script hou ik nog wel even zo omdat het vrij veel moeite vergt om dat opnieuw te gaan implementeren (m.b.v. de built-in MS SQL support).

Als je het hele script dan maar wel in een transactie zet.