[SQL][C#]Best practice Table in Table of List<> in Table?

[Stekeltje]

Ik ben bezig met een hobby project waarin ik tegen een 'probleem' aan loop die ik niet gemakkelijk gegoogled krijg of waarvan ik niet weet hoe ik het nu moet opzetten.

Wat ik wil een tabel met daarin de volgende onderdelen

• POnummer -> Specifiek referentie nummer, wordt per dag bekeken hoe deze wordt gemaakt.
• orderDate -> Datum van de 'bestelling'
• orderSupplier -> Leverancier
• orderItems -> Specifieke producten die worden besteld bij de leverancier met de volgende losse parameters.
  1. Product Naam
  2. Product Code
  3. Product SKU (mijn referentie)
  4. Product Bestel hoeveelheid

De eerste 3 zijn een makkie, zoiets doe ik al regelmatig in het programma en worden aangepast of aangemaakt wanneer nodig. Echter loop ik vast op orderItems, bij veel leveranciers horen veel producten met allemaal een aantal die gedaan moet worden. Ik wil niet dat de "Orders" tabel bestaat uit 100-en keren het zelfde order nummer met elk weer een apart product per leverancier.

Nu dacht ik zelf, ik moet een List<> gebruiken deze in de database opslaan en weer her gebruiken. De list wordt door middel van een struct opgebouwd. Alleen nu krijg ik de informatie er niet meer uit en blijkt dat een tabel niet geschikt is om zoiets op te slaan. Volgens mij moet ik een tabel met een soort van relationele tabel hebben?

Weet iemand hoe ik dit het best aan kan pakken. Zoals gezegd ik loop vast en mijn ervaring is helaas niet toereikend om tot een deftige oplossing te komen.

[Merethil]

Over het algemeen is het wel logisch om een tabel te hebben die bestaat uit het volgende:

- ID (Als je unique identifier)
- OrderID (Foreign Key naar je POnummer in een andere tabel)
- ProductName
- ProductCode
- ProductSKU
- ProductQuantity

Het is namelijk helemaal niet erg als je een gigantische tabel krijgt hiermee, het is allemaal vrij simpele data die je snel kan terugvinden op basis van je orderID.
Als je verwacht 100-en producten per order te doen dan is dit waarschijnlijk de meest performante oplossing, maar misschien niet de meest "Visueel aantrekkelijke".

Gelukkig is dat laatste geen probleem aangezien je normaalgesproken eigenlijk niets van doen hebt met hoe de data in de database er visueel uitziet: Het kunnen bekijken is alleen nuttig als je iets handmatig wilt aanpassen of verwijderen.
Voor de rest van de tijd hoor je gewoon in je presentatielaag dit anders aan te bieden dan het in je DB staat, maar een tabel vol met rijen aan data is juist waar die dingen voor zijn

[Stekeltje]

Merethil schreef op dinsdag 05 augustus 2014 @ 11:14:
Over het algemeen is het wel logisch om een tabel te hebben die bestaat uit het volgende:

- ID (Als je unique identifier)
- OrderID (Foreign Key naar je POnummer in een andere tabel)
- ProductName
- ProductCode
- ProductSKU
- ProductQuantity

Het is namelijk helemaal niet erg als je een gigantische tabel krijgt hiermee, het is allemaal vrij simpele data die je snel kan terugvinden op basis van je orderID.
Als je verwacht 100-en producten per order te doen dan is dit waarschijnlijk de meest performante oplossing, maar misschien niet de meest "Visueel aantrekkelijke".

Gelukkig is dat laatste geen probleem aangezien je normaalgesproken eigenlijk niets van doen hebt met hoe de data in de database er visueel uitziet: Het kunnen bekijken is alleen nuttig als je iets handmatig wilt aanpassen of verwijderen.
Voor de rest van de tijd hoor je gewoon in je presentatielaag dit anders aan te bieden dan het in je DB staat, maar een tabel vol met rijen aan data is juist waar die dingen voor zijn

Oké wat hierboven staat dacht ik al een beetje maar had nog een 'bevestiging' nodig. Nu vroeg ik mij alleen nog af waarom die unique id erbij moest. Ik gebruik hem wel altijd maar heeft dat zin in elke tabel?

[Merethil]

Stekeltje schreef op dinsdag 05 augustus 2014 @ 11:31:
[...]

Oké wat hierboven staat dacht ik al een beetje. Nu vroeg ik mij alleen nog af waarom die unique id erbij moest. Ik gebruik hem wel altijd maar heeft dat zin in elke tabel?

Voor updates/deletes maken die unique ID's (een oplopende int als primary key bv) het gewoon een stuk makkelijker.
Veel ORM's kunnen ook niet goed overweg met tables waar geen ID of iets soortgelijks in zit, aangezien je dan veelal ziet dat ze niet of nauwelijks een andere vorm van uniekheid kunnen vinden waarop je je updates/deletes kan baseren.

[Stekeltje]

Ah, dan hou ik die erin Nu even opzoeken wat het gemakkelijkste wegschrijven van de data is. Daar kom ik wel uit Thanks!

[Verwijderd]

Je unique Id is natuurlijk gewoon je Primary Key.

Wel krijg je zo per orderregel een product in je database. Wat het moeilijk maakt als bv je productnaam of SKU veranderd.

Natuurlijk zou je het ook zo kunnen doen:

Order
PONumber (PK)
orderDate
orderSupplier (FK?)

OrderLine
PONumber (PK, FK)
ProductCode (PK, FK)
Quantity

Product
ProductCode (PK)
Naam
SKU

Zo hoef je de producten zelf niet vaker op te slaan.

[Guldan]

Wat Sanderev66 aangeeft is inderdaad een handige opzet voor de database. De techniek om tot een dergelijk ontwerp te komen heet database normalisatie. Je kan daar een methodiek voor gebruiken zie deze link: Wikipedia: Databasenormalisatie

[Merethil]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 11:53:
Je unique Id is natuurlijk gewoon je Primary Key.

Wel krijg je zo per orderregel een product in je database. Wat het moeilijk maakt als bv je productnaam of SKU veranderd.

Natuurlijk zou je het ook zo kunnen doen:

Order
PONumber (PK)
orderDate
orderSupplier (FK?)

OrderLine
PONumber (PK, FK)
ProductCode (PK, FK)
Quantity

Product
ProductCode (PK)
Naam
SKU

Zo hoef je de producten zelf niet vaker op te slaan.

Dit is inderdaad een beter idee. Ik ging er eigenlijk vanuit dat hij zelf geen invloed had over de producten en dat een aanpassing in naam aan de kant van de tegenpartij gebeurde.
@TS: Als je zelf dit alles beheert (de namen van de producten etc.) dan kan je het best sanderev's manier volgen, die is dan natuurlijk netter.

[Stekeltje]

Wow, bedankt! Iedereen

Ik beheer alles Ik maak dit omdat ik het leuk vind een soort van ERP programma voor onze hobby webshop te maken. Hiermee wil ik gemakkelijk voorraad bijhouden maar ook bestel adviezen kunnen geven.

Ik ga het nu maar opnieuw aanpakken, ik kan namelijk veel meer FK koppelingen maken waardoor de kans op fouten geminimaliseerd wordt. Ik kan het beter nu dan later de DB te optimaliseren...

[ Voor 4% gewijzigd door Stekeltje op 05-08-2014 13:10 ]

[Russel88]

Bedrag zou ik ook in Orderline stoppen. Stel product wijzigt van prijs, dan wil je niet dat de bedragan van oude orders ook van prijs wijzigen.
Je wilt kunnen zien dat Pietje vorige week een boek kocht voor 5,99 ipv 4,99 (huidige prijs).

[Verwijderd]

Jup. Bedrag in zowel OrderLine als Product. Klant betaalt het bedrag in de orderline. Zo kan je ook evt. eenvoudig kortingen meerekenen.

[Stekeltje]

Nja het is maar aan onze kant. De webshop software reageert prijzen en statistieken opzich zelf qua verkoop. Dit programma is gebaseerd op Inkoop.

[mbaltus]

Voor inkoop geldt natuurlijk ook dat je vandaag voor een product een ander bedrag kunt betalen dan morgen. Dus blijft het opnemen van de prijs nog steeds relevant voor je orderregel tabel

[Stekeltje]

Mee eens, alleen ik weet bijna zeker dat we niet actief de inkoop prijs gaan opnemen in de webwinkel en daarom zal dit momenteel nog niet worden geïmplementeerd.

In de toekomst zal dit zeker meegenomen worden.

[raptorix]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 16:44:
Jup. Bedrag in zowel OrderLine als Product. Klant betaalt het bedrag in de orderline. Zo kan je ook evt. eenvoudig kortingen meerekenen.

Of nog mooier dat ook normaliseren en "versioning" op je producten toe te passen
Maar weet niet of TS dat helemaal nodig heeft.