Hi Reinoud,
Bij de reversie oplossing krijg je wel dat er bij een object van een
bepaalde datum weer de juiste childs horen. Geloof dat een generieke
reversie oplossing wel de juiste koers is.
Zou het bij de lockvlag dan handig zijn bij parent-child locks(/datum
restricties) per model de lock op te slaan of deze condities in je code op
te nemen? Dus bij een child edit de parent checken op lock status?
Mvrgr,
Gerard.
On 07-07-10 17:03, Reinoud van Leeuwen wrote:
On Wed, Jul 07, 2010 at 04:36:09PM +0200, Gerard Petersen wrote:
Hi All,
Ik ben recent met een facturatie pakket online gegaan en loop tegen een
interresant fenomeen aan. Ik zou hierover graag jullie input hebben.
Ik probeer alles zo dynamisch mogelijk af te handelen in mijn django app,
maar door wettelijke verplichting bijvoorbeeld, onstaan er noodzakelijke
wijzigingen.
Je beschrijft een klassiek probleem (of een keuze) bij het ontwerpen van
databases. Stop je wel of niet een 'tijdas' in je model? Is je database
een afspiegeling van hoe het nu is, of moet het model ook de situatie op
'datum X' kunnen weergeven.
In relationele databases los je zoiets vaak op door elk record een begin-
en einddatum te geven, en bij elke mutatie het bestaande record een
einddatum te geven en een nieuwe toe te voegen.
In jouw situatie denk ik dat je een soort lockvlaggetje op bepaalde
objecten zult moeten implementeren dat aangeeft dat een object niet meer
aangepast mag worden.
Reinoud
_______________________________________________
Python-nl mailing list
Python-nl@python.org
http://mail.python.org/mailman/listinfo/python-nl
