[SQL, ASP.NET] Gegevens gekoppeld aan evenementen

[Verwijderd]

Dag allemaal,

We zitten met een vraag waar we zelf niet uitkomen. De situatie is al volgt:

We zijn bezig met een applicatie voor een organisatie die jaarlijks een evenement organiseert. Daarop treden artiesten op. Ze hebben ons gevraagd om een applicatie te schrijven die per evenement gegevens kan bijhouden over die artiesten en meer.... Veel van die gegevens zijn gebonden aan een evenement, maar ook zijn veel gegevens gebonden aan de organisatie.

Een voorbeeld:
De organisatie nodigt per jaar verschillende artiesten uit, maar het kan zijn dat zijn al aanwezig waren op vorige editie's. De artiesten worden dus globaal opgeslagen, maar gekoppeld aan een evenement. Het zelfde gebeurd met producten. Zij hebben verschillende producten die ze opnieuw aankopen per evenement, deze worden globaal opgeslagen. Deze worden dan aan een evenement gekoppeld dmv een andere tabel.

Het probleem is als volgt:
Van een product wordt bijgehouden wat de eenheidsmaat is om te bestellen, bv. een fles cola. Deze worden gekocht op evenement 1. Daarna wordt het evenement afgesloten. ( evenementen zijn jaarlijks, dus kunnen elkaar niet overlappen ). Er kunnen hier dus geen evenement-specifieken gegevens meer worden aagepast.

Tijdens het aanvullen van de info over evenement 2 blijkt dat er geen flessen meer gekocht worden, maar blikken. Dan wordt het product ( die globaal opgeslagen is ) verandert van fles naar een blik. Dit is geen probleem voor evenement 2. Maar als we nu gegevens van evenement 1 opvragen ( om te kijken hoe het dan was ) zullen we zien dat er nu ( volgens de applicatie ) blikken cola verkocht werden op evenement 1. Hoewel dit niet klopt.

Het probleem gaat natuurlijk veel verder dan dit. Dit is slecht een eenvoudig voorbeeld, maar het komt neer op het feit, dat de globale info moet blijven bestaan ( zodat deze niet telkens opnieuw moet worden ingegeven ) maar dat we we een geschiedenis kunnen blijven bijhouden per evenement van deze globale data.

Wij zijn al enkele dagen op zoek, hebben al uren mogelijkheden zitten uitdenken, maar we komen er niet uit. Hoe kunnen we dit oplossen. We denken in de eerst plaats aan een aangepaste database, zodat we deze gegevens kunnen opslaan. Of is het eenvoudiger om dit in de programmacode te doen? Kan iemand ons een duwtje in de juiste richting geven?

Info over de ontwikkelingsomgeving:
ASP.NET ( .Net framework 3.5 SP1 )
MSSQL Server 2008 SP1

[Laurens-R]

Heel eenvoudig volgens mij... een fles en een blik cola zijn hele verschillende producten en zullen dus apart in de database vermeld moeten worden.

Ik neem aan dat er zoiets is als een products table in je db?

Je zal toch echt twee product records moeten aanmaken in dit geval... Kan me ook eigenlijk niet voorstellen dat een product veranderd van fles naar blik zonder dat dit invloed heeft op alle overige kenmerken van het product... bijvoorbeeld prijs, gewicht, inhoud, etc.

Administratief gezien zou daar dus geen hout van kloppen. Dan zou een bestelling van een jaar geleden ineens uit bananen ipv cola kunnen bestaan!

Wellicht dat jullie nog een keer naar jullie DB ontwerp of jullie applicatie architectuur moeten kijken? Er lijkt een fundamentele denkfout in te schuilen.

[ Voor 76% gewijzigd door Laurens-R op 07-04-2010 12:44 ]

[418O2]

Product met een productspecificatie maken oid? Dus Cola als product en een specificatie heeft dan de eigenschappen "type" en "hoeveelheid". Dus blik/fles bijv, kan je ook weer algemeniseren naar bijv blik 33cl, want dat kan bij meerdere producten horen (cola, cassis, 7-up)

En dan een aantal specs aan het evenement binden. Je kan dan ook ongeacht de exacte specificatie de totalen uitrekenen. Dus als je jaar 1 alles in flessen hebt en later alles in blikjes, dan kan je alsnog kijken wat je nodig gaat hebben het jaar daarop (ik noem maar wat).

Je kan allerlei kanten op met dit Zo ingewikkeld is het niet.

[Verwijderd]

Bedankt voor de antwoorden, maar ik heb misschien ene slecht voorbeeld gekozen met die producten. Het probleem doet zich ook voor bij de groepen. Per evenement komen er meerdere muziekgroepen spelen. Deze worden globaal bijgehouden. Maar er kan iets veranderen aan deze groep over de evenementen heen, maar we willen we weten hoe het was op een bepaalde editie. Er zou dus een soort van geschiedenis moeten zijn op de globale data.

