[mysql] database maken voor relatief veel data

[Beneveerg]

Laat ik even beginnen dat ik totaal geen programmeur ben, maar alleen wat kan knutselen.

Ik wil een database maken om bij te houden wel persoon een bepaald product hebt. Laten we zeggen Appels. Appels worden geleverd in batches van ruim 5000 appels. Elke appel heeft een uniek nummer binnen de batch. Batch1 heeft dus 0, 1, 2, 3 enz en Batch2 heeft ook 0, 1, 2, 3 enz. Zo gaan ook de batches door.

In een database wil ik weten welke persoon welke appels uit welke batch ik heb.

De data zelf krijg ik vanuit een JSON file.

Relevante software en hardware die ik gebruik
MySQL

Wat ik al gevonden of geprobeerd heb
Ik zat zelf te denken aan een tabel waar je een kolom hebt met gebruiker, batchnummer en appel nummer. Bij 10 batches krijg je dan al ruim 50.000 records, dat is misschien niet zo efficiënt. Is er een betere manier om dit bij te houden?

[Kheos]

je wil je even verdiepen in DB design
je hebt dan bijvoorbeeld een tabel met batches en een tabel met personen en een 3e tabel om de koppeling tussen de twee te maken

[Montaner]

Normaliseer je data maar eens om tot een ontwerp van je database te komen. Daarna kunnen we je misschien nog verder helpen als je er niet uitkomt.

Ps. relatief veel data? Wat is relatief? Er zijn ook databases met miljarden records..

[Boss]

50.000 records is niet veel voor een database. Klinkt als een goede opzet zo. Pas vanaf 1mln records moet je wellicht wat meer gaan nadenken over tuning van de database.

[Beneveerg]

Kheos schreef op dinsdag 2 april 2024 @ 10:23:
je wil je even verdiepen in DB design
je hebt dan bijvoorbeeld een tabel met batches en een tabel met personen en een 3e tabel om de koppeling tussen de twee te maken

Dat lukt mij wel. Blijf ik dan niet dezelfde aantal records hebben als wat ik zou hebben met 1 tabel?

Montaner schreef op dinsdag 2 april 2024 @ 10:31:
Normaliseer je data maar eens om tot een ontwerp van je database te komen. Daarna kunnen we je misschien nog verder helpen als je er niet uitkomt.

Ps. relatief veel data? Wat is relatief? Er zijn ook databases met miljarden records..

Dit is een beetje de data

Eigenaar - Batch - Product
Persoon A - Batch 1 - 0
Persoon A - Batch 1 - 2
Persoon A - Batch 1 - 3
Persoon A - Batch 1 - 4
Persoon A - Batch 1 - 5
Persoon A - Batch 1 - 6
Persoon A - Batch 2 - 600
Persoon A - Batch 2 - 601
Persoon A - Batch 3 - 1602
Persoon A - Batch 3 - 1603
Persoon B - Batch 1 - 7
Persoon B - Batch 1 - 8

Elke combinatie van batch + product kan maar 1 keer voorkomen in de database.

[IceFox]

Beneveerg schreef op dinsdag 2 april 2024 @ 10:35:
[...]


Dat lukt mij wel. Blijf ik dan niet dezelfde aantal records hebben als wat ik zou hebben met 1 tabel?


[...]


Dit is een beetje de data

Eigenaar - Batch - Product
Persoon A - Batch 1 - 0
Persoon A - Batch 1 - 2
Persoon A - Batch 1 - 3
Persoon A - Batch 1 - 4
Persoon A - Batch 1 - 5
Persoon A - Batch 1 - 6
Persoon A - Batch 2 - 600
Persoon A - Batch 2 - 601
Persoon A - Batch 3 - 1602
Persoon A - Batch 3 - 1603
Persoon B - Batch 1 - 7
Persoon B - Batch 1 - 8

Elke combinatie van batch + product kan maar 1 keer voorkomen in de database.

Als een batch altijd volledig naar dezelfde person gaat en opeenvolgende nummers heeft kan je ook een entiteit “batch” maken met start/stop nummer en die aan een persoon koppelen.

[Kheos]

