DBDesign: Meerdere vestigingen met meerdere voorraden

[Verwijderd]

Ik ben een retail pakket aan het ontwerpen, en loop tegen het volgende probleem aan.

- Meerdere vestigingen (Amsterdam, Rotterdam, Den Haag, etc...)
- Per vestiging meerdere voorraden (Main, Showroom, Returned, etc...)
- Per vestiging per voorraad transacties (Amsterdam, Main, +1, Invoice 1234)
- Overal dezelfde producten
- Prijzen per vestiging prijs instelbaar (inkoop, verkoop)

Wat ik nu heb (en slecht is volgens mij)

Product(name, buyprice, price)
Location (name)
Stock (location_id, product_id, main, transit, returned, showroom)

Als je drie locaties hebt, heeft je product drie rows in Stock. Dat moet je blijven controleren. En ik kan niet zomaar per vestiging magazijnen toevoegen en verwijderen.

Wie wil me hinten?

[NMe]

Voeg dan een tabel toe voor magazijnen. Je product- en location-tabellen kunnen hetzelfde blijven, maar je stock-tabel verandert dan in zoiets:
Stock (location_id, storehouse_id, product_id)
Alledrie de velden vormen samen de primary key, aangezien geen van de enkele velden op zichzelf uniek is in deze tabel.

De storehouse-tabel zou dan zoiets kunnen worden:
Storehouse (id, type)
Waarbij type een omschrijving is, dus in jouw geval "main", "transit", enz.

Zoek ook eens wat op over databasenormalisatie, want dit is gewoon een normaliseringsstap.

[DDemolition]

Bedenk ook dat eventueel je product meerdere leveranciers kan hebben maar wel hetzelfde is. Je krijgt dan een beetje een stamartikel - artikel idee, zodat je de onderliggende voorraad aantaal geeft en deze op kan tellen.
Ik denk niet dat je met 3 tabelletjes klaar bent

[Verwijderd]

Tja en eigenlijk moet ik ook waardes van de voorraad er in integreren. Grmf dit wordt lastiger dan ik dacht.

[Verwijderd]

Gewoon een gedachte. Zou het niet handiger zijn om elk product dat door je bedrijf heengaat een tabelrij te geven met een referentie aan de inkoopprijs, en de lokatie op dat moment? En dan misschien een quantity veld toevoegen zodat je het ook per partijen kan doen. Je krijgt dan wel een enorme tabel met alle producten die ooit door je bedrijf zijn heengegaan. En om de totale voorraad op moment x te berekenen moet je alle gelijke producten bij elkaar optellen.

Misschien moet je ze kopiëren naar een andere tabel zodra ze zijn afgerekend.

Is dat slim of belachelijk?

[php]
Product
ID
Name
location_id
buyprice
sellprice
stock_id

Location
ID
Name

Stock
ID
Name
location_id

[joepP]

Als je -en- een historie van de artikelen in de voorraad wilt bijhouden, -en- de huidige hoeveelheid snel wilt kunnen opvragen, dan ontkom je niet aan replicatie binnen de database.

Afhankelijk van je voorkeur kan je dit mbv van triggers implementeren, of zorgen dat je al je update/delete queries op de voorraad tabel altijd samen uitvoert met de update van de totalen. In het laatste geval wel de boel binnen een transaction stoppen, je moet 100% zeker zijn dat de totalen altijd kloppen.