[MySQL] Voorraadbeheer

[turkosh]

Hallo allemaal,

Is het nou handig om MySQL te gebruiken voor simulatie van een POS met voorraadbeheer?
Want er zijn waardes als bestelnivo's, omzetten, inkoop/verkoop prijzen, marge's, transacties, e.d., en niet te vergeten de referentiele integriteit die een belangrijke rol spelen.
En de nodige formulieren om het geheel overzichtelijker te houden. Nu vraag ik mij af of MySQL wel zo geschikt is om dit karwei te klaren.

[Boogie]

Als jij zorgt voor een goed data-model, dan kan MySql je data wel goed verwerken.

[Verwijderd]

referentiele integriteit die een belangrijke rol spelen

MySQL dwingt nu nog niets af.
Je kan wel relaties aangeven, maar je uitvoer zal je "handmatig" correct moeten coden.
Verder zijn er al vele voor jou gegaan die hun voorraad/winkel/bestelsystemen aan mysql toevertrouwd hebben.

[OkkE]

MySQL is in wezen niks anders als elke andere databse. Tuurlijk heeft elke database zo z'n voor- en nadelen, maar database blijft database. Ik zie dus niet waarom MySQL hier niet geschikt voor zijn? Kan in mijn ogen prima.
Zoals Boogie al gezegd, ik denk dat je data-model 10x meer invloed heeft op of het wel of niet werkt als de soort database. Zolang je model goed is werkt denk ik elke database.

Goed. Oke, MySQL heeft toch iets meer min-puntjes ..

[ Voor 9% gewijzigd door OkkE op 08-12-2003 15:37 ]

[whoami]

OkkE schreef op 08 december 2003 @ 15:14:
MySQL is in wezen niks anders als elke andere databse. Tuurlijk heeft elke database zo z'n voor- en nadelen, maar database blijft database. Ik zie dus niet waarom MySQL hier niet geschikt voor zijn? Kan in mijn ogen prima.
Zoals Boogie al gezegd, ik denk dat je data-model 10x meer invloed heeft op of het wel of niet werkt als de soort database. Zolang je model goed is werkt denk ik elke database.

Omdat MySQL geen referentiele integriteit afdwingt, omdat MySQL geen triggers/Stored Procedures/UDF/transactions kent...

[P_de_B]

OkkE schreef op 08 december 2003 @ 15:14:
MySQL is in wezen niks anders als elke andere databse. Tuurlijk heeft elke database zo z'n voor- en nadelen, maar database blijft database.

zonder MySQL hier te kort willen doen, en zonder te willen flamen. MySQL dwingt geen referentiele integriteit af en ondersteunt geen transacties. Ligt eraan hoeveer waarde je aan correcte data hecht, maar dit zijn wel twee belangrijke punten.

[MikeN]

Ik denk dat vooral de transactions in zo'n systeem toch wel belangrijk zijn. Jij hebt liever niet dat je database straks een zooitje is omdat sommige queries toch niet uitgevoerd konden worden, maar ondertussen wel je voorraad al bijgewerkt is.

Daar is met veel moeite misschien wel omheen te coden, maar het lijkt me dat een oplossing als postgresql handiger zou zijn.

[Qwerty-273]

Of je kan ook kijken naar Firebird als DB..
http://firebird.sourceforge.net/

[MaxxRide]

Volgens mij kun je in MySQL ook niet echt constraints opleggen. Op zich is het een prima database alleen je zult veel af moeten dwingen. Je kunt ook kijken naar b.v. interbase dat is ook wel een fijne database.

[turkosh]

Ok ik snap het.
Heb een model opgezet die veel met foreign keys werkt, om zo kleine tabellen te houden.
Dus het is van blang dat ik via die keys wel van een tabel kan linken naar een hele andere tabel via de tussen liggende tabellen.

Bijvoorbeeld achterhalen van btwomschrijving van een artikel in voorraadbeheer:

