[DB ontwerp] Financiële en webapp database scheiden?

[Verwijderd]

Hoi,

Ok, ik heb mijn post compleet opnieuw geschreven, omdat ik tijdens het schrijven ervan op een nieuwe vraag kwam. Here we go:

Ik ben bezig met een webapplicatie waarmee bezoekers producten kunnen zoeken en vergelijken. Bezoekers kunnen op een product_specs pagina een formulier invullen om informatie aan te vragen over dat product bij de leverancier. Voor zo'n aanvraag wordt in de toekomst eventueel een bedrag gerekend aan de leverancier.

Zo'n informatie-aanvraag is dus een item dat momenteel bij de webapplicatie hoort (en meer specifiek, bij een product en een leverancier), maar het hoort ook bij de financiële administratie.

Leveranciers kunnen in de webapplicatie zelf producten invoeren, wijzigen en verwijderen. Als een leverancier een product verwijdert zou ik om de integriteit van de database te behouden ook de bij dat product horende aanvragen moeten verwijderen. Probleem is echter dat ik deze informatie nodig heb (5 jaar lang als ik me niet vergis) voor de financiële administratie. Daarbij wil ik ze ook behouden voor latere analyse.

Wat zal ik doen? Producten en bijbehorende aanvragen helemaal verwijderen is geen optie, dus ik kan

(1) bij een verwijderd product en zijn aanvragen een bit veld 'deleted' op 1 zetten. Als er een leverancier verwijderd wordt, zal ik zelfs en de leverancier, en de producten voor die leverancier en de aanvragen voor de producten op deleted = 1 moeten zetten.
Zo bewaar ik de hele geschiedenis in de webapp database.
(2) een aparte database maken voor de financiële administratie, waarin ik gewoon de hele geschiedenis bewaar. Ik zou verwijderde producten en aanvragen in de webapp database dan verwijderen nadat ik met een dagelijkse job de financiele database geupdate heb.

Het nadeel van optie (1): waarom items die nooit meer gebruikt worden opslaan in mijn webapp database? Performance-wise geen ramp, maar het voelt gewoon niet ok.

Het nadeel van optie (2): Ik zal producten en bijbehorende aanvragen nog steeds niet direct kunnen verwijderen uit de webapp database. Dit kan pas als ik zeker weet dat eventuele informatie-aanvragen die dag voor dat product meegenomen zijn in de dagelijkse job om de financiële database te updaten. Ik zal dus alsnog met een 'deleted' veld moeten gaan werken voor als de aanvragen weg mogen, maar nog niet in de financiële database staan.

Kortom 'de boel bij elkaar houden' of verdelen en heerschen?

ps: laatste optie die ik verzin is realtime updaten van de financiële database. Dus aanvragen voor die dag wegschrijven in de financiele database en daarna verwijderen uit de webapp database.

[ Voor 12% gewijzigd door Verwijderd op 09-01-2006 22:25 ]

[djluc]

Bij elkaar houden is erg eenvoudig, snel om te ontwikkelen en simpel te controleren op integriteit. Je kan bijvoorbeeld delete en update queries onmogelijk maken voor de webapplicatie databaseuser. Dan weet je zeker dat alleen de originele gegevens bewaard worden.

[ripexx]

Eigenlijk is het veel eenvoudiger, je verwijder geen product, ook niet logisch maar je geeft het gewoon een einddatum. Product verschijnt niet meer en jij hebt je data nog. Oplossingen met logisch verwijderen enz. zijn eigenlijk houtje touwtje oplossingen.

[NetForce1]

djluc schreef op maandag 09 januari 2006 @ 19:10:
Bij elkaar houden is erg eenvoudig, snel om te ontwikkelen en simpel te controleren op integriteit. Je kan bijvoorbeeld delete en update queries onmogelijk maken voor de webapplicatie databaseuser. Dan weet je zeker dat alleen de originele gegevens bewaard worden.

Dan zou je dus een extra tabel bij moeten houden met alle verwijderde records.

[The Eagle]

ripexx schreef op maandag 09 januari 2006 @ 19:13:
Eigenlijk is het veel eenvoudiger, je verwijder geen product, ook niet logisch maar je geeft het gewoon een einddatum. Product verschijnt niet meer en jij hebt je data nog. Oplossingen met logisch verwijderen enz. zijn eigenlijk houtje touwtje oplossingen.

^^^ helemaal met stom

Ik werk zelf met PeopleSoft Financials(ERP-systeem), en daar zie je een dergelijke oplossing in de praktijk. Wat er gebeurt:
Iedere rij heeft een veld "active_status" en "effective_date". Dat laatste moet je als ingangsdatum van de wijziging zien. Zo kun je dus door effective status dusdanig selecteren, dat niet-actieve producten niet meer getoond worden bij een search. Effective date is zoals gezegd de ingangsdatum van de wijziging. Dit werkt als volgt:
Stel het volgende product (A), met rijen in de DB:
Ingangsdatum 1-1-2005, status inactief, naam "nog te verzinnen"
Ingangsdatum: 1-11-2005, status "actief", naam "Schoenen maat 48".
Ingangdatum 1-1-2006, status actief, naam "Sokken maat 48"
Ingangsdatum 31-12-2006, status "inactief" naam "Sokken maat 48"

