Datamodel MySQL database

foondump ontwikkeling
1

Ik heb de cdfoon naar een MySQL database gedumpt.
Is er ook een overzicht van de relaties tussen de tabellen?

Alvast bedankt

Andries

2

Tuurlijk:

3

Ok, bedankt.

Alleen hoe leg ik de link van pinksubscriber naar phonenumbers?
Wanneer ik mbv pinksubscriber.subscribernumber in de tabel subscriber ga zoeken vindt ik meerdere records.

In de tabel pinksubscriber zitten ook veel dubbele records, dwz records met
dezelfde naam, postcode, plaats maar verschillende md5 en subscribernumber waardes? Zelfs subscribernumber is niet uniek.

4

In de huidige versie van de Foondump database is de pink database nog niet genormaliseerd. Dat houdt in dat er nog geen link is van pinksubscriber naar een aparte phonenumbers tabel. Daarom komen er ook records voor waarbij alleen het telefoonnummer verschillend is.

In de volgende versie van Foondump zal de database anders zijn opgezet. Er zal dan ook een pink_info en een pink_phonenumbers tabel zijn. De database zal er waarschijnlijk als volgt uit zien:

5

Enig idee wanneer de volgende versie uitkomt?

6

Hoi RGJ,

Mooi nieuw datamodel --)

Ik zie dat seq niet in pink_info terugkomt. (seq zit wel in white_info).

Ik kan mij herinneren dat de volgorde van de info records belangrijk is bij de opmaak van een “info card”.

De vriendelijk groet Jan Marco

7

Hmm, de white_info tabel heeft ook geen ‘seq’ kolom, maar die heeft Powerdesigner gisteren zelf ingevoegd. Meestal is dat een teken dat er nog een klein foutje in het model zit. Daar zal ik nog even naar kijken.

Scherp gezien, ik had er overheen gekeken. Bedankt!

PS De volgorde van de info records wordt bepaald door lineno, recno.

8

Volgens mij zijn die seq velden (incl index) overbodig in phonenumers, subscriber en info. id is immers de verbinding tussen die tabellen.

Die onnodig velden kosten alleen maar mysql overhead. Weg ermee! :wink:

9

Nee.
Zoals ik al zei: in phonenumbers en info zit helemaal geen seq veld maar heeft Powerdesigner die er per ongeluk ingezet.
In subscriber is id niet uniek omdat een id wordt hergebruikt voor dubbele vermeldingen (bv als zowel man als vrouw hun achternaam hebben geregistreerd op dezelfde vermelding). Het id veld is dus niet geschikt als primary key (want die moet uniek zijn). Daarom is het seq veld als PK ingezet.

10

RGJ,

Erg mooi model --).

Ik zit even wat na te denken. Ik zie in hoofdlijn drie stukken database op de cdfoon.

  1. wooninrichtingen (white).

  2. bedrijfinrichtingen (pink)

  3. werknemers/bewoners. (“je kan een prive lijstje in de cdfoon invulen”). N.B. http://www.thawte.com gebruikt sofinummer als key voor personen.

Iemand in 3) kan bij 1 of meerdere bedrijven werken of in 1 of meerdere wooninrichtingen wonen. Denk hierbij aan ma t/m vrijdag in Den Haag wonen en za/zo in Groningen verblijven.

M.i. is deze indeling voor de online versie wel toepasbaar. Voor de batch foondump versie nog niet zo interessant,

De vriendelijke groet Jan Marco