Moet dan deze weg kunnen afleggen:
vooraadbeheer.PLU naar artikel.PLU -> artikel.rapportcode naar hoofdgroepen.rapportcode -> hoffdgroepen.btw_code naar btw.btw_code -> btw.btwomschrijving.

Of het berekenen van de marge d.m.v. de (artikel.prijs-voorraadbeheer.inkoopprijs) en dat in procenten. (Denk dat dit eerder handig is bij rapporten)

[Rataplan]

P_de_B schreef op 08 december 2003 @ 15:17:
ondersteunt geen transacties

http://www.mysql.com/doc/en/Transactional_Commands.html

en trouwens

http://www.mysql.com/doc/en/Subqueries.html
http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html

en triggers en stored procedures zitten in de 5.0 devtree. Ik heb trouwens wel eens eerder beweerd dat deze technieken zich allemaal nog maar even moeten bewijzen, maar met 4.0 is MySQL aan een hoop van de hierboven genoemde bezwaren tegemoetgekomen
[norml]
[/]
_{Over dat zich bewijzen gesproken:}

quote: http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html

_{Using your keys to join tables will work just fine}

_{Dat klinkt niet echt alsof ze graag willen dat je het gebruikt}

edit:

@turkosh: lees over bedrijfsmatig gebruik van mysql deze draad ook even. Het hebben van relations kan prima in MySQL, het houden ervan is vooralsnog betrouwbaarder (en net zo gratis) met andere db's uit te voeren. Wat jij wil is met vrijwel iedere database uitstekend mogelijk, en zeker met MySQL. Ik zou bijna zeggen: doe het vooral en leer van wat er mis kan gaan

[ Voor 25% gewijzigd door Rataplan op 08-12-2003 15:40 ]

[turkosh]

Opzich prefereer ik MySQL omdat die leuk integreert met OOo. En met mysqlcc heb ik nog een leuke grafische schil erop.
Maar helaas ben ik geen MySQL guru om alle nodige eisen die niet in MySQL voorkomen te herdefinieren / eromheen te coderen.

[whoami]

turkosh schreef op 08 december 2003 @ 15:31:
Ok ik snap het.
Heb een model opgezet die veel met foreign keys werkt, om zo kleine tabellen te houden.

