Data verdelen in tabellen

[Toppe]

Medetweakers,

Momenteel ben ik bezig met een nieuw project, informatie daarover kan je hier vinden.

Momenteel worden de artikelen opslagen in een tabel met de naam artikelen. Dit geeft weinig problemen. Alleen zit ik met de opslag van de boekingen.

Ik kan natuurlijk alle boekingen in één tabel verwerken, zoals ik op dit moment al doe. Alleen gaat dit natuurlijk in de toekomst veel performance problemen geven, dit wil ik dan ook graag voor zijn.

Onderling zijn er verschillende boekingen mogelijk: bestellingen, retouren (intern), retouren (extern), uitgave (magazijn naar personeelslid).

Hoe zouden jullie dit opslaan, ik wil eigenlijk zo min mogelijk aantal tabellen extra, zelf zit ik dan ook te denken aan de volgende opzet:

Boekingen
- ID
- soort (bestelling, retour-intern, retour-extern, uitgave)
- boekingsnummer
- medewerker_boeking

Dan vanuit het soort->boekingsnummer informatie uit de tabellen bestellingen, retouren*, uitgave

*bevat een optie intern of extern

Vanuit de tabel boekingen dan informatie uit de overige tabellen halen.

Wat is jullie idee hier over?

[Boss]

Toppe schreef op maandag 28 november 2011 @ 08:41:
Ik kan natuurlijk alle boekingen in één tabel verwerken, zoals ik op dit moment al doe. Alleen gaat dit natuurlijk in de toekomst veel performance problemen geven, dit wil ik dan ook graag voor zijn.

Waarop baseer je deze aanname? Je hebt het over een voorraad die tot nu toe in een zeecontainer past. Zolang er niet dagelijks 100.000 mutaties op de voorraad plaatsvinden denk ik dat je geen performance-problemen gaat tegenkomen bij deze omvang. Ik zou er dan ook geen probleem van maken voordat het daadwerkelijk een (bewezen, door tests) probleem is.

[Toppe]

Hallo,

Een dag of 5 in 'test' fase laat mij zien dat ik meer dan 600 (W00T) records weg schrijf. 600 is natuurlijk niet super veel op een jaar zijn dit toch 44000 records (en dan heb ik het nog niet over een zware belasting)

Daarbij vind ik deze marnier van werken zelf niet geweldig, er zijn niet veel aanpassingen mogelijk. Het lijkt mij makkelijker/verstandiger om de data toch over verschillende tabellen weg te schrijven.

Uiteraard sta ik open voor andere ideeën.

[Creepy]

40000 records is helemaal niks. Dus daar een preformance probleem verwachten is onzin. Maar als je denkt dat het toch een probleem is: test het. Insert een paar miljoen records in die tabel en query eens wat. Met de juiste indexen is dat toch echt erg snel.

[Toppe]

Hmz,

Ga ik proberen, met een paar miljoen records heb ik totaal geen ervaring. Zal vanacht eens een insert script laten lopen.

Als ik jullie dus goed begrijp, lekker alle data in één tabel verwerken. Maar, wat zijn eventueel mijn andere opties. Om een tabel boekingen aan te maken schiet je dus niets op. Je houd alsnog die aantal records, je moet alleen een dubbele query uitvoeren, dat levert dus sneller weer performance problemen op.

Daar heb ik niet over nagedacht. Ik ga deze optie zeker onderzoeken.

[kwaakvaak_v2]

buitenom wat Creepy zegt, 44000 records is pinda's voor een database, zijn meerdere tabellen niet eng en is het opzetten van een DB wel het hart van je hele systeem. Microoptimalisaties op gebied van aantal records etc is dus een serieuze verspilling van je tijd.

Maak eerst eens op papier een schema wanneer je welke data in welke situatie nodig hebt, daar kun je dan weer modellen uit distileren en in je applicatie gebruiken. Iets als een Object Mapper is zeker bij dit soort projecten handig. Want je business logic hoeft niet te weten in welk formaat je data waar staat. Die vraagt gewoon aan de Object layer, hey geef mij van product X eens de locatie en krijgt keurig een project object terug.

Kortom... denk niet in tabellen, denk in objecten met data...