Beneveerg schreef op dinsdag 2 april 2024 @ 10:35:
[...]
Dat lukt mij wel. Blijf ik dan niet dezelfde aantal records hebben als wat ik zou hebben met 1 tabel?

als je je design normaliseert kom je daar vanzelf achter

focus je maar niet op die aantallen (zoals iedereen hier al aangeeft 50.000 records is niks) je design is momenteel veel belangrijker

[downtime]

IceFox schreef op dinsdag 2 april 2024 @ 10:37:
[...]


Als een batch altijd volledig naar dezelfde person gaat en opeenvolgende nummers heeft kan je ook een entiteit “batch” maken met start/stop nummer en die aan een persoon koppelen.

Je ziet al in zijn voorbeeld dat dat niet het geval is. Batch 1 is verdeeld over 2 personen. Hier valt niks meer te normaliseren. Je krijgt gewoon een nieuw record voor elke appel.

[RM-rf]

bij een relationele database krijg je natuurlijk nog veel meer records...

niet enkele de tabellen voor batch, persoon en appel, maar ook de relaties ertussen, dus welke appel in welke batch zich bevind of hoe een appel zich tot een persoon verhoud...

is ook niet erg, databases zijn er juist op gebouwd zeer veel items te bevatten en hier heel snel in te kunnen sorteren of selecties uit te voeren.


de vraag is hooguit wel of je dat nodig hebt... eerlijk gezegd lees ik dat niet in het verhaal, welke databse-gebaseerde selecties, ordeningen of queries nodig zouden zijn...

enkel om "bij te houden welke persoon welke appel heeft" kun je bijna net zo goed in een textfile doen (als het aantal personen beperkt is en ze allemaal een of een paar appels in hun bezit hebben

[ThomasG]

Hier zijn relationele databases juist voor bedoeld. Als de tabellen goed zijn ontworpen en bijvoorbeeld de juiste indexering gebruiken, is dit allemaal geen probleem. Uit wat ik uit jouw berichten begrijp, gaat het om een koppeltabel met 3 relaties (persoon, batch, product), wat hoogstwaarschijnlijk gewoon neerkomt op een tabel met 3 integers. Daar hoef je je geen zorgen over te maken.

[Montaner]

Een voorstel van GPT... met nog wat veldjes erbij verzonnen

In je rationalisatie zou je bv. appels en batches nog in 1 tabel kunnen opnemen. Of juist apart houden.. dus; normaliseer je data en stel een concrete vraag waar je hulp nodig hebt. Eventueel vooraf nog wat kennis op doen over wat dat dan is, genoeg te vinden op YouTube.

code:

+-------------------+       +-------------------+       +-------------------+
| Personen          |       | Appels            |       | Batches           |
+-------------------+       +-------------------+       +-------------------+
| PersoonID (PK)    |       | AppelID (PK)      |       | BatchID (PK)      |
| Voornaam          |       | Soort             |       | Oogstdatum        |
| Achternaam        |       | Kleur             |       | Locatie           |
| ...               |       | ...               |       | ...               |
+-------------------+       +-------------------+       +-------------------+
        |                           |                           |
        |                           |                           |
        |                           |                           |
        |                           |                           |
        |                           |                           |
+-------------------+       +-------------------+       +-------------------+
| PersoonAppelKoppeling |       |                   |       |                   |
+-------------------+       +-------------------+       +-------------------+
| PersoonID (FK)    |       |                   |       |                   |
| AppelID (FK)      |       |                   |       |                   |
| DatumConsumptie  |       |                   |       |                   |
+-------------------+       +-------------------+       +-------------------+
        |                           |                           |
        |                           |                           |
        |                           |                           |
        |                           |                           |
        |                           |                           |
+-------------------+       +-------------------+       +-------------------+
| AppelBatchKoppeling |       |                   |       |                   |
+-------------------+       +-------------------+       +-------------------+
| AppelID (FK)      |       |                   |       |                   |
| BatchID (FK)      |       |                   |       |                   |
+-------------------+       +-------------------+       +-------------------+

[ Voor 5% gewijzigd door Montaner op 02-04-2024 13:22 ]

[Beneveerg]

Ik heb het inmiddels in 1 tabel gezet en het werkt prima voor wat ik nodig heb.

Bedankt voor de hulp