Een andere tabel creeëren om je tabellen klein te houden mag niet de reden zijn tot het maken van een nieuwe tabel.
Misschien moet je eerst eens iets lezen over normaliseren. (In de P&W FAQ vind je onder de SQL sectie een linkje naar een normaliseren tutorial.
Vergeet ook niet dat joins een vertragend effect hebben op SELECT queries.

[ACM]

Rataplan schreef op 08 december 2003 @ 15:36:
en triggers en stored procedures zitten in de 5.0 devtree.

't kostte mysql geloof ik een jaar om van alpha naar beta te komen met 4.0, dus ik zou maar niet gaan wachten met beginnen tot mysql 5.0 eindelijk stable is aangezien die nog complexere wijzigingen behelst dan 4.0 en zelfs 4.1 nog niet af is (ik snap ook niet zo goed waarom ze die niet eerst af maken)

Ik heb trouwens wel eens eerder beweerd dat deze technieken zich allemaal nog maar even moeten bewijzen, maar met 4.0 is MySQL aan een hoop van de hierboven genoemde bezwaren tegemoetgekomen

Volgens mij is de forcering van de relationele integriteit nauwelijks verbeterd...
Volgens mij kan je nog steeds items null maken als je not null definieert, zaken met overflows worden nog steeds niet correct afgehandeld, etc etc.
Zie de link in mijn sig en ook de op die pagina staande link, erg interessant als je gaat proberen te kijken hoe goed mysql is met relationele integriteit en de rest van de ACID eisen

ook even. Het hebben van relations kan prima in MySQL, het houden ervan is vooralsnog betrouwbaarder (en net zo gratis) met andere db's uit te voeren. Wat jij wil is met vrijwel iedere database uitstekend mogelijk, en zeker met MySQL. Ik zou bijna zeggen: doe het vooral en leer van wat er mis kan gaan

PostgreSQL en Firebird zijn iig twee "betere" (tenzij beter = sneller, dan is dat niet altijd waar) producten dan mysql, imho

turkosh schreef op 08 december 2003 @ 15:42:
Opzich prefereer ik MySQL omdat die leuk integreert met OOo. En met mysqlcc heb ik nog een leuke grafische schil erop.

Postgresql kent tegenwoordig ook OOo integratie toch?

[ Voor 8% gewijzigd door ACM op 08-12-2003 15:48 ]

[-=bas=-]

MySQL dwingt geen referentiele integriteit af en ondersteunt geen transacties. Ligt eraan hoeveer waarde je aan correcte data hecht, maar dit zijn wel twee belangrijke punten.

Dat betekent enkel dat je een goed model moet gebruiken en enkele zaken zelf zal moeten regelen en niet kan overlaten aan de database(engine) (wat soms wel heel veel werk scheelt zoals bv de transacties)

[whoami]

_bas_ schreef op 08 december 2003 @ 15:50:
[...]

Dat betekent enkel dat je een goed model moet gebruiken en enkele zaken zelf zal moeten regelen en niet kan overlaten aan de database(engine) (wat soms wel heel veel werk scheelt zoals bv de transacties)

Nee hoor.
Zelfs met een goed datamodel kan je orphin records hebben als jouw DBMS geen referentiele integriteit afdwingt.
Stel, je hebt een tabel 'Klant' en een tabel 'Orders' en er ligt geen relatie die referentiële integriteit afdwingt tussen klant en orders; dan kan je gewoon een klant verwijderen, terwijl hij bv. orders heeft, en die orders blijven dan gewoon in de DB staan. Dan heb je nog order-informatie in je DB zonder dat je weet van welke klant ze zijn.
Dergelijke dingen zelf regelen zijn gewoon tijdrovend, en error-prone.

[Rataplan]

whoami schreef op 08 december 2003 @ 15:54:
Stel, je hebt een tabel 'Klant' en een tabel 'Orders' en er ligt geen relatie die referentiële integriteit afdwingt tussen klant en orders; dan kan je gewoon een klant verwijderen, terwijl hij bv. orders heeft, en die orders blijven dan gewoon in de DB staan. Dan heb je nog order-informatie in je DB zonder dat je weet van welke klant ze zijn.
Dergelijke dingen zelf regelen zijn gewoon tijdrovend, en error-prone.

Dat is op zich waar, maar ik roep ook al jaren dat een goed programma zulke dingen niet mag toestaan. Als je weet waar je mee bezig bent, hoort er niets aan de hand te zijn. Een uitvloeisel, ongetwijfeld, van het feit dat het niet de programmeurs zijn die bepalen hoeveel ontwikkeltijd er beschikbaar is...

Tegelijkertijd begint er dan altijd wel weer iemand over "stroomuitval" en dat is wel een valide argument. Een technisch mankement zal optreden, en dan mag de db niet corrupt achterblijven. Maar dat kan je natuurlijk weer met transacties beveiligen... Weer de vraag: hoeveel tijd wil, mag, en kan je erin steken?

Eigenlijk moet je eerst het programma schrijven, en vervolgens maar zien welke database de juiste instructieset aan boord heeft. Maar zulke programmeurs zijn er niet veel

edit:
Het is trouwens 'orphan'

[ Voor 4% gewijzigd door Rataplan op 08-12-2003 16:20 ]

[turkosh]

1 voorbeeld met referntiele integriteit.

tabel hoofdgroepen:

btw_code references btw(btw_code)
ON UPDATE RESTRICT
ON DELETE RESTRICT;

En je kan makkelijk de btw_code anders invullen in hoofgroepen. Geen error melding of waarschuwing.

[Rataplan]

turkosh schreef op 08 december 2003 @ 16:20:
1 voorbeeld met referntiele integriteit.

tabel hoofdgroepen:

btw_code references btw(btw_code)
ON UPDATE RESTRICT
ON DELETE RESTRICT;

En je kan makkelijk de btw_code anders invullen in hoofgroepen. Geen error melding of waarschuwing.

Checks hou je toch. Mag je een BTW-percentage bijwerken? Mag je een BTW-percentage verwijderen? Moet je bij het gebruik van BTW in financiele administraties daarom niet altijd een kopie maken (very tricky question, houd rekening met de belastingdienst ) ? Hou je (dus) een historie bij? Hoe corrigeer je het verzenden van duizend van de verkeerde BTW voorziene fakturen? Mogen er dubbele percentages in de database voorkomen? Welke gereferencte tabellen mogen er nog naar een 'oude' waarde wijzen? Hoe lang?

En laat me je een ding vertellen: je gaat daarenboven aanzienlijk meer problemen hebben met het verwerken van intracommunautaire leveringen, verlegde btw, btw-vrijstelling, en 0%-btw. Allemaal hetzelfde bedrag, maar allemaal andere consequenties

[VisionMaster]

Ik werk erg veel met de transactie mechanismen die MySQL my bieden en ik ben er zeer tevreen over. Ik kan voldoende transacties per seconden behappen via een ODBC laagje en dat is momenteel goed genoeg. Rollbacks en Commits lopen door elkaar, dus absoluut geen ideale omgeving.

[turkosh]

btw_code is de key (of de id) om de btw te koppelen aan hoofdgroepen.
hoofgroepen zijn o.a. Rookwaren, Zoetware, Autogebonden, Levensmiddelen e.d.
En elk groep heeft zo z'n eigen BTW tarief. (Hoog 19%, Laag 6%, 0% )

tabel btw bevat simpelweg 3 dingen.
btw_code (primary key)
btw
omschrijving

Ingevuld ziet het er zo uit:
0 0 0% btw
1 6 LG btw
2 19 HG btw

Als ik nu in hoofdgroepen btw_code 5 zou invullen dan zou die eigenlijk een melding moeten geven omdat die niet bestaat. Dat doet die dus niet. Laat staan dat je nog rekening mee moet houden met andere zooi.

[Qwerty-273]

Rataplan schreef op 08 december 2003 @ 16:31:very tricky question, houd rekening met de belastingdienst

En ook vooral de overheid die met terug werkende krachten allerlei percentages en bedragen aanpast voor selecte groepen. Maar dat is weer een andere sector/gebied dan de probleem stelling in de TS

[turkosh]

Denk dat ik straks toch nog effe Postgre aan de tand ga voelen. Kent ieman een leuke grafisch schil á la mysqlcc?

[Rataplan]

turkosh schreef op 08 december 2003 @ 16:38:
Als ik nu in hoofdgroepen btw_code 5 zou invullen dan zou die eigenlijk een melding moeten geven omdat die niet bestaat. Dat doet die dus niet. Laat staan dat je nog rekening mee moet houden met andere zooi.

En wat ik je probeer duidelijk te maken is dat je die 5 uitsluitend onder bepaalde omstandigheden in kan voeren.

Bijvoorbeeld als je een faktuur invoert. Dan heb je meteen het percentage nodig, want dat moet gekopieerd worden - en die query levert direct een fout op. Ander voorbeeld: in het BTW-onderhoudsscherm. Daar moet het wel kunnen, want je wil bijvoorbeeld een nieuw percentage aan kunnen maken. Mocht je jezelf beperken tot situaties waarbij zo'n probleem meteen duidelijk is, dan hoef je d'r ook geen bescherming tegen te bouwen.

Bovendien heeft de gebruiker daar gewoon tussen bestaande codes te kiezen, ongeldige codes mogen niet aangeboden worden En voor er mensen over deletes beginnen: die horen in een administratief systeem niet voor te komen

[turkosh]

By the way, had ik al verteld dat het een simulatie is (voor een project). En dat de belastingdienst hopelijk zich niet gaat uitleven op fictieve gegevens. ;-)

