[SQL] Constraint violation bij delete *

[Verwijderd]

Hallo,

Ik ben bezig met een opdracht voor school met SQL. Ik heb een database gekregen van school, en ik moet uit de tabel Customers alle Customers verwijderen die uit Frankrijk en Duitsland komen. (alles in de database is in het Engels) Ik doe dus:

code:

delete customers where country = 'France' or country = 'Germany'

Het incident is nu dat ik een error krijg. De volgende error:

code:

Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint "FK_Orders_Customers". The conflict occurred in database "Northwind", table "dbo.Orders", column 'CustomerID'.
The statement has been terminated.

De bedoeling is dat ik geen Orders verwijder. En ik weet niet hoe ik dit kan doe.

Bij voorbaat dank.

Gegroet,
Fregge

[LinuX-TUX]

Jou customers hebben orders. Deze orders verwijzen terug naar customers.

Om database inconsistency te voorkomen, kan je dus niet random customers eruit knikkeren, want dan heb je 'customer'-loze orders in je systeem staan.

Succes

edit:

Nee, ik heb geen glazen bol, maar ik zie wel je Foreign Key constraint staan, die de customers linked met orders. Wil je wel customers verwijderen, dan moet je zorgen dat de te 'verwijderen' customers geen orders hebben OF je systeem aanpassen en customers netjes een 'status' toekennen. (actief/nonactief - enabled/disabled, je kent het wel)

[ Voor 42% gewijzigd door LinuX-TUX op 09-03-2009 11:40 ]

[Intrepidity]

Je kunt natuurlijk de orders aan een andere customer hangen, maar dat lijkt me ook niet echt de bedoeling. Een order hoort nou eenmaal bij iemand, dus als je de persoon wilt verwijderen zul je ook zijn historie moeten verwijderen.
Daarnaast lijkt me dit nogal een huiswerkvraag.. Overleg eens met je docent als je er niet uitkomt. De orders houden maar toch de customer verwijderen kan gewoon niet met deze constraint.

[dev10]

Verwijderd schreef op maandag 09 maart 2009 @ 11:30:
De bedoeling is dat ik geen Orders verwijder. En ik weet niet hoe ik dit kan doe.

Wil jij dit niet of mag het niet van de opdracht?

[Verwijderd]

Dat is dus net de bedoeling. Volgens de leraar moet dit. Hierdoor heeft hij de volgende reden: de wet. Je moet je orders minimaal 7 jaar bewaren.

@dev10.
Dit mag niet volgens de opdracht

[ Voor 13% gewijzigd door Verwijderd op 09-03-2009 11:36 ]

[Intrepidity]

Maar wat heb je aan een order zonder customer? Is alsnog incomplete historie dan.

[NMe]

Gebruik een soft delete.

[dev10]

Verwijderd schreef op maandag 09 maart 2009 @ 11:36:
@dev10.
Dit mag niet volgens de opdracht

En in de opdracht staat niet iets uitgelegd over foreign keys en constraints? Ik begin hoe langer hoe meer te twijfelen aan de kwaliteit van die opdracht als je een inconsistente database moet gaan maken.

[ Voor 0% gewijzigd door dev10 op 09-03-2009 11:40 . Reden: Uitgelegd is met een 'd' 8)7 ]

[LinuX-TUX]

Intrepidity schreef op maandag 09 maart 2009 @ 11:37:
Maar wat heb je aan een order zonder customer? Is alsnog incomplete historie dan.

Belastingdienst: Aan wie heeft u 5 ton nitroglycerine verkocht?
Fregge: Ja, aan 10
Belastingdienst: 10?
Fregge: Ja, dat zeg ik toch?

Tuurlijk moet je je boekhouding jaren terug nog in kunnen zien, daarom moet je ook die customers niet weg kunnen knikkeren

Statusje toekennen en verder werken

[Woy]

Je database heeft een constraint zodat je geen Customer weg kunt gooien als er nog Orders zijn die naar die Customer verwijzen.

Je zult dus eerst moeten bepalen wat je met die Orders wilt doen, voordat je de Customer weg gooit. Je zou er bijvoorbeeld voor kunnen kiezen om eerst de koppeling met de Customer te verwijderen. Je zou dus alle Orders die bij Customers uit Frankrijk en Duitsland op NULL kunnen zetten.

Ik zou eerst eens overleggen met je docent wat precies de bedoeling is. Het lijkt me namenlijk niet de bedoeling dat je de Constraint weg-haalt. Die zit er immers niet voor niks.

Dus je zult of de relatie tussen de Orders en Customers weg moeten halen, of toch de Orders verwijderen. Of inderdaad de customer niet echt verwijderen, maar alleen de status updaten

Wij tweakers doen elkaar permanent de groeten

edit:

Iets sneller leren typen

[ Voor 6% gewijzigd door Woy op 09-03-2009 11:42 ]

[Verwijderd]

Ik stelde dezelfde vraag aan de leraar. Die zei: om je voorraad te controleren. Als er bijvoorbeeld 10 computers binnenkrijgt, en je krijgt er 2 binnen. Dan hou je 8 computers over. Als je een order verwijderd, heb je er volgens je systeem nog 9, maar je hebt er eigenlijk 8.

[dev10]

offtopic:
En vraag eens aan de leraar waarom je in Customers moet verwijderen, de Orders moet laten staan en waarom die constraint er dan op zit?

[ Voor 29% gewijzigd door dev10 op 09-03-2009 11:46 ]

[Woy]

offtopic:
Wil je voortaan overigens een wat beter omschrijving voor je Topic Titel bedenken. Msg 547 is nou niet echt een duidelijke omschrijving van het probleem. Ik heb je titel nu maar wat aangepast

Ik zou eens je opdracht goed nalezen wat exact de bedoeling is. Moet je de Customer echt uit de database verwijderen, of moet je zorgen dat de customer niet meer zichtbaar is in de applicatie.

[ Voor 31% gewijzigd door Woy op 09-03-2009 11:46 ]

[LinuX-TUX]

Woy schreef op maandag 09 maart 2009 @ 11:44:

offtopic:
Wil je voortaan overigens een wat beter omschrijving voor je Topic Titel bedenken. Msg 547 is nou niet echt een duidelijke omschrijving van het probleem. Ik heb je titel nu maar wat aangepast

offtopic:
Ik vond Msg 547 wel echt klinken als een 'Constraint violation bij delete', jij niet? Net als 404 als je een typo maakt in een URL

Of ben ik nog van de die-hard generatie tweakers

[Woy]

LinuX-TUX schreef op maandag 09 maart 2009 @ 11:47:
[...]

offtopic:
Ik vond Msg 547 wel echt klinken als een 'Constraint violation bij delete', jij niet? Net als 404 als je een typo maakt in een URL

Of ben ik nog van de die-hard generatie tweakers

offtopic:
Tuurlijk is het wel te achterhalen, maar er zullen een hoop mensen rondlopen die niet alle error/msg codes uit hun hoofd weten. Een omschrijving van de fout is een stuk duidelijker

[NMe]

Woy schreef op maandag 09 maart 2009 @ 11:44:
Ik zou eens je opdracht goed nalezen wat exact de bedoeling is. Moet je de Customer echt uit de database verwijderen, of moet je zorgen dat de customer niet meer zichtbaar is in de applicatie.

Ik mag toch hopen dat er op zijn minst aangestuurd wordt op een soft delete. Je kan geen customer verwijderen als daar constraints op zitten, en orders mogen volgens de specificaties niet weggegooid worden. Aannemende dat die contraint er niet voor niets op zit is een soft delete je enige optie.

[Woy]

NMe schreef op maandag 09 maart 2009 @ 11:55:
[...]

Ik mag toch hopen dat er op zijn minst aangestuurd wordt op een soft delete. Je kan geen customer verwijderen als daar constraints op zitten, en orders mogen volgens de specificaties niet weggegooid worden. Aannemende dat die contraint er niet voor niets op zit is een soft delete je enige optie.

Exact de reden dat ik zeg dat hij zijn opdracht eens goed na moet lezen

[RobIII]

Of gewoon de constraint verwijderen en dan de customers verwijderen

_{En nee, dat is niet de bedoeling en kan het ook niet zijn...}

[Mike78]

Of moet je alleen de customers verwijderen die geen orders gedaan hebben?

[Verwijderd]

De precieze opdracht die wij hebben gekregen is: Verwijder alle klanten uit de tabel Customers die uit Frankrijk en Duitsland komen.
Toen ben ik met de uitwerking met eerst Orders verwijderen, dan Customers naar de leraar gegaan, en die zei dat het niet goed was. Om de redenen van vooraad en van de wet.

[Patriot]

Verwijderd schreef op maandag 09 maart 2009 @ 14:55:
De precieze opdracht die wij hebben gekregen is: Verwijder alle klanten uit de tabel Customers die uit Frankrijk en Duitsland komen.
Toen ben ik met de uitwerking met eerst Orders verwijderen, dan Customers naar de leraar gegaan, en die zei dat het niet goed was. Om de redenen van vooraad en van de wet.