Een query op de betreffende tabel zal voor product A op naam zal voor de diverse data de volgende resultaten teruggeven:
2-4-2005: nothing found (want rij is inactief)
15-12-2005: Schoenen maat 48 (want rij is actief en is bekend en eff. datum < selectiedatum)
30-12-2005: Sokken maat 48 (want rij is actief en is bekend en eff. datum < selectiedatum)
31-12-2006 nothing found (want rij is weer inactief)

In SQL code bereik je zoiets door de tabel met een inner join 2x met zichzelf te laten joinen in twee geneste subselects. Ik heb zo geen code bij de hand die dit doet, maar ik denk dat je mijn punt zo wel begrijpt

[Verwijderd]

@ripexx: Einddatum klinkt goed. Ik behoud zo ook de info die ik nodig heb voor latere analyse. Waarom hebben mijn ellenlange vragen altijd antwoorden van 1 woord?

'Probleem'' dat overblijft is dat ik dan data in mijn webapplicatie db heb die nooit meer gebruikt wordt door de webapplicatie. Maar weer wel door een financiële module die ik nog moet maken. Aangezien het qua performance niets uit zal maken ga ik ervoor.

[dusty]

Tip: Zorg dat je webapplicatie en de financiele module een andere sql-account gebruiken, en geef die twee gebruikers dus verschillende rechten, immers zal je met een van die accounts alleen informatie kunnen willen wegschrijven, zonder dat die informatie weer opgehaald kan worden met dezelfde gebruiker.

[djluc]

NetForce1 schreef op maandag 09 januari 2006 @ 19:26:
[...]
Dan zou je dus een extra tabel bij moeten houden met alle verwijderde records.

Nee, lees het nog eens: Ik bedoel dus gewoon een delete veldje wat je afvinkt om een record deleten. Je doet dit alleen niet door de rij te verwijderen maar door een nieuwe rij in te voegen. Om het te verduidelijken:

tabel gebruikers:
id-name-deleted-oid-oidsort

De originele rij:
1-jantje-0-0-0

Als je de naam wijzigt voeg je een nieuwe rij toe:
2-Jantje Jansen-0-1-1

Vervolgens voegen we een nieuwe gebruiker in:
3-Keesje-0-0-0

O nee, Kees is crimineel en moet verwijderd worden:
3-Keesje-1-3-1

Mocht blijken dat Kees toch wel in het systeem mag komen dan wijzigen we het weer terug:
3-Keesje-0-3-2

Wat je dus doet: Steeds een rij toevoegen aan het systeem. OID staat voor Original ID wat verwijst naar het originele record. OIDsort is een toenemende teller, het record met de hoogste order is de nieuwste van het record. Dit is van belang omdat je niet altijd mag vertrouwen op je autoincrement ID.

[whoami]

ripexx schreef op maandag 09 januari 2006 @ 19:13:
Eigenlijk is het veel eenvoudiger, je verwijder geen product, ook niet logisch maar je geeft het gewoon een einddatum. Product verschijnt niet meer en jij hebt je data nog. Oplossingen met logisch verwijderen enz. zijn eigenlijk houtje touwtje oplossingen.

Hetgeen wat jij doet, is eigenlijk ook logisch verwijderen.

[Verwijderd]

Ik heb het inmiddels met die einddatum geimplementeerd en dat werkt prima. Maar wat whoami zegt klopt wel. Het verschilt niet zo heel veel van een deleted bit veld. Ik check nu ook alleen of er een einddatum geset is of niet. Het belangrijkste verschil is dat die datum handig is voor analysedoeleinden, terwijl een bit veld geen verdere betekenis heeft.

Nu ik klaar ben met deze oplossing begin ik toch weer meer te neigen naar een andere oplossing Producten moeten eigenlijk 3 statussen kunnen hebben: actief, inactief en verwijderd. Ik zou een product_status tabel kunnen maken met de statusgeschiedenis erin. Maar goed, de oplossing die ik nu heb werkt goed, dus ik ga eerst alle basic functionaliteit bouwen voordat ik aan nieuwe trucken begin.

Thanks

[ Voor 4% gewijzigd door Verwijderd op 10-01-2006 15:18 ]

[Verwijderd]

Verwijderd schreef op dinsdag 10 januari 2006 @ 15:16:
Ik heb het inmiddels met die einddatum geimplementeerd en dat werkt prima. Maar wat whoami zegt klopt wel. Het verschilt niet zo heel veel van een deleted bit veld. Ik check nu ook alleen of er een einddatum geset is of niet. Het belangrijkste verschil is dat die datum handig is voor analysedoeleinden, terwijl een bit veld geen verdere betekenis heeft.

Het grote voordeel is dat je met begin en einddata ook bv seizoensgebonden artikelen kan aanmaken. Dus als je alleen kerstballen levert van oktober tot 1 januari, kun je zorgen dat de kerstballen eenvoudig (in)actief gemaakt worden. Is vaak toch handiger dan elke keer een nieuw artikel aanmaken.

[Verwijderd]

hehe, dat is waar. Ik heb alleen geen seizoensgebonden artikelen in mijn appje. Komt door de sector waarvoor de app voor bedoeld is.

[ Voor 9% gewijzigd door Verwijderd op 10-01-2006 21:06 ]