[Rataplan]

RIKZ schreef op 08 december 2003 @ 16:42:
[...]


En ook vooral de overheid die met terug werkende krachten allerlei percentages en bedragen aanpast voor selecte groepen. Maar dat is weer een andere sector/gebied dan de probleem stelling in de TS

Niet echt Je zal altijd je volledige transactiehistorie boven water moeten kunnen halen, en dit soort financiele correcties leiden tot het toevoegen van, niet tot het wijzigen van database-entries. That was the trick

turkosh schreef op 08 december 2003 @ 16:50:
By the way, had ik al verteld dat het een simulatie is (voor een project). En dat de belastingdienst hopelijk zich niet gaat uitleven op fictieve gegevens. ;-)

Simulaties dienen de werkelijkheid zo goed mogelijk te benaderen en je had nog niet verteld hoe goed je het gaat uitvoeren

Serieus, het hele verhaal is arbitrair (goeie keus, PostGreSQL, al heb ik begrepen dat bij bepaalde blobs de dbdump op z'n bek gaat - ook weer zo'n probleem waar je maar beter op voorbereid kan zijn) maar de crux is niet onbelangrijk: kies een database voor de oplossing die je gaat programmeren, niet voor wat de theorie zegt dat je zou moeten kunnen programmeren. Referentiele integriteit is leuk, maar als je programma meteen crashed als een check de mist in gaat, is dat natuurlijk ook geen porem. Per transactie zal je toch moeten bepalen wat er fout kan gaan, en hoe je dat probleem op gaat lossen zonder de gebruiker de stuipen op het lijf te jagen. Bij het verlaten van je facturenscherm moet er gewoon een factuur ingevoerd zijn, en verder niks.

