[SQL]wijzigingen in meerdere tabellen

[pkouwer]

Ik zit met een vraagstuk waarbij ik in 1 tabel records moet verwijderen, terwijl er in een andere tabel records aangepast moeten worden en er een derde tabel bij betrokken is. Ik zal de tabellen met velden even benoemen, zodat e.e.a. duidelijker wordt:

inlist

name

badge

reader

facility

reader

pnlref

rdrno

description

badge

enabled

lastname

firstname

badge

facility

remarks

lvdate

lvrdr

de volgende relaties zijn van toepassing:
inlist.badge=badge.badge
inlist.facility=badge.facility
inlist.reader=reader.description

nu is het de bedoeling dat er records uit de inlist verwijderd worden die een reader hebben die niet in de tabel reader staan. tevens moeten de (bijbehorende) records uit de tabel badge bijgewerkt worden. Ik wil dit in 1 query stoppen, maar ik kom er niet uit. Dit is wat ik aan queries heb:

code:

update inlist
set name="drop me" 
where reader not in
   (select description from reader)
go
update badge
set enabled=0
where 
badge.badge=inlist.badge and
badge.facility=inlist.facility
go;

delete from inlist where name=" drop me"

alles in een try/catch block. Mijn vraag is eigenlijk of dit niet eenvoudiger kan, of dat ik deze drie stappen moet gebruiken.

[ Voor 59% gewijzigd door pkouwer op 21-01-2009 20:34 ]

[Alain]

Kan inlist.reader een waarde hebben die niet in de tabel reader staat en ongelijk is aan NULL?

Daarnaast zou je met de zoekwoorden trigger en cascade een eind moeten komen.

[Gomez12]

Tja, in wezen zeg ik ook gewoon cascading triggers gebruiken als je dit te veel code vind.

Lees je alleen wel even in op de gevaren van cascading triggers. Als je er eentje niet goed documententeert is het een recipe for disaster

[pkouwer]

de inlist.reader kan inderdaad een waarde hebben die afwijkt. Doorgaans wordt deze door een apart programma ingevuld. Ik heb een externe applicatie ontwikkeld die dezelfde database gebruikt, dus de inlist.reader komt uit mijn eigen applicatie, een punt waar ik dus op zou controleren.

Het gaat mij niet zozeer om de hoeveelheid code, dit valt reuze mee, maar meer een vraag of dit zo de juiste aanpak is en of het ook anders had gekund.gemoeten, met wellicht andere/betere statements.

[Alain]

pkouwer schreef op donderdag 22 januari 2009 @ 09:40:
de inlist.reader kan inderdaad een waarde hebben die afwijkt.

Het gaat mij niet zozeer om de hoeveelheid code, dit valt reuze mee, maar meer een vraag of dit zo de juiste aanpak is en of het ook anders had gekund.gemoeten, met wellicht andere/betere statements.

Ik zou beginnen met een goed ontwerp van je database. Je legt een relatie tussen inlist.reader en reader.description. Je geeft zelf al aan dat beide tabellen door verschillende applicatie's en onafhankelijk van elkaar gevuld worden. Dat is geen relatie.

Het meest eenvoudig lijkt me om een gestandaardiseerde tabel te maken van reader en beide applicatie's laten wijzen naar de id in de gestandaardiseerde tabel.

[pkouwer]

ik kan/wil/mag/ga de database niet aanpassen daar de andere applicatie leidend is.

[Alain]

kan/wil/mag/ga je ook geen extra tabel toevoegen? Je bent wel in staat een inlist tabel aan te maken?

De extra tabel maakt het mogelijk om een relatie te leggen tussen een inlist object en een bekende reader. Als je geen relatie kunt leggen tussen twee velden kun je nog beter een binary search doen volgens mij.

[pkouwer]

ik kan alleen data toevoegen en verwijderen in de database. de tabellen zijn voorgedefineerd voor de leidende applicatie. Daar ik een eigen applicatie heb ontwikkeld die precies doet wat de klant wil en dit niet in de leidende applicatie zit, moet ik wel eens iets verwijderen. vandaar.

Dus: de database-definitie ligt vast.

[Alain]

Nogmaals: Met mijn methode hoef je de leidende niet aan te passen. Je moet er alleen iets bij aanknopen.

Als je triggers op de leidende tabellen kunt zetten ben je helemaal klaar, anders moet je een vetraging inbouwen.

Daarnaast is het nu de vraag of je iets kunt automatiseren in een relationele database, waarvan je zelf aangeeft dat de data niet relationeel is. Wat je nu feitelijk doet is de database gebruiken als bestandensysteem en telkens alle bestanden afzoeken naar een match.