[SQL] Constraint violation bij delete *

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