[mysql]table structuur vraag

[paragon]

Ik ben vandaag in overleg met iemand over de structuur van een database table. De inhoud ervan wordt best aanzienlijk, in de miljoenen records. Het gaat een 15cijferige reeks die wordt toegevoegd in de database vanuit een spreadsheet. De bedoeling is om op duplicaten te testen. Zitten er duplicaten in dezelfde spreadsheet dan moet er een low level waarschuwing komen en zitten de duplicaten in een andere spreadsheet dan moet er een high lever waarschuwing komen. mijn idee was om met de volgende structuur te komen

id	15digit_id	spreadsheet_id	blank_1	blank_2
1	345012345678901	1	NULL	NULL
2	345012345678923	1	NULL	NULL
..	.....	..	NULL	NULL
1500	345012345687256	2	NULL	NULL
1501	345012345685469	2	NULL	NULL

hier is id een autoincrement, 15digit_id het eigenlijke indentifiactie nummer van een object en spreedsheet_id de identificatie van het originele spreadsheet doh. De andere persoon is alleen bang voor de grote van de database en wil voor de volgende opzet kiezen.

id	phoneid
1	1
2	blank
3	blank
4	345012345678901
5	345012345678923
..	.....
..	.....
1500	345012345679725
1501	2
1502	blank
1503	blank
1504	345012345687256
1505	345012345685469

[ Voor 15% gewijzigd door paragon op 18-04-2005 15:01 ]

[farlane]

Het is logisch om voor je apparaten ( tenminste ik neem aan dat die code een imei nummer is ) een aparte tabel te maken.

[paragon]

Jij bedoelt 1 tabel spreadsheet gegevens? Andere tabel imei?

[Daos]

Als je dat 15 cijferige nummer als sleutel gebruikt in je tabel, dan kan hij er nooit dubbel in komen. Je kan ook eerst zoeken in de database voordat je er een nieuwe bijgooit.

Voor 15 cijferig nummer heb je 50 bits nodig. Ik weet niet welke datatypen je allemaal hebt in de database, maar dit zullen er waarschijnlijk 64 worden. Spreadsheet_id is niet zo groot. Wat er in blank_1 en blank_2 moet komen zie ik niet. Het eerste geval is niet veel groter dan het tweede.
Gebruik in ieder geval geen strings. 15 cijfers + '\0' = 16 bytes = 128 bits. Of zelfs 256 bits als je unicode hebt. Base64-string is weliswaar al iets beter, maar kost nog steeds (50 / 6) = 9 characters + '\0' = 80 bits in het beste geval.

[paragon]

Het probleem is dus dat ik het 15 cijferige nummer niet als key kan gebruiken. Ze zouden uniek moeten zijn, maar ergens gaat er iets fout en zijn er toch aanzienlijk wat duplicaten. Ze moeten echter wel toegevoegd worden omdat het om leveringen apparaten gaat. En een duplicaat kan in het ergste geval beteken dat een aparaat 2x geleverd wordt . Wat er in blank_1 en blank_2 te staan komt weet ik zelf ook nog niet.

[Daos]

Het enige verschil tussen de voorstellen is dus spreadsheet_id. Dat is een getal en maakt volgens mij niet zoveel uit voor het formaat van je record.

Maar zoals ik al eerder zei: Denk goed na over hoe je dat 15 cijferige nummer op gaat slaan.

[ Voor 25% gewijzigd door Daos op 18-04-2005 14:23 ]

[farlane]

paragon schreef op maandag 18 april 2005 @ 13:15:
Jij bedoelt 1 tabel spreadsheet gegevens? Andere tabel imei?

Ja

[paragon]

Daos schreef op maandag 18 april 2005 @ 14:20:
Het enige verschil tussen de voorstellen is dus spreadsheet_id. Dat is een getal en maakt volgens mij niet zoveel uit voor het formaat van je record.

Maar zoals ik al eerder zei: Denk goed na over hoe je dat 15 cijferige nummer op gaat slaan.