En vergeet niet: referentiele integriteit aan de db-kant moet ook goed geprogrammeerd worden; en dat kost ook tijd.

[ACM]

turkosh schreef op 08 december 2003 @ 16:48:
Denk dat ik straks toch nog effe Postgre aan de tand ga voelen. Kent ieman een leuke grafisch schil á la mysqlcc?

pgadmin3 is wellicht wel aardig ?

Btw, over mysql's foreign key geknoei:
- Je kan FK's definieren naar niet-innodb tabellen (meen ik), wat niet eens een waarschuwing oplevert.
- Je kan FK's definieren op myisam tabellen, terwijl dat verder niet mogelijk is in myisam... Ook geen waarschuwing.
- Dit kan geloof ik niet: CREATE TABLE selfreference (id integer primary key, parentid integer references selfreference(id) ON UPDATE CASCADE) -> de cascade werkt dan niet
- Je moet verplicht een index aanleggen op het veld waar je de FK in definieert

en er is nog wel meer mee mis...
Toch jammer dat ze het dan presenteren als een volledige implementatie

[ACM]

Rataplan schreef op 08 december 2003 @ 16:57:
Referentiele integriteit is leuk, maar als je programma meteen crashed als een check de mist in gaat, is dat natuurlijk ook geen porem. Per transactie zal je toch moeten bepalen wat er fout kan gaan, en hoe je dat probleem op gaat lossen zonder de gebruiker de stuipen op het lijf te jagen. Bij het verlaten van je facturenscherm moet er gewoon een factuur ingevoerd zijn, en verder niks.

Huh?
Dus als je referentiele integriteit je een foutmelding teruggeeft en je daar niks mee wilt doen in je applicatie, dan kan je maar beter de referentiele integriteit overboord zetten?
Althans, dat lees ik uit jouw verhaal

Volgens mij is dat net verkeerdom