[ Voor 4% gewijzigd door kwaakvaak_v2 op 28-11-2011 09:26 ]

[Toppe]

Hmz,

Ik ga eens opzoek naar object mapper, had er wel eens van gehoord maar nooit echt naar gezocht.
Wat snel google werkt levert mij weinig resultaten op, misschien dat ik zelf eens wat moet gaan knutselen met een MySql class.

[kwaakvaak_v2]

Als je php gebruikt -> doctrine2. Het is even doorbijten de eerste paar keer, maar als je eenmaal door hebt hoe het 'truukje' werkt is het een geweldig mooi systeem wat zeker enterprise geschikt is.

Lees wel even de documentatie goed, vooral de manier van relaties leggen en hoe de 'Unit of work' werkt is wel handig om te weten.

[Remus]

Toppe schreef op maandag 28 november 2011 @ 09:25:
Als ik jullie dus goed begrijp, lekker alle data in één tabel verwerken. Maar, wat zijn eventueel mijn andere opties. Om een tabel boekingen aan te maken schiet je dus niets op. Je houd alsnog die aantal records, je moet alleen een dubbele query uitvoeren, dat levert dus sneller weer performance problemen op.

Je moet gewoon een goed datamodel ontwerpen dat geschikt is om je data genormaliseerd op te slaan (evt old-school met NIAM(Natuurlijke taal Informatie Analyse Methode)/ORM (Object Role Modelling, uitbreiding van NIAM)/ER (Entity Relationship) of evt gebaseerd op je objectmodel zodat je een een ORM (Object Relational Mapper) kunt gebruiken. dit zijn dus twee verschillende betekenissen voor de term ORM!

Performanceproblemen oplossen zijn vaak een kwestie van de juiste indexen aanmaken en de verkeerde indexen verwijderen, de juiste queries en join condities gebruiken ed.

Serieus: als je je datamodel goed opzet en op de juiste wijze je data opvraagt dan maakt het niet of nauwelijks uit hoeveel data er in je database zit.

[ Voor 3% gewijzigd door Remus op 28-11-2011 12:06 ]

[Toppe]

Pff wat een hoop informatie.

Ik zal me eens wat meer moeten verdiepen in het opslaan van data in een database. Het idee van NIAM heb ik even opgezocht op google, daar kwam ik weer op een pagina van Wikipedia met een hoop informatie.

Misschien dat ik toch eens echte professionele ondersteuning moet huren, zodat die persoon voor mij een opzet kan maken met het opzetten van deze database.

Zelf wil ik niet te veel nutteloze informatie in de database hebben...

[Remus]

Toppe schreef op maandag 28 november 2011 @ 12:11:
Pff wat een hoop informatie.

Ik zal me eens wat meer moeten verdiepen in het opslaan van data in een database. Het idee van NIAM heb ik even opgezocht op google, daar kwam ik weer op een pagina van Wikipedia met een hoop informatie.

Misschien dat ik toch eens echte professionele ondersteuning moet huren, zodat die persoon voor mij een opzet kan maken met het opzetten van deze database.

Zelf wil ik niet te veel nutteloze informatie in de database hebben...

Dacht je dat een database ontwerpen gewoon even klikken en klaar was? Het ontwikkelen van software en databases is gewoon moeilijk en uitdagend werk. Overigens vind ikzelf de Wikipedia pagina over NIAM nogal karig.

[GlowMouse]

Of een bepaald aantal rijen 'peanuts is met de juiste indices', hangt helemaal af van de queries die je erop gaat draaien.

[kwaakvaak_v2]

Dat vertel je elke keer als de pinda kreet valt GlowMouse, ik denk dat je er intussentijd best vanuit mag gaan dat iemand die serieus een DB op gaat zetten, ook serieus naar indexen en qeuries gaat kijken.

Als iemand inderdaad zo dom is om 44.000 producten één voor één met 3 joins, gesorteerd op een ongeindexeerde veldnaam gaat ophalen.. Dan is het voor geen enkele DB pinda's...

[GlowMouse]

kwaakvaak_v2 schreef op maandag 28 november 2011 @ 16:59:
Dat vertel je elke keer als de pinda kreet valt GlowMouse, ik denk dat je er intussentijd best vanuit mag gaan dat iemand die serieus een DB op gaat zetten, ook serieus naar indexen en qeuries gaat kijken.

Dat krijg je met ongeclausuleerde uitspraken als "40000 records is helemaal niks". Het blijkt in praktijk voor veel ontwikkelaars ook heel moeilijk om de juiste indices te bepalen.

[cariolive23]

Toppe schreef op maandag 28 november 2011 @ 09:05:
op een jaar zijn dit toch 44000 records (en dan heb ik het nog niet over een zware belasting)

Dat doen wij hier in ongeveer iedere 10 seconden...

Het aantal zegt alleen niet zo heel erg veel, het gaat er vooral om wat je nu precies opslaat en wat je er mee gaat doen. Wanneer je alleen op dit getal afgaat, dan mag je concluderen dat je in jouw geval na een jaar dus nog steeds een vrijwel lege database hebt, 44000 records is helemaal niets.

Zorg eerst maar dat je een performance probleem hebt, dan kun je deze pas gaan oplossen. Met jouw huidige schatting van 44k records, kun je gewoon netjes een datamodel gaan normaliseren (3e normaalvorm) en op basis van jouw queries de nodige indexen gaan plaatsen. Hier hoef je nog lang niet te gaan denken aan optimaliseren, je hebt namelijk helemaal niks om te optimaliseren, er is geen probleem.

[PolarBear]

Als blijkt dat de tabel te groot is ga je niet meer tabellen aanmaken maar tabel partitionering kijken

[YopY]

Als databaseontwerp te hoog gegrepen is, waarom gebruik je uberhaupt een database? Kijk eens naar bijv. MongoDB als opslagsysteem, dan heb je veel minder geneuzel met hoe je de data op moet slaan, databaseabstractielagen, SQL, ORMs, future-proofing, schaalbaarheid etc etc etc.

[GlowMouse]

YopY schreef op zaterdag 03 december 2011 @ 12:32:
Als databaseontwerp te hoog gegrepen is, waarom gebruik je uberhaupt een database? Kijk eens naar bijv. MongoDB als opslagsysteem, dan heb je veel minder geneuzel met hoe je de data op moet slaan, databaseabstractielagen, SQL, ORMs, future-proofing, schaalbaarheid etc etc etc.

wow, een magische tool

[cariolive23]

YopY schreef op zaterdag 03 december 2011 @ 12:32:
Als databaseontwerp te hoog gegrepen is, waarom gebruik je uberhaupt een database? Kijk eens naar bijv. MongoDB als opslagsysteem, dan heb je veel minder geneuzel met hoe je de data op moet slaan, databaseabstractielagen, SQL, ORMs, future-proofing, schaalbaarheid etc etc etc.

Maar ga je dan wel eerst verdiepen in de verschillen tussen een RDBMS en een document-oriented database. MongoDB (en anderen) zijn echt geen rozegeur en maneschijn omdat het hip is, het is totaal iets anders.

Wanneer MongoDB de oplossing is voor jouw probleem, heb je nooit een RDBMS nodig gehad en was de keuze voor een RDBMS gewoon fout. Wanneer je wel een RDBMS nodig hebt, is MongoDB gewoon een foute keuze.

Dus om het nou "minder geneuzel" te noemen, lijkt me een rare uitspraak. Je moet een goede keuze maken, dat is alles. Denk bv. eens aan dataintegriteit en dus transacties.
http://www.mongodb.org/display/DOCS/Atomic+Operations

[ Voor 5% gewijzigd door cariolive23 op 03-12-2011 12:50 . Reden: linkje ]

[dingstje]

YopY schreef op zaterdag 03 december 2011 @ 12:32:
Als databaseontwerp te hoog gegrepen is, waarom gebruik je uberhaupt een database? Kijk eens naar bijv. MongoDB als opslagsysteem, dan heb je veel minder geneuzel met hoe je de data op moet slaan, databaseabstractielagen, SQL, ORMs, future-proofing, schaalbaarheid etc etc etc.

Dat is het probleem ontwijken en uitstellen, i.p.v. een goede oplossing te vinden. Over sommige dingen moet je nu eenmaal op voorhand wat nadenken. http://www.mongodb.org/display/DOCS/Use+Cases