[creator1988]

Simpel: doe NOOIT updates, maar doe altijd inserts, met een soort 'indActief' veld in je database waarmee je het meest recente record aanduid. Als je dan informatie over een historisch event opzoekt, kijk je naar het record dat toentertijd actief was voor de artiest.

(Ergo: een view die altijd alleen records met indActief = 1 teruggeeft, en een UPDATE trigger die er INSERTS van maakt, is de minste impact. Alleen voor oude events hoef je dan je code aan te passen).

Voorbeeld van je artiesten tabel;

| autonummer | artiestId | naam | indActief |
| 200 | 5 | Band | 0 |
| 201 | 5 | Band nieuwe naam | 1 |

En in je evenement tabel:

| eventId | artiestAutonummer | artiestId |
| 12 | 200 | 5 |

Nu kan je bij event 12 altijd de versie pakken die je op het moment van het event in je database had staan.

[ Voor 26% gewijzigd door creator1988 op 07-04-2010 13:11 ]

[HMS]

Dan zal je toch de gegevens per evenement moeten op slaan.

Voor je dranken voorbeeld:

Evenement - product - eenheid

Festival.X - Cola - blik 33cl
Festival.Y - Cola - fles 0.5l

Bij aanpassingen aan een muziekgroep (band?) neem ik aan artiesten die er bij komen / weg gaan? Dan zou je eventueel een mutatie tabel ofzo kunnen hebben waarin je de wijzigingen aan de band bijhoudt, oid. Of dubbele invoer in de vorm van:

Evenement - Band - Artiesten

Festival.X - Band Y - Artist A, Artist B, Artist C

[Reptile209]

Verwijderd schreef op woensdag 07 april 2010 @ 12:56:
Bedankt voor de antwoorden, maar ik heb misschien ene slecht voorbeeld gekozen met die producten. Het probleem doet zich ook voor bij de groepen. Per evenement komen er meerdere muziekgroepen spelen. Deze worden globaal bijgehouden. Maar er kan iets veranderen aan deze groep over de evenementen heen, maar we willen we weten hoe het was op een bepaalde editie. Er zou dus een soort van geschiedenis moeten zijn op de globale data.

Als je een band dan definieert als een 'container' die meerdere 'producten' kan bevatten? Dan is 'Vader Abraham' je container. Die heeft dan producten 'Optreden Songfestival 1931', 'Optreden Songfestival 1954', enz. En die producten koppel je aan een globaal evenement en kan je dan weer voorzien van andere informatie (aantalSmurfen, prijsOptreden, ...). Zo kan je dus per evenement specifieke info bijhouden, en toch een soort globale overzichten maken (wanneer trad V.A. op?).

[creator1988]

Reptile209 schreef op woensdag 07 april 2010 @ 13:17:
[...]

Als je een band dan definieert als een 'container' die meerdere 'producten' kan bevatten? Dan is 'Vader Abraham' je container. Die heeft dan producten 'Optreden Songfestival 1931', 'Optreden Songfestival 1954', enz. En die producten koppel je aan een globaal evenement en kan je dan weer voorzien van andere informatie (aantalSmurfen, prijsOptreden, ...). Zo kan je dus per evenement specifieke info bijhouden, en toch een soort globale overzichten maken (wanneer trad V.A. op?).

Tot Vader Abraham zijn naam veranderd. Je moet niet de helft van je data zo uit elkaar trekken, maar gewoon álles versionen.

[Verwijderd]

Bedankt allemaal voor jullie snelle reactie.
Ik denk dat we eens zullen kijken naar de oplossing van creator1988. Ik denk dat die het meest voor de hand ligt. Ik laat nog weten hoe we het geïmplementeerd hebben.

edit:
Nog een vraagje. Als je nu in deze tabel ( zoals het voorbeeld van creator1988 ):

[b][message=33779556,noline]
Voorbeeld van je artiesten tabel;

| autonummer | artiestId | naam | indActief |
| 200 | 5 | Band | 0 |
| 201 | 5 | Band nieuwe naam | 1 |

een relatie wil leggen tussen een artiest en een andere tabel. Hoe kan dit dan worden aangepakt. ArtiestID is namelijk niet uniek en geen primary key. En als we een samengestelde primary key maken, dan wordt er verwijst naar een bepaald record en niet meer naar een groep. Of zie ik dit verkeerd?

[ Voor 58% gewijzigd door Verwijderd op 07-04-2010 14:53 . Reden: nieuwe vraag ]