Dat is niet het enige verschil, in de tweede optie heb je maar 2 velden en wordt er in het 2de veld ok informatie opgeslagen die er naar mijn mening niet in hoort namelijk: spreadsheet_id, blank en blank. Dit omdat iemand anders dus denkt dat je nu een kleinere database krijgt omdat je voor die informatei geen aparte velden maakt.

farlane schreef op maandag 18 april 2005 @ 14:35:
[...]
Ja

Wat verandert dit aan de situatie?

OK dus dit is de bedoeling:

Imei

id	15digit_id	spreadsheet_id
1	345012345678901	1
2	345012345678923	1
..	.....	..
1500	345012345687256	2
1501	345012345685469	2

Spreadsheets

id	blank_1	blank_2
1	Null	Null
2	Null	Null

[ Voor 40% gewijzigd door paragon op 18-04-2005 15:08 ]

[farlane]

Je imeinummer kan in meerdere spreadsheets voorkomen, je spreadsheet kan meerdere imeinummers bevatten.

Dit suggereert een veel op veel relatie...dwz dat je tenminste 3 tabellen krijgt, 1 met imeinummers en de gegevens die daarbij horen, 1 met documenten en een koppeltabel

Je kolomnamen blank_1 en blank_2 suggereren dat er nog meer info in die koppeltabel moet komen trouwens. ( Het riekt naar het begin van een minder goed ontwerp )

[ Voor 24% gewijzigd door farlane op 18-04-2005 16:00 ]

[paragon]

Je bedoelt zoiets:
imei:

imei

345012345678901

345012345678923

Spreadsheets

id	date	supplier
1	180405	compone
2	230405	comptwo

Koppeltabel

id	imei	spreadsheet
1	345012345678901	1
2	345012345678923	1

Of niet? Wat is het voordeel hiervan tenopzichte van mijn vorige reply? Ik heb nu ipv blank_1 en blank_2 even iets concreters gebruikt.

[farlane]

Zoiets, maar ik zou het imeinummer zelf geen pk maken maar een unique constraint oid, en een andere pk nemen.

Wat je op deze manier kunt doen:

- Zien welke spreadsheets y naar apparaat met imei code x refereren
- Op welke spreadsheets y apparaat met imeinummer x voorkomen
- Afdwingen dat een appraat met imeinummer x maar een maal voorkomt.
- Afdwingen dat een spreadsheet y maar een maal voorkomt
- Je hebt geen dubbele gegevens in je db
- .....

Ik vind eerlijk gezegd ook dat de opzet er 'logischer' uitziet.

[paragon]

Maar het probleem is dus dat er op de een of andere manier dus meerdere apparaten met hetzelde imei nummer zijn. Kan dit dan nog wel op deze manier.

Meerdere referenties natuurlijk.

[ Voor 11% gewijzigd door paragon op 19-04-2005 18:05 ]

[farlane]

paragon schreef op dinsdag 19 april 2005 @ 18:04:
Maar het probleem is dus dat er op de een of andere manier dus meerdere apparaten met hetzelde imei nummer zijn. Kan dit dan nog wel op deze manier.

Meerdere referenties natuurlijk.

Als er meerdere 'echte' apparaten met hetzelfde imei nummer zijn, kan deze opzet niet ( als je die unique maakt ), dan zul je verder moeten normaliseren.
Als je bedoelt dat er meerdere referenties zijn naar hetzelfde imei nummer ( en dus hetzelfde apparaat ) is deze opzet voldoende.

Ik ga er dus van uit dat het imei nummer uniek is en dat je daarmee een apparaat kunt identificeren. ( Was ook een beetje het idee van een imei nummer )

[Guldan]

Ander zou je in die iMei tabel ook gewoon nog een andere Primary key in kunnen voeren maar dat is niet echt de netste oplossing qua database design. En dan hou je dus nog steeds die koppeltabel. Zoals de structuur er nu staat biedt hij ook meer ruimte voor uitbreiding.