De enige resterende mogelijkheid is het opheffen van de constraint voordat je delete. Als later blijkt dat dat de oplossing is moet je niet vergeten direct te stoppen met je opleiding

[Woy]

Verwijderd schreef op maandag 09 maart 2009 @ 14:55:
De precieze opdracht die wij hebben gekregen is: Verwijder alle klanten uit de tabel Customers die uit Frankrijk en Duitsland komen.
Toen ben ik met de uitwerking met eerst Orders verwijderen, dan Customers naar de leraar gegaan, en die zei dat het niet goed was. Om de redenen van vooraad en van de wet.

Dan zul je dus moeten zorgen dat er geen Orders meer naar die Customers wijzen.

Ik zou alle Orders die een Customer in Frankrijk of Duitsland hebben bij een random andere Customer toewijzen

offtopic:
Ik wil de wet wel eens zien die stelt dat je geen Orders uit je database mag gooien. Maar het is wel logisch dat je dat niet wilt.

[ Voor 11% gewijzigd door Woy op 09-03-2009 15:02 ]

[Verwijderd]

Ik was dit met een klasgenoot ook aan het bespreken. We kwamen tot het volgende: Maak een user aan, die Unknown heet, en voeg daar de Orders toe. Ik zal eerst soft delete eens testen.

[RobIII]

Verwijderd schreef op maandag 09 maart 2009 @ 15:04:
Maak een user aan, die Unknown heet, en voeg daar de Orders toe.

Dan zet je beter je customerid bij die order op NULL. Maar linksom of rechtsom zijn het allemaal boutoplossingen. Je moet gewoon een soft-delete uitvoeren danwel een harde delete en voor lief nemen dat je orders foetsie zijn. Veel overige manieren zijn er AFAIK niet.

[Pathogen]

Ik zou je customers niet verwijderen maar op inactief zetten. Een valid_till kolom oid in de customers tabel invullen met de datum van inactief zetten van die klant.

Dat is de beste manier om historisch een overzicht te kunnen houden.

[jbdeiman]

@Fregge

