[SQL] Constraint violation bij delete *

[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.

[raptorix]

Waarom zou je die klanten niet verwijderen? Je moet wel heel dom zijn als je je order table met je klanten table linked.

[curry684]

raptorix schreef op vrijdag 13 maart 2009 @ 15:13:
Waarom zou je die klanten niet verwijderen? Je moet wel heel dom zijn als je je order table met je klanten table linked.

Die onderliggende kwestie is ook al aangestipt dat je historische data niet aan realtime data moet koppelen, maar dat is toch een iets te advanced issue als het concept 'soft delete' al te hoog gegrepen is.

[Pathogen]

raptorix schreef op vrijdag 13 maart 2009 @ 15:13:
Waarom zou je die klanten niet verwijderen? Je moet wel heel dom zijn als je je order table met je klanten table linked.

Dat is wel heel kort door de bocht. Een order is van of voor een klant, dus die verwijzing maakt de order volledig. Hoe wil je anders kunnen zien waar je je order af moet leveren en wie er voor betaalt?

Voordat je de suggestie "Gewoon, dat in de orders tabel zetten" oppert, dat is erg veel dubbele gegevens kweken.

[RobIII]

Thrackan schreef op vrijdag 13 maart 2009 @ 15:27:
Voordat je de suggestie "Gewoon, dat in de orders tabel zetten" oppert, dat is erg veel dubbele gegevens kweken.

Toch is dat een in de praktijk veelvoorkomende oplossing. Zo kun je ook nog achterhalen waar die order van vorig jaar bezorgd is bijvoorbeeld. En zo is het ook gebruikelijk om de prijs van een product ook op te slaan bij een orderregel of factuur. Want wat als de prijs veranderd? Of een adres? Of een naam van een klant die overgenomen wordt? Dan klopt er geen zak meer van je historie. Redundante informatie is niet per definitie verkeerd en opslag kost geen drol per Gb. Hell, soms worden complete klanten, producten en andere informatie nog eens 'gekopieerd' en opgeslagen bij een order/factuur. Zo zit je nooit met omschrijvingen die gewijzigd worden waardoor jij de factuur van vorig jaar niet meer kunt re-produceren als de belastingdienst daar om vraagt. Want die komt dan niet (meer) overeen met wat je toen uitdraaide.

[ Voor 21% gewijzigd door RobIII op 13-03-2009 15:35 ]

[NMe]

raptorix schreef op vrijdag 13 maart 2009 @ 15:13:
Waarom zou je die klanten niet verwijderen? Je moet wel heel dom zijn als je je order table met je klanten table linked.

Pardon? Je hebt een relationele database, waarin je klanten opslaat. Klanten hebben orders. Waarom zou je die link in godsnaam niet leggen?

En voordat je suggereert wat Rob hierboven zegt: dat kan ook op andere manieren binnen een RDBMS.

[ Voor 12% gewijzigd door NMe op 13-03-2009 15:33 ]

[Woy]

RobIII schreef op vrijdag 13 maart 2009 @ 15:29:
[...]
Redundante informatie is niet per definitie verkeerd en opslag kost geen drol per Gb.

En bovendien kun je er ook nog over discussieren of het wel redundante informatie is. Het is op dat moment immers informatie van de factuur.

raptorix schreef op vrijdag 13 maart 2009 @ 15:13:
Waarom zou je die klanten niet verwijderen? Je moet wel heel dom zijn als je je order table met je klanten table linked.

Soms is het nou eenmaal handig dat je bij een klant nog op kan zoeken welke orders hij heeft geplaatst. Dat neemt niet weg dat het vaak handig is om je klant gegevens ook bij je factuur op te slaan.

[curry684]

Woy schreef op vrijdag 13 maart 2009 @ 15:36:
[...]

En bovendien kun je er ook nog over discussieren of het wel redundante informatie is. Het is op dat moment immers informatie van de factuur.

Het is niet redundant, het is historisch. Dingen als 'versioning' wat dit in beginsel is zijn binnen een OLTP database gewoon gangbaar.

Soms is het nou eenmaal handig dat je bij een klant nog op kan zoeken welke orders hij heeft geplaatst. Dat neemt niet weg dat het vaak handig is om je klant gegevens ook bij je factuur op te slaan.

De klant zelf moet ook gelinkt blijven ja zodat je kunt opzoeken wat de huidige status van die klant is bij een nabestelling of garantiekwestie. Maja dan is het wel zo fijn als bij die klant duidelijk staat dat ie geen klant meer is op basis van de soft-delete

[RobIII]

Woy schreef op vrijdag 13 maart 2009 @ 15:36:
[...]

En bovendien kun je er ook nog over discussieren of het wel redundante informatie is. Het is op dat moment immers informatie van de factuur.

Euh, wat curry zegt Ik had redundant nog tussen aanhalingstekens willen zetten; want redundant is het niet.

[.Gertjan.]

Woy schreef op vrijdag 13 maart 2009 @ 15:36:
[...]

En bovendien kun je er ook nog over discussieren of het wel redundante informatie is. Het is op dat moment immers informatie van de factuur.

Om te voorkomen dat je redundante informatie opslaat zou je een soort "houdbaarheid" toe kunnen passen in je record. Je koppelt de factuur dus wel aan de klant tabel, maar als het klant record wordt aangepast maak je een nieuwe versie die je weer linkt aan de oude (of andersom) en markeert het oude record met een "valid until" datum.

Op die manier zouden alle klanten netjes in de klanten tabel blijven en heb je een koppeling tussen beide tabellen. Mocht er niets aan de klant veranderen staat hij er maar 1x in en is hij dus niet redundant.

Jou zou zelfs een constructie kunnen maken waar je een klant tabel hebt met alleen een ID en dan een klantdetail tabel met daarin de details met hun houdbaarheidsdatum. Dan kun je ook snel opvragen welke orders een klant heeft

Waarschijnlijk is niet iedereen het met mij eens (waarschijnlijk = natuurlijk )

* .Gertjan. rent weg...

[NMe]

.Gertjan. schreef op vrijdag 13 maart 2009 @ 15:45:
[...]

Da's inderdaad wat ik bedoelde met

NMe schreef op vrijdag 13 maart 2009 @ 15:32:
En voordat je suggereert wat Rob hierboven zegt: dat kan ook op andere manieren binnen een RDBMS.

[curry684]

Met het concept ben ik het wel eens, met de uitvoering niet Gangbaar is om gewoon de 'bedrijfsinfo' van de klant los te koppen van de 'klant' - ze hebben beiden een foreign key naar elkaar maar de relatie is wel 1 op meer doordat de klant linkte naar de actuele geldige informatie. Een order zal moeten linken naar de op het moment van bestellen geldige informatie. Waarbij informatie uit de tabel 'bedrijfsinfo' vanzelfsprekend nooit geupdate of deleted mag worden.

Wat je met houdbaarheidsdata wil snap ik niet helemaal en het klinkt me toch al overcomplex voor een simpel gangbaar vraagstuk

[ Voor 12% gewijzigd door curry684 op 13-03-2009 15:49 ]

[.Gertjan.]

curry684 schreef op vrijdag 13 maart 2009 @ 15:49:
Wat je met houdbaarheidsdata wil snap ik niet helemaal en het klinkt me toch al overcomplex voor een simpel gangbaar vraagstuk

offtopic:
Waarom zou je makkelijk doen als het ook moeilijk kan worden opgelost. Je moet jezelf als IT-er toch in de markt houden he . Maar je hebt gelijk, het is misschien wat overkill, maar als toekomstige IT-er heeft de TS er misschien wat aan om te lezen hoe "professionals" het zouden oplossen.

Met houdbaarheid bedoel ik dat je aangeeft in welke periode een record "actueel" was. Zie het een beetje als valuta koersen. Als je dat in een tabel zet zet je er ook bij voor welke periode die koers geldig was. Zo zou je dat ook met adres gegevens en dergelijke kunnen doen. Die koersen koppel je dan weer aan "statische" informatie van de valuta (naam bijvoorbeeld).

[ Voor 11% gewijzigd door .Gertjan. op 13-03-2009 15:59 ]

[Woy]

curry684 schreef op vrijdag 13 maart 2009 @ 15:42:
[...]

Het is niet redundant, het is historisch. Dingen als 'versioning' wat dit in beginsel is zijn binnen een OLTP database gewoon gangbaar.

[...]

De klant zelf moet ook gelinkt blijven ja zodat je kunt opzoeken wat de huidige status van die klant is bij een nabestelling of garantiekwestie. Maja dan is het wel zo fijn als bij die klant duidelijk staat dat ie geen klant meer is op basis van de soft-delete

Dat is idd precies wat ik bedoelde

[Pathogen]

Helemaal eens met Gertjan, ik kies liever voor valid_from en valid_till contructies, zowel voor tarieven, prijzen, exchange rates en historische klantdata.
Zeker op grote schaal koppel ik dat liever op die manier, maar ieder heeft zo zijn voorkeuren.

Per definitie is het inderdaad niet "fout" om bepaalde data redundant op te slaan ten behoeve van historie en dit kan op meerdere manieren.

[Alain]

Thrackan schreef op vrijdag 13 maart 2009 @ 16:18:
ik kies liever voor valid_from en valid_till contructies, zowel voor tarieven, prijzen, exchange rates en historische klantdata.

Ik denk dat het afhangt van de wensen. Wil je onafhankelijk van de order weten wat de valuta op een bepaald moment in het verleden was? Wil je onafhankelijk van de order de klantinformatie naar boven halen die geldig was op een bepaald moment in het verleden? Zo ja, dan zou je die informatie op moeten slaan.

Alles wat je maakt dat niet gevraagd wordt kost extra geld.

[Gomez12]

AlainS schreef op vrijdag 13 maart 2009 @ 18:09:
[...]
Alles wat je maakt dat niet gevraagd wordt kost extra geld.

Dat is geen harde stelling die je imho zo maar kan maken. Bepaalde functionaliteit is gewoon basisfunctionaliteit en opgelegd door andere partijen ( bijv belastingdienst ) waar de klant niet altijd alle ins en outs van kent.

Ik ben in ieder geval nog nooit tegen een klant aangelopen die specificeerde dat als er een factuur gemaakt werd dat dan van die artikelen wel in het eerdere traject de harde eis was dat daar een voorraadmutatie voor plaatsvond. Dat is gewoon een basisprincipe wat de klant niet hoeft te vragen.
Net zomin als dat er prijzen op een factuur moeten staan en dat die niet opnieuw handmatig ingevoerd moeten worden als er gewoon een verkooporder onderligt.

Van de belasting moet je als ondernemer afaik tot 7 jaar terug je originele facturen ( dus met toenmalige NAW gegevens ) op de een of andere manier kunnen tonen.

Dan vind ik het heden ten dage onrealistisch om als software partij maatwerk / extra werk hiervoor te gaan verrichten om het ook digitaal te kunnen, een klant vraagt hier niet specifiek om, maar verwacht het imho wel.

[Alain]

Gomez12 schreef op vrijdag 13 maart 2009 @ 19:54:
Bepaalde functionaliteit is gewoon basisfunctionaliteit en opgelegd door andere partijen ( bijv belastingdienst ) waar de klant niet altijd alle ins en outs van kent.

Ik heb zelf te maken met vrij strenge regelgeving (scheepvaart) en ik neem deze regelgeving mee in de basisopdracht. De klant vraagt mij om een systeem dat voldoet aan de regelgeving en dus wordt het wel degelijk gevraagd.

Van de belasting moet je als ondernemer afaik tot 7 jaar terug je originele facturen ( dus met toenmalige NAW gegevens ) op de een of andere manier kunnen tonen.

Ik heb geen verstand van de belastingdienst, maar als het waar is wat je zegt is het hele vraagstuk opgelost.

Dan vind ik het heden ten dage onrealistisch om als software partij maatwerk / extra werk hiervoor te gaan verrichten om het ook digitaal te kunnen, een klant vraagt hier niet specifiek om, maar verwacht het imho wel.

Als het voor de regelgeving niet nodig is en de klant vraagt er niet om is het extra werk. Als je denkt dat de klant het wel verwacht moet je het mee nemen in de basisopdracht. Of beter nog: De klant vragen of hij het verwacht.

[NMe]

AlainS schreef op vrijdag 13 maart 2009 @ 18:09:
[...]

Ik denk dat het afhangt van de wensen. Wil je onafhankelijk van de order weten wat de valuta op een bepaald moment in het verleden was? Wil je onafhankelijk van de order de klantinformatie naar boven halen die geldig was op een bepaald moment in het verleden? Zo ja, dan zou je die informatie op moeten slaan.

Alles wat je maakt dat niet gevraagd wordt kost extra geld.

Je maakt daarbij wel een belangrijke nuancering niet. Als jij redelijkerwijs kan verwachten dat een klant iets op een bepaalde manier verwacht of in alle redelijkheid kan aannemen dat iets in de toekomst anders/gedetailleerder moet, dan kun je het net zo goed als extra stukje service opnemen. Desnoods pas je je datamodel er vast op aan en maak je er in je applicatie zelf nog geen gebruik van, om zo een eventueel SLA-gevalletje of een vervolgopdracht sneller te laten gaan.

[Gomez12]

AlainS schreef op vrijdag 13 maart 2009 @ 20:08:
[...]
Ik heb zelf te maken met vrij strenge regelgeving (scheepvaart) en ik neem deze regelgeving mee in de basisopdracht. De klant vraagt mij om een systeem dat voldoet aan de regelgeving en dus wordt het wel degelijk gevraagd.

Voldoen aan is op meerdere manieren uit te leggen, zie iets verderop.
Maar sowieso vraag ik me af of je klant echt vraagt of de software 100% voldoet aan 100% van de scheepvaart regelgeving, of dat het meer is dat een klant zegt dat hij bijv "bijna alleen" maar handelt in zeeschepen en of de software voldoet aan alle regelgeving?
Waardoor bij een verkeerde interpretatie je dus discussie kan krijgen over privejachten etc. Klant vroeg om alle regelgeving, programmeurs interpreteerden dit als alle regelgeving van toepassing op zeeschepen.

[...]
Ik heb geen verstand van de belastingdienst, maar als het waar is wat je zegt is het hele vraagstuk opgelost.

Nee. Een papieren archief is voor de belastingdienst ook gewoon aanvaardbaar.
Puur sec gezien hoef je als programmeur geen rekening te houden bijv een belastingdienst en een 7 jaar bewaarplicht. Het is de verantwoordelijkheid van de klant om een archief bij te houden, of hij dit op papier doet of digitaal is niet jouw probleem als je jouw zwart-wit stelling volgt.
Meeste klanten zullen er waarschijnlijk niet om vragen, maar gewoon verwachten dat het erin zit. Terwijl dit vanuit regelgeving helemaal geen verplichting is.
Zie je het zwart-witte van je stelling al?

[...]
Als het voor de regelgeving niet nodig is en de klant vraagt er niet om is het extra werk. Als je denkt dat de klant het wel verwacht moet je het mee nemen in de basisopdracht. Of beter nog: De klant vragen of hij het verwacht.

Voor de meeste regelgeving is op IT-gebied eigenlijk verrekte weinig nodig, regelgeving biedt afaik nog steeds de mogelijkheid om alles op papier te doen, dus alle regels vereisen dan ook minimaal papier. Als jij een print kan maken voldoe je aan zo ongeveer alle regelgeving.
Ander voorbeeld, op zich is er qua regelgeving niets mis met een hardcoded btw-percentage, zolang de klant niet vraagt of het veranderd kan worden is het meerwerk? Of gooi je het toch stiekem in een tabelletje zodat de klant het kan wijzigen?

[Alain]

NMe schreef op vrijdag 13 maart 2009 @ 20:11:
Je maakt daarbij wel een belangrijke nuancering niet. Als jij redelijkerwijs kan verwachten dat een klant iets op een bepaalde manier verwacht of in alle redelijkheid kan aannemen dat iets in de toekomst anders/gedetailleerder moet, dan kun je het net zo goed als extra stukje service opnemen. Desnoods pas je je datamodel er vast op aan en maak je er in je applicatie zelf nog geen gebruik van, om zo een eventueel SLA-gevalletje of een vervolgopdracht sneller te laten gaan.

Volgens mij ben je dan geld aan het weggooien. Je maakt dan een product zoals de klant het wil hebben en laat hem alleen betalen voor hetgeen wat hij omschrijft. Als je het mis hebt gooi je geld weg en als je opdracht krijgt, krijg je te weinig betaald.

Als ik het idee heb dat een klant iets verwacht wat niet in de specificatie staat, dan vraag ik rechtstreeks of het verwacht wordt of niet.

Ik moet wel zeggen dat ik voor 50% bezig ben met universele systemen waar een klant niet eens invloed op heeft en 50% met klantspecificieke oplossingen.

[Gomez12]

Geld weggooien is alleen van toepassing als dit een eenmalig iets is enkel en alleen voor deze klant.

Wil je het morgen weet kunnen slijten aan een andere klant dan kan je maar beter rekening houden met een aantal basisprincipes, anders wordt je meerwerk voor de volgende klant zo groot dat niemand je pakket meer hoeft of je krijgt zoveel verschillende versies inclusief maatwerk dat je gewoon een uitdaging hebt gecreeerd qua versie beheer.

Wil je (imho) echt goed bezig zijn, dan zorg je ervoor dat je voor de 1e klant een extra investering doet zodat je juist op klant 2 t/m 10 extra winst kan halen doordat dat gewoon geen extra werk meer is.

[Alain]

Gomez12 schreef op vrijdag 13 maart 2009 @ 20:25:
Voldoen aan is op meerdere manieren uit te leggen, zie iets verderop.
Maar sowieso vraag ik me af of je klant echt vraagt of de software 100% voldoet aan 100% van de scheepvaart regelgeving, of dat het meer is dat een klant zegt dat hij bijv "bijna alleen" maar handelt in zeeschepen en of de software voldoet aan alle regelgeving?
Waardoor bij een verkeerde interpretatie je dus discussie kan krijgen over privejachten etc. Klant vroeg om alle regelgeving, programmeurs interpreteerden dit als alle regelgeving van toepassing op zeeschepen.

Een systeem moet in de scheepvaart voldoen aan de regels die (uiteindelijk) door de verzekering gesteld worden. De klant weet meestal niet veel van de regelgeving van mijn systeem. De klant specificeert dat het systeem moet voldoen aan regelgeving x. Voordat het systeem bij ons vertrekt wordt het beken door een surveyor van regelgeving x. Als programmeur/ontwikkelaar van deze systemen moet je de regelgeving kennen.

Nee. Een papieren archief is voor de belastingdienst ook gewoon aanvaardbaar.
Puur sec gezien hoef je als programmeur geen rekening te houden bijv een belastingdienst en een 7 jaar bewaarplicht. Het is de verantwoordelijkheid van de klant om een archief bij te houden, of hij dit op papier doet of digitaal is niet jouw probleem als je jouw zwart-wit stelling volgt.
Meeste klanten zullen er waarschijnlijk niet om vragen, maar gewoon verwachten dat het erin zit. Terwijl dit vanuit regelgeving helemaal geen verplichting is.

Dat ontken ik ook niet, sterker nog ik gebruik deze flexibiliteit van de regels soms. Ik probeer alleen aan te geven dat volgens jou informatie alleen de historische data van belang is en niet de extra valid_from en valid_until data.

Ander voorbeeld, op zich is er qua regelgeving niets mis met een hardcoded btw-percentage, zolang de klant niet vraagt of het veranderd kan worden is het meerwerk? Of gooi je het toch stiekem in een tabelletje zodat de klant het kan wijzigen?

Als ik vind dat het gebruikersvriendelijk is en het is geen klantspecifiek product, dan neem ik het mee. Als het klantspecifiek is vraag ik de klant of deze het verwacht. Als de klant aangeeft het niet te willen en het achteraf toch wil, dan krijgt hij een meerprijs.

[Alain]

Gomez12 schreef op vrijdag 13 maart 2009 @ 20:37:
Geld weggooien is alleen van toepassing als dit een eenmalig iets is enkel en alleen voor deze klant.

Wil je het morgen weet kunnen slijten aan een andere klant dan kan je maar beter rekening houden met een aantal basisprincipes, anders wordt je meerwerk voor de volgende klant zo groot dat niemand je pakket meer hoeft of je krijgt zoveel verschillende versies inclusief maatwerk dat je gewoon een uitdaging hebt gecreeerd qua versie beheer.

Wil je (imho) echt goed bezig zijn, dan zorg je ervoor dat je voor de 1e klant een extra investering doet zodat je juist op klant 2 t/m 10 extra winst kan halen doordat dat gewoon geen extra werk meer is.

Wij ontwikkelen nieuwe producten niet op kosten van 1 klant. Ik boek de uren op een intern project en de kosten worden gerekent in de verkoopprijs.

[raptorix]

NMe schreef op vrijdag 13 maart 2009 @ 15:32:
[...]

Pardon? Je hebt een relationele database, waarin je klanten opslaat. Klanten hebben orders. Waarom zou je die link in godsnaam niet leggen?

En voordat je suggereert wat Rob hierboven zegt: dat kan ook op andere manieren binnen een RDBMS.

Hier doelde ik dus op, had niet de hele thread gelezen
Koppelen kan soms handig zijn, maar dus niet om de genoemde redenen
De ideale situatie in een relationeel model is dus om je order table te linken met een kruistabel naar persoonsgegevens, zodat je historische gegevens over de persoon kan bewaren (bijvoorbeeld als een persoon van adres veranderd). Dan zijn je orders direct aan de relevante persoonsgegvens gebonden.

[NMe]

raptorix schreef op zondag 15 maart 2009 @ 10:31:
[...]

Hier doelde ik dus op, had niet de hele thread gelezen
Koppelen kan soms handig zijn, maar dus niet om de genoemde redenen
De ideale situatie in een relationeel model is dus om je order table te linken met een kruistabel naar persoonsgegevens, zodat je historische gegevens over de persoon kan bewaren (bijvoorbeeld als een persoon van adres veranderd). Dan zijn je orders direct aan de relevante persoonsgegvens gebonden.

Dat is inderdaad mijn huidige keuze voor orders in het systeem waar ik nu aan werk. Orders verwijzen naar adressen, adresrecords kunnen niet geupdatet worden. Wanneer je een adres aanpast wordt er een nieuw record aangemaakt die verwijst naar het vorige ID en wordt de klant geupdatet om te verwijzen naar het nieuw record. Eventueel met een "changed on" date erbij heb je alle historie die je zou willen, zonder overbodige redundantie.

[Janoz]

raptorix schreef op zondag 15 maart 2009 @ 10:31:
[...]

Hier doelde ik dus op, had niet de hele thread gelezen
Koppelen kan soms handig zijn, maar dus niet om de genoemde redenen
De ideale situatie in een relationeel model is dus om je order table te linken met een kruistabel naar persoonsgegevens, zodat je historische gegevens over de persoon kan bewaren (bijvoorbeeld als een persoon van adres veranderd). Dan zijn je orders direct aan de relevante persoonsgegvens gebonden.

De klant wordt niet anders, enkel een paar gegevens van de klant worden anders. Ikzelf zou eerder een oplossing kiezen waarbij je niet via een koppeltabel aan de klant zit, maar de veranderbare gegevens als een 1 op meer relatie met de klant modeleren. Op die manier heb je ook de controle over welke onderdelen wel, maar vooral niet veranderd mogen worden. Een adres, contactpersoon, rekeningnummer kan allemaal veranderen, maar een klantnummer hou je graag hetzelfde.

[.Gertjan.]

AlainS schreef op vrijdag 13 maart 2009 @ 20:28:
[...]

Volgens mij ben je dan geld aan het weggooien. Je maakt dan een product zoals de klant het wil hebben en laat hem alleen betalen voor hetgeen wat hij omschrijft. Als je het mis hebt gooi je geld weg en als je opdracht krijgt, krijg je te weinig betaald.

Hier wil ik toch nog even op reageren. Misschien wat off-topic, maar goed. In principe heb je gelijk dat je geen dingen moet maken die de klant niet vraagt, omdat de klant daar niet (altijd) voor zal betalen, maar van een (goede) developer wordt verwacht dat hij ook rekening houdt met de toekomst. In sommige gevallen moet je dus gewoon wat extra's doen. Mocht de klant dan alsnog die wijziging willen dan kun je die snel implementeren. Als je grote systemen maakt (in de range tonnen tot miljoenen) dan maakt dat extra uurtje wat je besteed om een goede oplossing te maken niets meer uit.

Als je puur maakt wat de vraag is en verder niet nadenkt krijg je vaak slecht uitbreidbare systemen. Die gaan door de jaren heen steeds verder vervuilen met vieze hacks en dergelijke. Ik zit momenteel ook aan een applicatie te werken die al ongeveer 10 jaar draait en waar steeds weer wat extra dingen ingeprikt zijn op een zeer vieze manier (wijziging in de tabel levert vaak een wijziging op tientallen classes/schermen) . Op een gegeven moment is de rek eruit en moet je het in zijn geheel vervangen.

Ook vind ik dat je wanneer je meedenkt met de klant (en eventueel rekening houdt met toekomstige wensen) de klant meer waar voor zijn geld krijgt (is in eerste instantie dus een kleine investering van de developer en zijn bedrijf) en later sneller geneigd zou zijn om een vervolg opdracht te geven aan dat bedrijf.

Tevens is het vaak zo dat een wijziging in de opzet fase sneller is te implementeren dan wanneer het systeem al helemaal gemaakt is. Zodra het systeem draait zit je altijd met zaken als data conversie als je drastisch in je datamodel gaat snijden. Ook moet je heel goed testen omdat het systeem gebouwd is op het oude model. In een vroeg stadium dingen inbouwen is dus soms "winstgevender" dan achteraf.

Zelf heb ik vaak discussies met mensen die niet verder kijken dan hun neus lang is en dus echt alleen bouwen wat nodig is. Als dan vervolgens uit de discussie blijkt dat ze toch beter een stukje meer kunnen doen en de klant vraagt een half jaar later om die functionaliteit dan konden we die snel opleveren en had ik altijd het gevoel van: "Zie je wel 8)"

Misschien een voorbeeldje om te illustreren dat je met een stukje verder denken een heel eind komt. Stel je hebt een persoon tabel in de DB. Een persoon heeft een adres. Vaak sla je het adres op in velden behorende tot de persoon. Als je verder denkt hebben (later) misschien meerdere "objecten" in de db een adres nodig (bijvoorbeeld een bedrijf). Als je vervolgens een adres tabel maakt en koppelt kun je in de toekomst bijvoorbeeld ook een persoon meerdere adressen toewijzen. Het is bij het bouwen maar een kleine investering met in mijn ogen weinig impact, maar als je dat moet doen in een groot en werkend systeem dan is het een stuk moeilijker.

[Pathogen]

AlainS schreef op vrijdag 13 maart 2009 @ 18:09:
[...]


Ik denk dat het afhangt van de wensen. Wil je onafhankelijk van de order weten wat de valuta op een bepaald moment in het verleden was? Wil je onafhankelijk van de order de klantinformatie naar boven halen die geldig was op een bepaald moment in het verleden? Zo ja, dan zou je die informatie op moeten slaan.

Alles wat je maakt dat niet gevraagd wordt kost extra geld.

Ja, dat wil ik allemaal weten. Ook historie moet gecorrigeerd kunnen worden in het uiterste noodgeval dat er in een order van 5 jaar oud nog fouten terugkomen (vies, maar het gebeurt toch zo'n 1 a 2 keer per jaar op 250+ gebruikers) als de belastingdienst toch maar eens besluit om bij een van onze klanten binnen te vallen.

Ik merk, en dat kan persoonlijk zijn, dat op een schaal als deze, waarbij enkele duizenden klanten tientallen orders per week binnenschieten, er altijd fouten gemaakt worden, en dat deze altijd uiteindelijk door iemand hier op de afdeling opgelost moeten worden.
Als er ook maar iets niet historisch traceerbaar is wordt dat herstellen een enorme rotklus.

[raptorix]

Janoz schreef op zondag 15 maart 2009 @ 13:45:
[...]

De klant wordt niet anders, enkel een paar gegevens van de klant worden anders. Ikzelf zou eerder een oplossing kiezen waarbij je niet via een koppeltabel aan de klant zit, maar de veranderbare gegevens als een 1 op meer relatie met de klant modeleren. Op die manier heb je ook de controle over welke onderdelen wel, maar vooral niet veranderd mogen worden. Een adres, contactpersoon, rekeningnummer kan allemaal veranderen, maar een klantnummer hou je graag hetzelfde.

Klopt dat bedoelde ik ook min of meer te zeggen.

[Janoz]

Thrackan schreef op maandag 16 maart 2009 @ 14:02:
[...]


Ja, dat wil ik allemaal weten. Ook historie moet gecorrigeerd kunnen worden in het uiterste noodgeval dat er in een order van 5 jaar oud nog fouten terugkomen (vies, maar het gebeurt toch zo'n 1 a 2 keer per jaar op 250+ gebruikers) als de belastingdienst toch maar eens besluit om bij een van onze klanten binnen te vallen.

Ik merk, en dat kan persoonlijk zijn, dat op een schaal als deze, waarbij enkele duizenden klanten tientallen orders per week binnenschieten, er altijd fouten gemaakt worden, en dat deze altijd uiteindelijk door iemand hier op de afdeling opgelost moeten worden.
Als er ook maar iets niet historisch traceerbaar is wordt dat herstellen een enorme rotklus.

Goed, het wordt behoorlijk offtopic, maar toch wil ik hier even op ingaan. Je haalt twee verschillende tijdsdimensies door elkaar. Aan de ene kant heb je namelijk de 'normale' temporele data. Waar woon je nu, waar woonde je vorige week en waar woon je volgend jaar. Dat zijn de gegevens die eventueel aangepast moeten worden voor een order waarbij een verkeerd adres bij de client stond

Aan de andere kant heb je het audit trail. Daarin worden records gemaakt, maar nooit meer veranderd! Daarin staat bijvoorbeeld waar we vorige week of vorig jaar dachten dat je nu zou wonen en waar je vorige week woonde. Dat is de informatie waar de belastingdienst, maar vooral de accountant geinterreseerd kan zijn. Je wilt immers ook later nog kunnen zien waarom die order vorige week fout had kunnen gaan terwijl de database er nu uitziet alsof alles goed had moeten gaan.

[raptorix]

Een ex-collega had trouwens een uitstekend boekwerkje over databases en historische data, zal eens achterhalen wat de titel daarvan was, het was een creme kleurachtige boekje met volgens mij de Big Ben op de voorkant.