Als je dan goed nadenkt dan moet je de ordergeschiedenis dus bewaren? Horen klantgegevens (die dus in de tabel "client" staan dan niet bij een order?

Ik dacht van wel, je moet dingen aan kunnen tonen, incl. de klantgegevens die je erbij hebt gekregen. Dus klantgegevens mag je ook niet weggooien.
Linux-TUX gaf het al aan -> Ja aan 10. Alleen het klantnummer zegt niets meer zonder de klantgegevens. Oftewel, deze mag je nooit weggooien -> Zet ze met een status op inactief (status = 0), pas de query aan door in de query WHERE (als dat woordje er nog niet staat!) status != 0 toe te voegen.

Je krijgt dan op de pagina waar je de gegevens in een overzicht bekijkt niet meer de klanten te zien uit die landen waarvoor je de status op 0 hebt gezet. -> Voila, voor een bezoeker is de klant "verwijderd" maar hij bestaat nog wel.

[NMe]

Patriot schreef op maandag 09 maart 2009 @ 14:59:
[...]

De enige resterende mogelijkheid is het opheffen van de constraint voordat je delete.

Moet ik "soft delete" uitspellen?

Verwijderd schreef op maandag 09 maart 2009 @ 15:04:
Ik was dit met een klasgenoot ook aan het bespreken. We kwamen tot het volgende: Maak een user aan, die Unknown heet, en voeg daar de Orders toe. Ik zal eerst soft delete eens testen.

Diezelfde wet die zegt dat je orders (eigenlijk: facturen) niet weg mag gooien zegt ook dat die niet meer mogen wijzigen nadat je ze aan hebt gemaakt. Aan een andere klant hangen mag dan dus ook niet, als je leraar consequent is.

jbdeiman schreef op maandag 09 maart 2009 @ 15:20:
verhaal

Dat zeg ik.

[ Voor 9% gewijzigd door NMe op 09-03-2009 15:22 ]

[Pathogen]

jbdeiman schreef op maandag 09 maart 2009 @ 15:20:
@Fregge

Als je dan goed nadenkt dan moet je de ordergeschiedenis dus bewaren? Horen klantgegevens (die dus in de tabel "client" staan dan niet bij een order?

Ik dacht van wel, je moet dingen aan kunnen tonen, incl. de klantgegevens die je erbij hebt gekregen. Dus klantgegevens mag je ook niet weggooien.
Linux-TUX gaf het al aan -> Ja aan 10. Alleen het klantnummer zegt niets meer zonder de klantgegevens. Oftewel, deze mag je nooit weggooien -> Zet ze met een status op inactief (status = 0), pas de query aan door in de query WHERE (als dat woordje er nog niet staat!) status != 0 toe te voegen.

Je krijgt dan op de pagina waar je de gegevens in een overzicht bekijkt niet meer de klanten te zien uit die landen waarvoor je de status op 0 hebt gezet. -> Voila, voor een bezoeker is de klant "verwijderd" maar hij bestaat nog wel.

Ik prefereer een datum boven een 1/0 switch, hoewel het bij clients niet zo vreselijk is, maar bij bijvoorbeeld tarieven kun je tegen een hoop aanlopen.

Als je een tarief, wisselkoers of whatever invult in een tabel en je historisch correct wil blijven met je facturen moet je die wisselkoers een valid_from en valid_till datum meegeven. Aan de hand van de factuurdatum kun je dan altijd terugkijken naar wat er precies is gefactureerd.

Hetzelfde geldt enigzins voor clients. De klant wordt nu op inactief gezet, maar vanaf wanneer? Je moet nog wel de orders kunnen bekijken die ooit voor die klant gemaakt zijn, anders ben je wederom historie kwijt.
Met een valid_from en valid_till datum kun je precies aangeven wanneer de klant in je systeem actief heeft gestaan.

[d00d]

Verwijderd schreef op maandag 09 maart 2009 @ 14:55:
De precieze opdracht die wij hebben gekregen is: Verwijder alle klanten uit de tabel Customers die uit Frankrijk en Duitsland komen.
Toen ben ik met de uitwerking met eerst Orders verwijderen, dan Customers naar de leraar gegaan, en die zei dat het niet goed was. Om de redenen van vooraad en van de wet.

Als je dit exact zou uitvoeren wordt je statement dus zoiets als:

SQL:

delete customers where country = 'France' and country = 'Germany'

Het resultaat is 0 records affected. En je kunt weer verder gaan met de opdracht

[Woy]

d00d schreef op maandag 09 maart 2009 @ 15:37:
[...]


Als je dit exact zou uitvoeren wordt je statement dus zoiets als:

SQL:

delete customers where country = 'France' and country = 'Germany'

Het resultaat is 0 records affected. En je kunt weer verder gaan met de opdracht

Als je de TS goed gelezen had, had je gezien dat het resultaat niet "0 records affected" was, maar
[quote]
Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint "FK_Orders_Customers". The conflict occurred in database "Northwind", table "dbo.Orders", column 'CustomerID'.
The statement has been terminated.
[/quote]

[RobIII]

Woy schreef op maandag 09 maart 2009 @ 15:44:
[...]

Als je de TS goed gelezen had, had je gezien dat het resultaat niet "0 records affected" was, maar

[...]

offtopic:
Effectief gezien zijn er dus 0 record affected. Maar da's mierencopulatie
Nou nog een "on error resume next" of een try met lege catch er om heen en doorgaan met die app

[ Voor 13% gewijzigd door RobIII op 09-03-2009 15:46 ]

[Woy]

Ik zie nu pas dat d00d het over de en in de beschrijving had dus dan zou het idd "0 records affected" zonder foutmelding zijn

[ Voor 31% gewijzigd door Woy op 09-03-2009 15:49 ]

[Dido]

Woy schreef op maandag 09 maart 2009 @ 15:44:
Als je de TS goed gelezen had, had je gezien dat het resultaat niet "0 records affected" was, maar

Als je de query die jij quote vergeleken had met de query uit de TS had je gezien dat ze niet hetzelfde zijn, en dat je dus ook niet hetzelfde resultaat hoeft te verwachten

[Verwijderd]

d00d schreef op maandag 09 maart 2009 @ 15:37:
[...]


Als je dit exact zou uitvoeren wordt je statement dus zoiets als:

SQL:

delete customers where country = 'France' and country = 'Germany'

Het resultaat is 0 records affected. En je kunt weer verder gaan met de opdracht

Dat klopt. Zo moet dat dan ja. Als je het exact uitvoert. Maar als je een beetje nadenkt moet er Or zijn.

[Dido]

Verwijderd schreef op maandag 09 maart 2009 @ 16:01:
Dat klopt. Zo moet dat dan ja. Als je het exact uitvoert. Maar als je een beetje nadenkt moet er Or zijn.

Maar waar stop je met nadenken? Want ik kom met een beetje nadenken ook zover dat je geen customers weggooit die orders hebben. Sterker nog, de database vertelt me dat

[LinuX-TUX]

Dido schreef op maandag 09 maart 2009 @ 16:10:
[...]

Maar waar stop je met nadenken? Want ik kom met een beetje nadenken ook zover dat je geen customers weggooit die orders hebben. Sterker nog, de database vertelt me dat

Omdat de database zo geconfigureerd was ...

/me LinuX-TUX denkt dat de leraar het express heeft gedaan om de leerlingen na te laten denken ... OF een grove fout heeft begaan en een cursus heeft gebaseerd op prefab code zonder het zelf te doorgronden

/me Tevens heeft LinuX-TUX nu een leuke baan en is ook bezig met de 'business' reverse enginered aan te leren. Deels via code en deels via vragen. Komt soms nog wel eens achter dingen om anderen het vuur aan de schenen mee te leggen, om tot de al gecodeerde conclusies te komen ... of niet, en de code aan te passen natuurlijk

---

edit:
@ hieronder

Dat tussen de haakjes is niet echt aan de orde, wel zou ik me voor kunnen stellen dat een leraar gewoon leerlingen een keer 'poked' om hiermee kennis te maken en zelf een keer nadenken over materie, toepassing & oplossing. De vraag kwam redelijk eerstejaars over (sorry als ik hiermee mensen beledig) maar is wel iets wat ik her en der ZELF gemist heb op mijn opleiding. Soms moet je wat flexibeler denken en out-of-the-box van wat je wordt aan gereikt.

Desalniettemin, de constraint zat er al vooraf in ... 1 way or the other moeten ze (leerling/leraar) wel tot de conclusie komen dat die daar niet voor niets zat

[ Voor 48% gewijzigd door LinuX-TUX op 09-03-2009 23:37 ]

[Gomez12]

Lijkt me persoonlijk een verkeerde manier van lesgeven als je dit verstaat onder laten nadenken.
Simplistisch gezegd kan je of een soft delete doen of je kan alle regels breken en bijv de constraint eraf halen ( een oplossing als alles naar een onbekende klant laten leiden om de constraint niet te breken is gewoon per definitie fout, als dit geaccepteerd was dan had de hele constraint nooit bestaan, in het latere leven garandeer ik je toch echt wel dat je niet zomaar constraints mag negeren dan wordt er gewoon een hoge boom voor jou uitgezocht )

[Verwijderd]

We zijn bezig om applicatie ontwikkelaars te worden. Dan krijgen we te maken met dit soort situaties. Maar ik heb niet echt oplossingen gehoord die zullen werken.

[Gomez12]

@Fregge dat heeft er gewoon mee te maken dat de vraag verkeerd is. Op een verkeerde vraag is geen correct antwoord te geven, dan moet je of de vraag veranderen of het zo maken dat het lijkt alsof de vraag beantwoord is ( soft-deletes ) zonder dat je de vraag echt beantwoord

[Dido]

Verwijderd schreef op dinsdag 10 maart 2009 @ 10:07:
We zijn bezig om applicatie ontwikkelaars te worden. Dan krijgen we te maken met dit soort situaties. Maar ik heb niet echt oplossingen gehoord die zullen werken.

Je bedoelt in dit topic? Er staan er anders genoeg. Je zult echter eerst uit moeten zoeken wat er gewenst is, waarbij je even vergeet wat de technische (on)mogelijkheden zijn. Wat wil de klant/gebruiker?

Fout nummer 1 is de aanname dat de klant wil wat ie zegt. Het is aan de ITer om de consequenties van de wensen van de klant duidelijk te maken, maar het is daarna weer aan de klant om te kiezen welke consequenties aanvaarbaar zijn.

Mogelijke oplossingen (en die werken, maar hebben allemaal consequenties):

• Je verwijdert de constraint.
Functionele consequentie: orders zonder geldige klant
Technische consequentie: inconsistente database
• Je zet de klanten op inactief (soft delete).
Functionele consequentie: klanten zijn onzichtbaar.
Technische consequentie: tabelwijziging noodzakelijk
• Je verplaatst de orders eerst naar een dummyklant.
Functionele consequentie: orderinformatie is gewijzigd en nu onjuist
Technische consequentie: geen

De klant is normaliter alleen geinteresseerd in de functionele consequentie. Drie keer raden welke van de drie oplossingen hij wil?

offtopic:
En ergens bekruipt me het gevoel dat we veel te diep gaan en de hele opdracht niet meer was dan een enorm basic SQL-opdrachtje om te kijken of de student het verschil tussen AND en OR begrijpt

[Woy]

Dido schreef op dinsdag 10 maart 2009 @ 10:24:
[...]

offtopic:
En ergens bekruipt me het gevoel dat we veel te diep gaan en de hele opdracht niet meer was dan een enorm basic SQL-opdrachtje om te kijken of de student het verschil tussen AND en OR begrijpt

offtopic:
Dat zou wel een enorme grap zijn

[.Gertjan.]

Dido schreef op dinsdag 10 maart 2009 @ 10:24:
[...]

Fout nummer 1 is de aanname dat de klant wil wat ie zegt. Het is aan de ITer om de consequenties van de wensen van de klant duidelijk te maken, maar het is daarna weer aan de klant om te kiezen welke consequenties aanvaarbaar zijn.

Je kunt er eigenlijk bijna altijd van uit gaan dat de klant niet weet wat hij wil. En hoe meer "lijnen" er tussen de developer en de klant zitten hoe meer de aanvankelijke opdracht vervormd/aangepast wordt. Iedereen wil er (bewust of onbewust) zijn eigen twist aan geven of begrijpt de wens van de ander partij niet.

[ Voor 11% gewijzigd door .Gertjan. op 10-03-2009 11:05 ]

[RobIII]

.Gertjan. schreef op dinsdag 10 maart 2009 @ 11:05:
[afbeelding]

Grote(re) versie

[.Gertjan.]

RobIII schreef op dinsdag 10 maart 2009 @ 11:26:
[...]

Grote(re) versie

Die bedoelde ik ook eigenlijk, maar kon hem zo snel niet gevonden krijgen. Thanks, deze gooi ik ook even op mijn HDD neer, je weet nooit wanneer je hem nodig hebt

[Verwijderd]

disable constraint FK_Orders_Customers
delete customers where country = 'France' or country = 'Germany'
enable constraint FK_Orders_Customers

Zo zou ik het toch doen als je de orders moet bijhouden, zo hebben wij het ook geleerd.

[RobIII]

Verwijderd schreef op dinsdag 10 maart 2009 @ 11:37:
disable constraint FK_Orders_Customers
delete customers where country = 'France' or country = 'Germany'
enable constraint FK_Orders_Customers

Zo zou ik het toch doen als je de orders moet bijhouden, zo hebben wij het ook geleerd.

Die constraint ga je nooit niet meer kunnen enablen omdat er orders bestaan die naar niet-bestaande customers verwijzen. En als je het zo hebt geleerd moeten ze die leraar de spreekwoordelijke plank in z'n nek rammen en een functie als geschiedenisleraar aardrijkskundeleraar aanbieden en moet jij zorgen dat je als de sodemieter van dit stupide idee af komt door te proberen te doorgronden wat er nou eigenlijk gebeurt en te beseffen dat het klinkklare onzin is..

En mocht het je wél lukken die constraint terug te zetten terwijl er nog orders in staan die verwijzen naar niet bestaande customers dan mikker het RDBMS dat je gebruikt ook maar buiten (en ja, ik ken er een aantal en nee, ik ga geen namen noemen )

Wat is dat toch met die opleidingen van tegenwoordig?

.Gertjan. schreef op dinsdag 10 maart 2009 @ 11:47:

offtopic:
@RobIII: Geschiedenisleraar lijkt me geen geschikt vak voor die docent. In deze situatie wordt de geschiedenis gewoon weggegooid als een customer verdwijnt. Aangezien de meeste sleutel figuren uit de geschiedenis ook al overleden zijn zou volgens een dergelijke leraar de geschiedenis nooit plaats hebben gevonden

I stand corrected

[ Voor 49% gewijzigd door RobIII op 10-03-2009 11:51 ]

[.Gertjan.]

RobIII schreef op dinsdag 10 maart 2009 @ 11:39:
[...]

Die constraint ga je nooit niet meer kunnen enablen omdat er orders bestaan die naar niet-bestaande customers verwijzen. En als je het zo hebt geleerd moeten ze die leraar de spreekwoordelijke plank in z'n nek rammen

Wat is dat toch met die opleidingen van tegenwoordig?

Inderdaad. Je kan hooguit even de constraint eraf halen om te verwijderen, de boel recht te zetten en dan de costraint er weer op, maar dat is zeker niet aan te raden (wat als je iets te veel verwijdert en alsnog de constraint er niet op krijgt? Dan denk ik dat de opdrachtgever je niet zo erg leuk/aardig meer vindt). Beter is het om eerst de boel recht te zetten en dan pas je delete te doen. Opleidingen die mensen dat soort ideeen bijbrengt moeten ze eigenlijk een flinke schop geven. Mij is zelfs geleerd dat je eigenlijk nooit iets uit de database moet gooien. Veel bedrijven hechten veel waarde aan historische gegevens (en in veel gevallen moet het volgens de wetgeving sowieso bewaard worden). Bij oplossingen als het gooien van de orders naar een soort dummy klant gaan mijn nek haren rechtovereind staan... Dan ben je gewoon je historie aan het verkloten.

Constraints zijn er om te garanderen dat de data aan bepaalde eisen voldoet. Als je ergens in je data verwerking die eisen moet schenden ben je verkeerd bezig.

Lang leve de DeletedYN bitjes

offtopic:
@RobIII: Geschiedenisleraar lijkt me geen geschikt vak voor die docent. In deze situatie wordt de geschiedenis gewoon weggegooid als een customer verdwijnt. Aangezien de meeste sleutel figuren uit de geschiedenis ook al overleden zijn zou volgens een dergelijke leraar de geschiedenis nooit plaats hebben gevonden

[ Voor 9% gewijzigd door .Gertjan. op 10-03-2009 12:00 ]

[Patriot]

NMe schreef op maandag 09 maart 2009 @ 15:20:
[...]
Moet ik "soft delete" uitspellen?

Tsja, als je met een opdracht specifiek voor (het vak?) SQL bezig bent, dan lijkt me "voeg een 'delete' veld toe en zet deze op 1 bij mensen uit Frankrijk en Duitsland" een beetje een vreemd antwoord.

Daarom zie ik een soft delete niet als optie, net zo min als het verwijderen/uitschakelen van de constraint (dat moet je ook niet doen natuurlijk, dat was meer een grapje van mijn kant). Maar misschien vat ik de vraag wel verkeerd op, en is een soft delete wél de oplossing. Ik ben iig benieuwd, wat mij betreft mag die leraar wel even zijn zegje komen doen over wat hij nou de beste oplossing vind

[NMe]

Patriot schreef op dinsdag 10 maart 2009 @ 12:07:
[...]


Tsja, als je met een opdracht specifiek voor (het vak?) SQL bezig bent, dan lijkt me "voeg een 'delete' veld toe en zet deze op 1 bij mensen uit Frankrijk en Duitsland" een beetje een vreemd antwoord.

Daarom zie ik een soft delete niet als optie, net zo min als het verwijderen/uitschakelen van de constraint (dat moet je ook niet doen natuurlijk, dat was meer een grapje van mijn kant). Maar misschien vat ik de vraag wel verkeerd op, en is een soft delete wél de oplossing. Ik ben iig benieuwd, wat mij betreft mag die leraar wel even zijn zegje komen doen over wat hij nou de beste oplossing vind

Stiekem denk ik gewoon dat we eindelijk eens met een goeie leraar te maken krijgen hier op GoT en dat hij daadwerkelijk zijn studenten de goeie kant op pusht. Hij zal gewoon willen dat zijn studenten ófwel de gedachtengang maken "hee, hij spreekt zichzelf tegen, wat moet ik nu?" en het vervolgens gaan vragen, ofwel dat ze inzien dat dit gewoon niet mogelijk is in een DELETE-query binnen de bestaande constraints en het op een andere manier moet. In het eerste geval heeft hij ze geleerd om actief bij de klant na te vragen wat het nou eigenlijk precies is dat hij bedoelt (héél belangrijk!) en in het tweede geval heeft hij de student geleerd outside of the box te denken.

Maar in plaats van dat te waarderen van een leraar zie ik hier in dit topic bijna alleen maar vieze hacks en rare opmerkingen voorbij komen die de helft van de tijd het probleem niet oplossen en de andere helft van de tijd te ranzig zijn om aan te zien, onderwijl de leraar te verwijten dat 'ie fout bezig is.

[Dido]

Puur uit nieuwsgierigheid... bij welke helft reken je mij nu? De ranzigheid of de niet-oplossende helft?

[.oisyn]

Ah wat schattig, NMe gelooft nog in een utopie

[cariolive23]

Verwijderd schreef op dinsdag 10 maart 2009 @ 11:37:
disable constraint FK_Orders_Customers
delete customers where country = 'France' or country = 'Germany'
enable constraint FK_Orders_Customers

Zo zou ik het toch doen als je de orders moet bijhouden, zo hebben wij het ook geleerd.

Hoe verzin je het? Met een paar eenvoudige handelingen, waar een programmeur nooit rechten voor zou mogen hebben, de database het riool in. Enig idee waarom die constraints zijn bedacht?

Wanneer de constraints goed zijn, kom je daar nooit meer met je vingers aan en al helemaal niet omdat data anders niet zou "passen". De data voldoet dan blijkbaar niet aan de gestelde eisen en dus moet je zorgen voor betere data. In dit geval zou je eerst de gerelateerde data kunnen verwijderen, wat ook niet de bedoeling is, of even de status van een record aanpassen, de reeds genoemde soft delete. Kolommetje toevoegen, status erin zetten en het probleem is gefixed.

Constraints weggooien om data passend te krijgen...

[LinuX-TUX]

cariolive23 schreef op dinsdag 10 maart 2009 @ 17:51:
[...]

Hoe verzin je het? Met een paar eenvoudige handelingen, waar een programmeur nooit rechten voor zou mogen hebben, de database het riool in. Enig idee waarom die constraints zijn bedacht?

Wanneer de constraints goed zijn, kom je daar nooit meer met je vingers aan en al helemaal niet omdat data anders niet zou "passen". De data voldoet dan blijkbaar niet aan de gestelde eisen en dus moet je zorgen voor betere data. In dit geval zou je eerst de gerelateerde data kunnen verwijderen, wat ook niet de bedoeling is, of even de status van een record aanpassen, de reeds genoemde soft delete. Kolommetje toevoegen, status erin zetten en het probleem is gefixed.

Constraints weggooien om data passend te krijgen...

Zoals RobIII al zei, die constraints kan je daarna ook niet meer activeren

[cariolive23]

Weet ik, maar wanneer iemand van dit soort domme opmerkingen weet uit te spugen, verwacht ik niet dat hij/zij zich druk gaat maken over een corrupte database. Gewoon de foutmeldingen onder de mat vegen en klaar is kees... Toch jammer dat er mensen zijn die zich niet druk maken over corrupte data.

[Patriot]

NMe schreef op dinsdag 10 maart 2009 @ 16:26:
[...]

Stiekem denk ik gewoon dat we eindelijk eens met een goeie leraar te maken krijgen hier op GoT en dat hij daadwerkelijk zijn studenten de goeie kant op pusht. Hij zal gewoon willen dat zijn studenten ófwel de gedachtengang maken "hee, hij spreekt zichzelf tegen, wat moet ik nu?" en het vervolgens gaan vragen, ofwel dat ze inzien dat dit gewoon niet mogelijk is in een DELETE-query binnen de bestaande constraints en het op een andere manier moet. In het eerste geval heeft hij ze geleerd om actief bij de klant na te vragen wat het nou eigenlijk precies is dat hij bedoelt (héél belangrijk!) en in het tweede geval heeft hij de student geleerd outside of the box te denken.

Dat kan best, maar ik vind het een beetje een vreemde manier van werken hoor. Je dwingt mensen namelijk nu out-of-the-box te denken, maar ze hebben het zelf waarschijnlijk niet door. Ik ben geen expert op het gebied van educatie, maar mijn gevoel zegt me dat het een betere strategie is om een duidelijke opdracht te leveren waar eventueel out-of-the-box oplossingen voor zijn die je alsnog extra kunt belonen. Als je dat vanaf het begin duidelijk maakt zullen leerlingen misschien wél de moeite doen voor interessante oplossingen zonder dat ze daarbij eerst helemaal vol raken met de twijfel over hun eigen kunnen die zo'n opdracht als die van de TS op lijkt te wekken (is er nou geen goede oplossing? Of ken ik die gewoon niet?).

[Verwijderd]

Thrackan schreef op maandag 09 maart 2009 @ 15:19:
Ik zou je customers niet verwijderen maar op inactief zetten. Een valid_till kolom oid in de customers tabel invullen met de datum van inactief zetten van die klant.

Dat is de beste manier om historisch een overzicht te kunnen houden.

een kolom met een boolean (Actueel J/N) of beter, een datum range toekennen aan de customercode in de customer tabel is IMHO functioneel gezien de beste oplossing ja.

die FK zit er niet voor niks. afblijven dus..
Alles onder een dummy customer zeggen? hoe ziek kun je zijn.

[Cartman!]

nm

[ Voor 85% gewijzigd door Cartman! op 10-03-2009 19:17 ]

[Gomez12]

Verwijderd schreef op dinsdag 10 maart 2009 @ 18:56:
[...]
Alles onder een dummy customer zeggen? hoe ziek kun je zijn.

He, het blijft binnen de opdracht , genereert een vervolg opdracht ( de data corruptie is iemand anders zijn pakkie an ) en geen enkele zinnige programmeur komt erop ( is ook een manier om out of the box te definieren )

Ik ben bedrijven tegengekomen die zo handelen...

[Dido]

Gomez12 schreef op dinsdag 10 maart 2009 @ 19:29:
Ik ben bedrijven tegengekomen die zo handelen...

Ik ook, maar om het nou aan studenten aan te gaan raden. We adviseren hier ook niet om de belasting vooral zo hard mogelijk te tillen, omdat we bedrijven kennen die het doen

[NMe]

Dido schreef op dinsdag 10 maart 2009 @ 16:42:
Puur uit nieuwsgierigheid... bij welke helft reken je mij nu? De ranzigheid of de niet-oplossende helft?

Ik zeg dat er bijna alleen maar vieze oplossingen voorbij komen en de helft daarvan werkt niet óf is te ranzig om aan te zien. Of beiden. Jouw post stipt twee vieze oplossingen aan maar ook eentje die wel werkt, en vergelijkt die drie oplossingen met elkaar. Lijkt me duidelijk dat ik daar wél blij mee ben.

.oisyn schreef op dinsdag 10 maart 2009 @ 17:04:
Ah wat schattig, NMe gelooft nog in een utopie

Ik heb ook één zo'n leraar.

Granted, hij is enig in zijn soort op mijn school, maar hij ís er wel.

[Verwijderd]

De soft-delete is anders net zo ranzig.

zo-iets dien je goed te modelleren.. en dan is een item, of meerdere items die aangeven of het acteel is het beste resultaat.
Dit heeft niks met techniek te maken, maar met fatsoenlijk ontwerp.

[RobIII]

Verwijderd schreef op woensdag 11 maart 2009 @ 00:58:
De soft-delete is anders net zo ranzig.

Want? In deze, zonder veel verdere context of uitgebreide informatie over hoe de DB in elkaar steekt danwel technische en/of functionele eisen, is een soft-delete de makkelijkste en beste oplossing.

Verwijderd schreef op woensdag 11 maart 2009 @ 00:58:
zo-iets dien je goed te modelleren.. en dan is een item, of meerdere items die aangeven of het acteel is het beste resultaat.

Wat bedoel je hier mee? Doe's een voorbeeldje ter verduidelijking? Zie 't al Tuurlijk, maar dat komt op hetzelfde neer als een soft-delete. Of er nou staat "deleted = 1" of "valid = 0" of "validuntil = 10-03-2009"; in alle drie de gevallen is de klant 'soft-deleted'.

Sure, je kunt een klant ook redundant in de order-tabel bij de order opslaan; dan kun je naderhand ook doodleuk klanten verwijderen en heb je geen last van die 'pesky constraints'. Of je dat wil is een tweede en ligt behoorlijk aan de eisen, mogelijkheden etc..

Verwijderd schreef op woensdag 11 maart 2009 @ 00:58:
Dit heeft niks met techniek te maken, maar met fatsoenlijk ontwerp.

Daar waren we inmiddels al lang en breed achter

[ Voor 22% gewijzigd door RobIII op 11-03-2009 01:16 ]

[Verwijderd]

Wat bedoel je hier mee? Doe's een voorbeeldje ter verduidelijking?

Sorry hoor.. maar dit is een schoolvoorbeeld. Moet ik dit uberhaupt nog hier uitleggen???
Een soft-delete is een tijdelijke oplossing die lang niet door alle platformen wordt ondersteund. Door het goed te modelleren krijg je een systeem wat hoe dan ook op alle RDBMS's werkt en dat kan ook.. Dit gaat niet om .. welke fabrikant heeft hier een leuk foefje voor.. Dit zijn zulke essentiele vraagstukken dat je dit gewoon in je ERD opneemt.
Of het nu SQL server of niet. leuke technieken zoals soft-deletes mogen NOOIT impact hebben op een ontwerp. Een soft-delete is makkelijk ja.. maar niks anders dan een sleezy work-around.

Sure, je kunt een klant ook redundant in de order-tabel bij de order opslaan; dan kun je naderhand doodleuk klanten verwijderen en heb je geen last van die 'pesky constraints'. Of je dat wil is een tweede en ligt behoorlijk aan de eisen, mogelijkheden etc..

Ik denk niet dat je uberhaupt snapt hoe je dit soort systemen modeleert. althans dat blijkt uit bovenstaande suggestie.

Er is hier een iemand op pagina 1 die functioneel (en daar gaat het om, zulke systemen dienen bedrijfsprocessen te ondersteunen en niet andersom) wist hoe je dit het beste oplost. Vanuit je applicatie filter je op "is iets actueel Ja of Nee" als het gaat om die belasting-eis bijv. Je maakt geen vensters die enkel een select * doen op 1 tabel, maar een inner join leggen op een dimensie tabel zoals customers.. juist door een filter te leggen op bijvoorbeeld Actueel J/N krijg je:
1: actueel = J: Alleorders en/of klanten die een order gepaatst hebben
2: actuee; =N: Alleen klanten die NIET actueel zijn en daarbij horende orders
3: geen selectie: Alle klanten met daarbij horend .. alle orders

Daar waren we inmiddels al lang en breed achter

Grappig dat iemand dit roept wat keer op keer "soft deletes" oppert terwijl dit een kwestie is van een fatsoenlijk design.

Soft-deletes hebben namelijk geen RUK met RDBMS's te maken als het gaat om design van een applicatie op een IS.

[RobIII]

Verwijderd schreef op woensdag 11 maart 2009 @ 01:17:
[...]
Sorry hoor.. maar dit is een schoolvoorbeeld. Moet ik dit uberhaupt nog hier uitleggen???

Zie mijn edit

RobIII schreef op woensdag 11 maart 2009 @ 01:01:
Doe's een voorbeeldje ter verduidelijking? Zie 't al Tuurlijk, maar dat komt op hetzelfde neer als een soft-delete. Of er nou staat "deleted = 1" of "valid = 0" of "validuntil = 10-03-2009"; in alle drie de gevallen is de klant 'soft-deleted'.

Het was me gewoon even onduidelijk wat je met idem dit en item dat bedoelde

Verwijderd schreef op woensdag 11 maart 2009 @ 01:17:
[...]
Een soft-delete is een tijdelijke oplossing die lang niet door alle platformen wordt ondersteund.

Ik geloof dat we iets anders onder soft-delete verstaan?
soft-delete
soft-delete
RobIII in "[SQL] Constraint violation bij delete *"
Ik kan me niet voorstellen dat er een RDBMS is dat géén soft-delete ondersteunt...

Jij doelt op versioned records of iets dergelijks? Porren in transaction logs enzo? Of...?

Verwijderd schreef op woensdag 11 maart 2009 @ 01:17:
[...]
Dit gaat niet om .. welke fabrikant heeft hier een leuk foefje voor..
Of het nu SQL server of niet. leuke technieken zoals soft-deletes mogen NOOIT impact hebben op een ontwerp. Een soft-delete is makkelijk ja.. maar niks anders dan een sleezy work-around.

Ik weet niet waar jij het over hebt dan?

offtopic:
En verder mag je wel een beetje minder hard van stapel lopen, ik weet heus wel waar ik het over heb

[ Voor 93% gewijzigd door RobIII op 11-03-2009 01:30 ]

[NMe]

Verwijderd schreef op woensdag 11 maart 2009 @ 00:58:
De soft-delete is anders net zo ranzig.

zo-iets dien je goed te modelleren.. en dan is een item, of meerdere items die aangeven of het acteel is het beste resultaat.

Wat jij zegt is letterlijk precies hetzelfde, met als enige verschil dat een soft-delete alleen zorgt dat een order zinnig blijft na het verwijderen van een klant, en jouw methode ook nog eens geschiedenis van wijzigingen bijhoudt. Dat laatste lijkt me zeker voor een schoolopdracht als deze zowel irrelevant als verwarrend. Daarnaast kan het ook in "de echte wereld" nog eens totaal overbodig zijn afhankelijk van wat je opdracht is of inhoudt.

Verwijderd schreef op woensdag 11 maart 2009 @ 01:17:
[...]
Een soft-delete is makkelijk ja.. maar niks anders dan een sleezy work-around.

Het is de meest elegante manier die het probleem oplost. Jouw oplossing doet veel meer dan de opdracht van de topicstarter en zou derhalve op mijn school door een aantal leraren zelfs afgekeurd worden.

[ Voor 21% gewijzigd door NMe op 11-03-2009 01:21 ]

[curry684]

RobIII schreef op woensdag 11 maart 2009 @ 01:01:
[...]

Sure, je kunt een klant ook redundant in de order-tabel bij de order opslaan; dan kun je naderhand ook doodleuk klanten verwijderen en heb je geen last van die 'pesky constraints'. Of je dat wil is een tweede en ligt behoorlijk aan de eisen, mogelijkheden etc..

Uit functioneel oogpunt is dit stiekem vaak wel wenselijk - historische informatie over een order is in beginsel waardeloos als de informatie niet klopt, en bedrijven willen nog wel eens verhuizen, van naam veranderen, opgekocht worden, failliet gaan en doorstarten en dat soort dingen. Ten behoeve van belastingdienst en debiteurenadministratie is het dus welzeker wenselijk om te kunnen achterhalen niet alleen dat je op 23 augustus 2004 een pallet vol teletubbies hebt verkocht, maar ook aan wie en naar welk adres je toen de poppen en de factuur hebt verstuurd.

Een docent die overigens actief propageert dat constraints tijdelijk verwijderen een goed idee is bevestigt enkel mijn al jaren lopende en vaak bevestigde vooroordeel dat ICT-onderwijs in Nederland een grappig stukje tijdsvulling inhoudt voordat je in het bedrijfsleven echt iets leert - of vaker nog helaas niet leert hoe het wel zou moeten. Niet alleen overtreedt het alle basisbeginselen van goed ontwerp en aanspreken van relationele databases, het opent zelfs wagenwijd de deuren dat er op een dag een nieuwe klant is met dezelfde PK. En dan heb je je teletubbies ineens aan Pietje Puk BV uit Lutjebroek geleverd in plaats van VOF de Deurzakkertjes uit Moddergat. Zal de deurwaarder amusant vinden als je hem achter de factuur aanstuurt.

[RobIII]

curry684 schreef op woensdag 11 maart 2009 @ 01:30:
[...]

Uit functioneel oogpunt is dit stiekem vaak wel wenselijk - historische informatie over een order is in beginsel waardeloos als de informatie niet klopt, en bedrijven willen nog wel eens verhuizen, van naam veranderen, opgekocht worden, failliet gaan en doorstarten en dat soort dingen. Ten behoeve van belastingdienst en debiteurenadministratie is het dus welzeker wenselijk om te kunnen achterhalen niet alleen dat je op 23 augustus 2004 een pallet vol teletubbies hebt verkocht, maar ook aan wie en naar welk adres je toen de poppen en de factuur hebt verstuurd.

En daarom stip ik het ook aan. _{En ikzelf doe het, doorgaans, dan ook zo.}

curry684 schreef op woensdag 11 maart 2009 @ 01:30:
Een docent die overigens actief propageert dat constraints tijdelijk verwijderen een goed idee is bevestigt enkel mijn al jaren lopende en vaak bevestigde vooroordeel dat ICT-onderwijs in Nederland een grappig stukje tijdsvulling inhoudt voordat je in het bedrijfsleven echt iets leert - of vaker nog helaas niet leert hoe het wel zou moeten.

curry684 schreef op woensdag 11 maart 2009 @ 01:30:
Niet alleen overtreedt het alle basisbeginselen van goed ontwerp en aanspreken van relationele databases

Dan gooien ze 't gewoon op "dat was voor educatieve doeleinden en moet je *kuch* natuurlijk *kuch* nooit doen in het echte leven"

[ Voor 37% gewijzigd door RobIII op 11-03-2009 01:36 ]

[NMe]

curry684 schreef op woensdag 11 maart 2009 @ 01:30:
[...]

Een docent die overigens actief propageert dat constraints tijdelijk verwijderen een goed idee is [..]

Dat zie ik nergens terug eigenlijk. We (ik incluis) nemen hier een aantal dingen aan maar uiteindelijk gaan we alleen te weten komen of die docent goed bezig is of niet wanneer de topicstarter aan die docent vraagt of de door hem (door ons? ) verzonnen oplossing goed is of niet.

[Gomez12]

NMe schreef op woensdag 11 maart 2009 @ 01:19:
[...]

Het is de meest elegante manier die het probleem oplost. Jouw oplossing doet veel meer dan de opdracht van de topicstarter en zou derhalve op mijn school door een aantal leraren zelfs afgekeurd worden.

Dan zou ik toch maar eens goed nadenken over hoe goed die leraren zijn.

In het echte leven moet je vaak/bijna altijd buiten de wens van de klant gaan ( uiteraard in overleg ) puur omdat de klant gewoon een onbenul is die niet weet wat hij wil.
Op school gaat dat overleg waarschijnlijk iets moeilijker ( als opdrachtgever ga je ook om tafel zitten met 20 developers etc ), maar gewoon goede functionele oplossingen die de wens van de klant inwilligen kan je wat mij betreft niet afkeuren als je komt met een onmogelijke vraag. Dan moet er al buiten de opdracht getreden worden, als een leraar dan denkt dat dit te ver is en dat niet dan mag hij dit van te voren aangeven door er bijvoorbeeld een deadline/budget aan te verbinden ( waarmee automatisch de mogelijkheden al verkleind worden ).

Puur sec gezien is er geen goed antwoord op de letterlijke vraag, elk antwoord wat dus hetzelfde doel bereikt als de vraag lijkt mij dan ook goed als er verder geen restricties zijn opgegeven.

[.oisyn]

Verwijderd schreef op woensdag 11 maart 2009 @ 01:17:
[...]
Sorry hoor.. maar dit is een schoolvoorbeeld. Moet ik dit uberhaupt nog hier uitleggen???

Nou, ja dus. RobIII vraagt om een verduidelijking, omdat hij vermoed dat jullie samen niet op een lijn zitten, niet omdat hij het niet snapt. Deze hele post van jou maakt dat vervolgens wel duidelijk (dat jullie niet op een lijn zitten). Blijkbaar ken jij een soft delete als een bepaalde feature van een RDBMS. Ik versta zelf onder soft delete gewoon een feature in je datamodel wat dus RDBMS onafhankelijk is, en derhalve onderdeel van het design (ergo, precies wat jij zegt). Sterker nog, ik heb het idee dat iedereen hier dat eronder verstaat, behalve jij. Je hele relaas is dus nogal onzinnig, jullie hebben het gewoon over hetzelfde, en dat wat jij aan het afbranden bent heeft niemand gesuggereerd.

[ Voor 4% gewijzigd door .oisyn op 11-03-2009 01:40 ]

[Verwijderd]

Wat jij zegt is letterlijk precies hetzelfde, met als enige verschil dat een soft-delete alleen zorgt dat een order zinnig blijft na het verwijderen van een klant, en jouw methode ook nog eens geschiedenis van wijzigingen bijhoudt. Dat laatste lijkt me zeker voor een schoolopdracht als deze zowel irrelevant als verwarrend. Daarnaast kan het ook in "de echte wereld" nog eens totaal overbodig zijn afhankelijk van wat je opdracht is of inhoudt.

Ja misschien ga ik juist verder dan de opdracht.. Ik kom uit het bedrijfsleven en ik kan het gewoon niet waardere dat "pas opgeleiden" dit soort fuckups leren.

Want, Nee wat ik zeg is letterlijk niet hetzelfde gezien het hier gaat om een DESIGN kwestie en geen technische work-around kwestie. Ik mag aannemen dat de persoon in kwestie lid krijgt in het maken van applicaties op IS's en geen cursus wil hebben van SQL Server?

Het is zeker niet irrelevant of verwarrend.. mijn god.. overbodig? noem je het wegwuiven van data van 4 jaar ouder gewoon overbodig?? Ook al is het 5 jaar oud.. en op dit moment niet relevant.. er zijn momenten dat het WEL relevant is. en dat moet je het hebben.

Data-fuckups onder de noemer van: zet alles onder 1 dummy record en .. gebruik van soft delete.. terwijl een goed ontwerp van je informatiesysteem DE oplossing is..
En ook al hebben we een verschillende mening over de term soft-delete.. Ik kan me niet voorstellen dat een leraar mijn keuze zou afkeuren en geloof mij, daar heb ik alle redenen voor om dat te bedenken. Het zijn namelijk best-practices op dit vlak..

To mark a record in a database for deletion or to temporarily prevent it from being selected. In order to actually delete the record, a "hard" delete or "permanent" delete function must be performed.

het GAAT hier niet om toekomstig te verwijderen..dat is juist mijn punt. Ook al gaat dit wellicht de opdracht voorbij. Historische data MAG je niet verwijderen, je moet het alleen "links laten liggen" vanuit je applicatie.
Dit kan juist met een J/N boolean in de dimensie tabel.
Ik denk namelijk dat dit een dikke vette instinker is van de school. Want dit soort historie verwijder je niet.. je schakelt het alleen uit voor je applicatie en daarom is soft-delete een sleezy work around en zeker geen elegante oplossing..Het zou hier moeten gaan om design toch? en niet om een cursusje technische mogelijkheden...voila... ontwerp!

[ Voor 0% gewijzigd door een moderator op 11-03-2009 02:04 . Reden: Even zo vrij geweest een verkeerde [/qoute[ tag te fixen... ]

[RobIII]

Verwijderd schreef op woensdag 11 maart 2009 @ 01:38:
het GAAT hier niet om toekomstig te verwijderen..dat is juist mijn punt.

Er wordt ook niets verwijderd. Ik kan het niet anders zeggen maar WE ZEGGEN HETZELFDE!!!11. Koel even af, lees nog eens even rustig de laatste pagina door en probeer het dan nog eens

Een soft-delete is, in dit topic althans, nog nergens beschreven als RDBMS-afhankelijke vage feature maar gewoon een (EXACT hetzelfde als wat jij zegt) keuze in het ontwerp waarbij je een record markeert als "nog geldig" of "verwijderd" of "verborgen" of "verlopen" of whatever je het wil noemen. Wat jij onder die RDBMS afhankelijke (kennelijk MSSQL specifieke?) soft-delete verstaat weet ik niet. Maar ik ben er wel érg nieuwschierig naar. Voor educatieve doeleinden uiteraard

[ Voor 43% gewijzigd door RobIII op 11-03-2009 01:47 ]

[Verwijderd]

RobIII schreef op woensdag 11 maart 2009 @ 01:40:
[...]

Er wordt ook niets verwijderd. Ik kan het niet anders zeggen maar WE ZEGGEN HETZELFDE!!!11. Koel even af, lees nog eens even rustig de laatste pagina door en probeer het dan nog eens

ok.. gelukkig maar.. want ik dacht even dat je records wilde markeren voor deletion.. en dat schoot mij even in verkeerde keelgat

Dan liggen we op een lijn kunnen we alleen bekvechten over definities waar ik geen zin in heb..
we bedoelen dan hetzelfde..

[NMe]

Verwijderd schreef op woensdag 11 maart 2009 @ 01:38:
Ja misschien ga ik juist verder dan de opdracht.. Ik kom uit het bedrijfsleven en ik kan het gewoon niet waardere dat "pas opgeleiden" dit soort fuckups leren.

Toch moet je eerst leren lopen voordat je een marathon kan rennen.

Want, Nee wat ik zeg is letterlijk niet hetzelfde gezien het hier gaat om een DESIGN kwestie en geen technische work-around kwestie.

Een extra veldje in je tabel met een boolean die aangeeft of iets al dan niet verwijderd is is ook een DESIGN kwestie.

Het is zeker niet irrelevant of verwarrend.. mijn god.. overbodig? noem je het wegwuiven van data van 4 jaar ouder gewoon overbodig?? Ook al is het 5 jaar oud.. en op dit moment niet relevant.. er zijn momenten dat het WEL relevant is. en dat moet je het hebben.

En toch kan het voor bepaalde opdrachten in zijn geheel onzinnig zijn. Natuurlijk is het een best practice, en natuurlijk lost het het probleem op. Als ik een random icon zou willen hebben hier op het forum zou ik daar ook een compleet framework voor kunnen schrijven met allerlei functies die het heel gemakkelijk maken om images te manipuleren, maar uiteindelijk zou een simpele tabel in je database, een random select daarop (lang leve MySQL ) en uitvoeren van de in dat record gelinkte image óók voldoen. Een best practice is niet altijd meteen de beste keuze.

Ik kan me niet voorstellen dat een leraar mijn keuze zou afkeuren en geloof mij, daar heb ik alle redenen voor om dat te bedenken.

Je hebt zeker niet recent eens rondgekeken wat er voor malloten rondlopen op hogescholen en MBO's om les te geven?

---

edit:

In de context van de twee posts hierboven: lees dit even met een korreltje zout. Een soft-delete vlaggetje is voor een omgeschoolde bouwvakker die lesgeeft nog wel te begrijpen en dat zal 'ie ook wel goedkeuren, maar een datum opnemen en op die manier hiërarchie opbouwen wordt al gauw lastig. Weet ik helaas uit ervaring.

edit:

Hmm, ik realiseer me nu net dat ik een veel complexer beeld had van wat je bedoelde dan wat je echt bedoelt. Never mind.

[ Voor 12% gewijzigd door NMe op 11-03-2009 01:51 ]

[RobIII]

Verwijderd schreef op woensdag 11 maart 2009 @ 01:46:
[...]


ok.. gelukkig maar.. want ik dacht even dat je records wilde markeren voor deletion.. en dat schoot mij even in verkeerde keelgat

Pff, dat kostte me gelukkig niet veel overredingskracht _/sarcasm

Verwijderd schreef op woensdag 11 maart 2009 @ 01:46:
Dan liggen we op een lijn kunnen we alleen bekvechten over definities waar ik geen zin in heb..
we bedoelen dan hetzelfde..

Nou...

RobIII schreef op woensdag 11 maart 2009 @ 01:40:
Wat jij onder die RDBMS afhankelijke (kennelijk MSSQL specifieke?) soft-delete verstaat weet ik niet. Maar ik ben er wel érg nieuwschierig naar. Voor educatieve doeleinden uiteraard

Enlighten me

[ Voor 25% gewijzigd door RobIII op 11-03-2009 01:47 ]

[.oisyn]

Als iedereen nou gewoon mijn post had gelezen dan had het meteen duidelijk geweest: .oisyn in "[SQL] Constraint violation bij delete *"

.edit:

Daar zouden ze mensen voor op 't forum moeten aanstellen die dit soort topics in goede banen leiden...

offtopic:
't Is idd bergafwaarts gegaan sinds ik admin-af ben

[ Voor 36% gewijzigd door .oisyn op 11-03-2009 01:52 ]

[RobIII]

.oisyn schreef op woensdag 11 maart 2009 @ 01:49:
Als iedereen nou gewoon mijn post had gelezen dan had het meteen duidelijk geweest: .oisyn in "[SQL] Constraint violation bij delete *"

Joh We waren allemaal veel te druk met op onze toetsenborden rammen van boosheid om je reply te lezen

Wel grappig om te zien hoe een simpel 1+1 huiswerkvraagje kan ontsporen in een complete wanordelijke en hoogoplopende verhitte discussie waarin iedereen al van meet-af-aan hetzelfde roept maar niet iedereen dat door heeft. Daar zouden ze mensen voor op 't forum moeten aanstellen die dit soort topics in goede banen leiden...

.oisyn schreef op woensdag 11 maart 2009 @ 01:49:

offtopic:
't Is idd bergafwaarts gegaan sinds ik admin-af ben

EJ!

[ Voor 15% gewijzigd door RobIII op 11-03-2009 01:53 ]

[Patriot]

Bij de eerste comments (althans, sommige, NMe had het wel direct door) is onbewust het idee ontstaan dat het een oplossing moest zijn die alleen zijn betrekking had tot de databaselaag (i.e. geen soft deletes omdat die ook wijzigingen in de applicatie vereisen). Daar ben ik ook in mee gegaan, maar als ik de TS zo opnieuw lees dan is dat een onterechte conclusie.

In ieder geval is de discussie hier 'iets' langer doorgegaan dan nodig

[.Gertjan.]

Patriot schreef op woensdag 11 maart 2009 @ 12:31:
Bij de eerste comments (althans, sommige, NMe had het wel direct door) is onbewust het idee ontstaan dat het een oplossing moest zijn die alleen zijn betrekking had tot de databaselaag (i.e. geen soft deletes omdat die ook wijzigingen in de applicatie vereisen). Daar ben ik ook in mee gegaan, maar als ik de TS zo opnieuw lees dan is dat een onterechte conclusie.

In ieder geval is de discussie hier 'iets' langer doorgegaan dan nodig

offtopic:
Je kan ook soft deletes maken zonder dat je in je applicatie laag iets hoeft te doen. Zodra jij de gegevens ophaalt met stored procedures (hierover zijn denk ik ook al diverse oorlogen gevoerd ) dan voeg je in je storedprocedure in je where statement toe dat je geen deleted items wilt ophalen (bv WHERE DELETEDYN = 0).

Je applicatie zal ze dan niet tonen (dat is wat de klant wil, klant wil weg=weg en hij wil geen undelete), maar je kan ze later wel in reports terug laten komen, maar om de delete mogelijk te maken is dus niet altijd een applicatie wijziging nodig.

[.oisyn]

Dan moet je app wel al gebruik maken van een stored procedure om de data op te halen. Ik zou in dit geval eerder denken aan een view eigenlijk .

[ Voor 11% gewijzigd door .oisyn op 11-03-2009 12:56 ]

[.Gertjan.]

.oisyn schreef op woensdag 11 maart 2009 @ 12:56:
Dan moet je app wel al gebruik maken van een stored procedure om de data op te halen. Ik zou in dit geval eerder denken aan een view eigenlijk .

offtopic:
Inderdaad moet je app al stored procedures gebruiken, anders moet je dat eerst in je app bouwen . Maar goed zelfs om data uit de view te halen (en eventueel zoekparams op te kunnen geven) zou ik logischerwijs een SP gebruiken.

[ Voor 2% gewijzigd door .Gertjan. op 11-03-2009 13:25 . Reden: Even offtopic gemarkeerd om geen discussie over stored procedures te starten :) ]

[Woy]

.Gertjan. schreef op woensdag 11 maart 2009 @ 13:14:
[...]
Inderdaad moet je app al stored procedures gebruiken, anders moet je dat eerst in je app bouwen . Maar goed zelfs om data uit de view te halen (en eventueel zoekparams op te kunnen geven) zou ik logischerwijs een SP gebruiken.

Het haalt natuurlijk niet zoveel uit of je het nu in je SP of in je Applicatie aan moet passen. En laten we de discussie of je beter SP's of gewoon Query's uit je applicatie kunt gebruiken maar niet weer gaan starten Daar is in andere topics al genoeg over gezegd.

[curry684]

Woy schreef op woensdag 11 maart 2009 @ 13:21:
[...]

Het haalt natuurlijk niet zoveel uit of je het nu in je SP of in je Applicatie aan moet passen. En laten we de discussie of je beter SP's of gewoon Query's uit je applicatie kunt gebruiken maar niet weer gaan starten Daar is in andere topics al genoeg over gezegd.

En iedereen weet intussen al lang dat SP's kut zijn voor alles behalve DB-local maintenance jobs en helper procedures, en goede programmeurs ze in code mijden als de pest.

* curry684 rent

[Gé Brander]

curry684 schreef op donderdag 12 maart 2009 @ 00:17:
[...]

En iedereen weet intussen al lang dat SP's kut zijn voor alles behalve DB-local maintenance jobs en helper procedures, en goede programmeurs ze in code mijden als de pest.

* curry684 rent

En iedereen weet intussen dat de wereld niet meer zo zwart wit is en dat je SP's prima kunt gebruiken in sommige situaties, net als alle andere mogelijke oplossingen...

* Gé Brander duikt onder

[ Voor 6% gewijzigd door Gé Brander op 12-03-2009 08:50 ]

[Dido]

Stem tegen, stem SP, was het toch?

[Verwijderd]

En we hebben de opdracht besproken. Beste oplossing was dus om een Dummy account aan te maken, en daar de Orders op te zetten. In principe kan deze op slot, tenzij mensen verder willen discussieren

[Woy]

Een slotje is niet nodig op een topic als je je oplossing hebt. Zie daarvoor ook onze faq betreffende topiceinde.

Verder zou ik dat zeker niet de beste oplossing noemen. Het is eigenlijk iets wat je beter meteen weer kunt vergeten. Zoals al vaak genoeg in dit topic gezegd, is een soft-delete de beste oplossing.

Mischien kun je eens met je leraar bespreken of hij dat ook niet een betere oplossing vind. ( En als hij dat niet vind, zou ik hem voortaan niet zo serieus meer nemen )

[ Voor 8% gewijzigd door Woy op 13-03-2009 09:50 ]

[LinuX-TUX]

Verwijderd schreef op vrijdag 13 maart 2009 @ 09:44:
En we hebben de opdracht besproken. Beste oplossing was dus om een Dummy account aan te maken, en daar de Orders op te zetten. In principe kan deze op slot, tenzij mensen verder willen discussieren

O M G ...

Beste oplossing, gooi het over de heuvel, verdoezel je order gegevens, kan altijd de geschiedenis inkijken en je boekhouding oprecht opleveren want ja, DUMMY heeft zo'n beetje alle orders op z'n naam staan ... is kijken of de belastingdienst ed dat gewoon accepteren bij aanslagen.

Ik ga voor 1000% met Woy mee, als de leraar bij deze oplossing blijft in een operationeel & in gebruik genomen systeem, neem ik hem niet meer serieus.

edit:

Geen flame, snap dat je nog een cijfertje moet krijgen van diezelfde leraar, maar ... think about it

[ Voor 7% gewijzigd door LinuX-TUX op 13-03-2009 10:53 ]

[NMe]

Verwijderd schreef op vrijdag 13 maart 2009 @ 09:44:
En we hebben de opdracht besproken. Beste oplossing was dus om een Dummy account aan te maken, en daar de Orders op te zetten. In principe kan deze op slot, tenzij mensen verder willen discussieren

Mijn lage dunk van de gemiddelde leraar heeft bij dezen een all time low bereikt.

[Yoozer]

Verwijderd schreef op vrijdag 13 maart 2009 @ 09:44:
En we hebben de opdracht besproken. Beste oplossing was dus om een Dummy account aan te maken

Voer eens een praktijkvoorbeeld uit, en vraag dan waarom dat het Dummy-bedrijf 500 orders heeft die allemaal geen jota met elkaar te maken hebben, en hoe je ze terug wil halen als de directeur per ongeluk op het verkeerde knopje heeft gedrukt.

comedy option: laat je leraar dit topic zien. extra bonuspunten als 'ie een reply maakt.

[ Voor 9% gewijzigd door Yoozer op 13-03-2009 11:07 ]

[Creepy]

Jammer dat de leraren hier vaak niet meelezen. Dan had ie hopelijk ingezien dat wat ie nu doet toch niet helemaal klopt......

@Yoozer: (je reply stond er nog niet toen ik de twee zinnen hierboven aan het typen was).

offtopic:
Curry, je moet harder meppen met die zweep

[ Voor 39% gewijzigd door Creepy op 13-03-2009 11:10 ]

[Woy]

Zowiezo is het nogal onzinnig om een Dummy customer te maken. Zet dan gewoon de CustomerID op NULL ( Heb even in de Northwind DB gekeken en dat is toegestaan ). Dan is het tenminste duidelijk dat de Order niet meer bij een Customer hoort.

[Pathogen]

Ik frons mij half dubbel bij de oplossing die de leraar aanbrengt... Zelfs voor een begincursusje SQL is het uitermate vies om het relationele gedeelte uit "relationele database" te slopen.

[RobIII]

Verwijderd schreef op vrijdag 13 maart 2009 @ 09:44:
En we hebben de opdracht besproken. Beste oplossing was dus om een Dummy account aan te maken, en daar de Orders op te zetten. In principe kan deze op slot, tenzij mensen verder willen discussieren

1 Word:



Wat zou ik graag die leraar van jou eens ontmoeten
Heb je nog enig verweer gepleegd? Andere opties besproken? Dit topic aangehaald? Of heb je braaf zijn *kuch* onorthodoxe oplossing *kuch* door je strot laten glijden en ben je netjes ja en amen blijven knikken?

Het zijn precies dit soort leraren waardoor we, zodra jullie van school komen, we jullie eerst nog een jaar moeten kneden met harde hand voordat jullie eens een beetje productief zijn... Het zou verboden moeten worden.

[ Voor 32% gewijzigd door RobIII op 13-03-2009 12:06 ]

[Cr1mp]

De leraar gaf 2 mogelijkheden. (zit bij fregge in de klas)

een soft delete en een dummy waarvan hij zelf de soft delete beter vond.

[RobIII]

Cr1mp schreef op vrijdag 13 maart 2009 @ 13:06:
een soft delete en een dummy waarvan hij zelf de soft delete beter vond.

Grappig dat Fregge dat even "vergeet" erbij te vermelden...

[Creepy]

Maar wel goed dat de leraar beter z'n werk doet dan dat wij in eerste instantie dachten

[NMe]

Creepy schreef op vrijdag 13 maart 2009 @ 13:17:
Maar wel goed dat de leraar beter z'n werk doet dan dat wij in eerste instantie dachten

Nee hoor. Hij noemt die dummy record nog steeds als mogelijkheid en zoals fregge hier mooi demonstreert zal die mogelijkheid altijd door een student opgepakt worden... Een goeie leraar zou een dummy record alleen als voorbeeld mogen nemen als een student daarmee aankomt...en alleen om het daarna meteen af te fakkelen.

[ Voor 17% gewijzigd door NMe op 13-03-2009 13:24 ]

[Verwijderd]

RobIII schreef op vrijdag 13 maart 2009 @ 13:13:
[...]

Grappig dat Fregge dat even "vergeet" erbij te vermelden...

Ik ben snel afgeleid misschien dat ik daardoor die soft delete niet hoorde.

[curry684]

Verwijderd schreef op vrijdag 13 maart 2009 @ 13:22:
[...]


Ik ben snel afgeleid misschien dat ik daardoor die soft delete niet hoorde.

Want stel je voor dat je op school iets zou leren wat je later nog eens zou kunnen gebruiken, kamertje verhuren met de buurman is interessanter.