🚀 go-pugleaf

In be.comp.programming Pugi! <reply@togroup.be> wrote:
> Ik ben van plan om zelf een adres-databank te maken (mysql).

The trick is to bang the rocks together...  Het vuur is al uitgevonden, het
wiel ook.  Het heet LDAP.

> Maar ben ik hier niet terug het wiel aan het uitvinden ? Hoe ziet de ultieme
> adres-databank er uit ?

Een beetje als een LDAP schema.

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  BOFH Excuse #16:
    somebody was calculating pi on the server

Op Thu, 25 Nov 2004 14:40:24 +0100, schreef Pugi!:

> Ik ben van plan om zelf een adres-databank te maken (mysql). Je kunt daar
> heelwat gegevens in kwijt zoals naam, thuisadres, verjaardag, paar email,
> telefoon, fax, gsm, huwelijksverjaardag, werk (en hier ook adres,
> functies, email, telefoon, ...), paar commentaarvelden (naam partner en
> kinderen bvb.), ...
> Maar dan zit je in je tabel met een groot aantal lege velden omdat je niet
> van iedereen de gegevens ivm werk wilt bijhouden. OK, het wordt dus een
> relationele databank met verschillende tabellen. Werk wordt een aparte
> tabel
> Land-informatie (naam land en int. telefooncode) kan ook in aparte tabel
> Provincies of staten per land kunnen ook in aparte tabel. ...
> Maar ben ik hier niet terug het wiel aan het uitvinden ? Hoe ziet de
> ultieme adres-databank er uit ?
> Heb gegoogeld met trefwoorden zoals model adresdatabank database address
> addresses datamodel, ... maar vond geen relevante links. (Was het na een
> paar dozijn beu.)
> 
> Pugi!

zelf php frontendje schrijven? :)
ik ben er ooit aan begonnen, maar niet afgemaakt, verre van zelf.

-- 
http://www.djseth.be
In music & dance I express myself as a member of a higher community....
I have forgotten how to walk and speak and I am towards flying in the air.
Raving.

Pugi! wrote:

> Ik ben van plan om zelf een adres-databank te maken (mysql). Je kunt
> daar heelwat gegevens in kwijt zoals naam, thuisadres, verjaardag,
> paar email, telefoon, fax, gsm, huwelijksverjaardag, werk (en hier ook
> adres, functies, email, telefoon, ...), paar commentaarvelden (naam
> partner en kinderen bvb.), ...
> Maar dan zit je in je tabel met een groot aantal lege velden omdat je
> niet van iedereen de gegevens ivm werk wilt bijhouden.

Dan is je database model dus fout.

Wat je bij een goed database model doet is je tabellen zo maken dat een 
minimale hoeveelheid data dubbel wordt opgeslagen (liefst niks).

Bv. Werk, er zijn vast meer mensen bij een zelfde bedrijf, en niet 
iedereen werkt.

Je kan dan een tabel voor persoongegevens, een tabel voor werkgegevens, 
en een tabel die die twee koppelt.

Als je goed naar je model gaat kijken zie je vast meer van dit soort 
zaken (adressen worden soms gedeeld, telefoonnrs, etc). 

Ook kan je een relatietabel maken, dus persoon a heeft een b relatie met 
c. 

> OK, het wordt dus een relationele databank met verschillende tabellen.
> Werk wordt een aparte tabel

:-D.

> Land-informatie (naam land en int. telefooncode) kan ook in aparte
> tabel Provincies of staten per land kunnen ook in aparte tabel.
> ...
> Maar ben ik hier niet terug het wiel aan het uitvinden ? Hoe ziet de
> ultieme adres-databank er uit ?

Die bestaat niet :-D

Maak gewoon een lijstje van wat je wilt. Bij een goed ontwerp kan je 
altijd tabellen toevoegen, met evt. een koppeltabel.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:

> Dan is je database model dus fout.
> 
> Wat je bij een goed database model doet is je tabellen zo maken dat een 
> minimale hoeveelheid data dubbel wordt opgeslagen (liefst niks).
> 
> Bv. Werk, er zijn vast meer mensen bij een zelfde bedrijf, en niet 
> iedereen werkt.
> 
> Je kan dan een tabel voor persoongegevens, een tabel voor werkgegevens, 
> en een tabel die die twee koppelt.
> 
> Als je goed naar je model gaat kijken zie je vast meer van dit soort 
> zaken (adressen worden soms gedeeld, telefoonnrs, etc). 
> 
> Ook kan je een relatietabel maken, dus persoon a heeft een b relatie met 
> c. 

Let echter ook op voor "over-normalisering" :) Het blijft steeds een 
afweging van alle faktoren.

-- 

Serge van Ginderachter

Serge van Ginderachter wrote:

> John Bokma wrote:
> 
>> Dan is je database model dus fout.
>> 
>> Wat je bij een goed database model doet is je tabellen zo maken dat
>> een minimale hoeveelheid data dubbel wordt opgeslagen (liefst niks).
>> 
>> Bv. Werk, er zijn vast meer mensen bij een zelfde bedrijf, en niet 
>> iedereen werkt.
>> 
>> Je kan dan een tabel voor persoongegevens, een tabel voor
>> werkgegevens, en een tabel die die twee koppelt.
>> 
>> Als je goed naar je model gaat kijken zie je vast meer van dit soort 
>> zaken (adressen worden soms gedeeld, telefoonnrs, etc). 
>> 
>> Ook kan je een relatietabel maken, dus persoon a heeft een b relatie
>> met c. 
> 
> Let echter ook op voor "over-normalisering" :) Het blijft steeds een 
> afweging van alle faktoren.

Uiteraard, dingen als

LeeftijdsID, met een Leeftijd tabel gaat weer een beetje erg ver :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:

>>Let echter ook op voor "over-normalisering" :) Het blijft steeds een 
>>afweging van alle faktoren.

> Uiteraard, dingen als
> LeeftijdsID, met een Leeftijd tabel gaat weer een beetje erg ver :-D.

Zeker en vast :-D

Ander realistische voorbeeld:
een tabel "klanten" en een tabel "leveranciers" vervangen door een tabel 
  "bedrijven" met extra kolom "type" die bepaalt of het een klant of 
leverancier is.

In bepaalde gevallen is het ene of het andere beter. Als je echter 
zelden klanten hebt die ook leverancier zijn, is het imho. beter het 
gescheiden te houden. Je vele queries met die tabellen zullen een stukje 
eenvoudiger zijn.


-- 

Serge van Ginderachter

Pugi! schreef:
> Ik ben van plan om zelf een adres-databank te maken (mysql). Je kunt daar 
> heelwat gegevens in kwijt zoals naam, thuisadres, verjaardag, paar email, 
> telefoon, fax, gsm, huwelijksverjaardag, werk (en hier ook adres, functies, 
> email, telefoon, ...), paar commentaarvelden (naam partner en kinderen 
> bvb.), ...
> Maar dan zit je in je tabel met een groot aantal lege velden omdat je niet 
> van iedereen de gegevens ivm werk wilt bijhouden.
> OK, het wordt dus een relationele databank met verschillende tabellen.
> Werk wordt een aparte tabel
> Land-informatie (naam land en int. telefooncode) kan ook in aparte tabel
> Provincies of staten per land kunnen ook in aparte tabel.
> ...
> Maar ben ik hier niet terug het wiel aan het uitvinden ? Hoe ziet de ultieme 
> adres-databank er uit ?
> Heb gegoogeld met trefwoorden zoals model adresdatabank database address 
> addresses datamodel, ... maar vond geen relevante links. (Was het na een 
> paar dozijn beu.)

Misschien heb je hier iets aan:
http://www.horde.org/turba/

Er is ook een IMP-driver die ervoor zorgt dat je niet hoeft in te 
loggen. Dan heb je dus gewoon een adres-boek, met mogelijkheid tot 
uitbreiden naar nog veel meer, bijvoorbeeld een agenda of webmail, alles 
in dezelfde look-en-feel.

Het is niet heel erg simpel om te installeren.

Groet,
Paul.

Pugi! wrote:
> Ik ben van plan om zelf een adres-databank te maken (mysql). Je kunt daar 
> heelwat gegevens in kwijt zoals naam, thuisadres, verjaardag, paar email, 
> telefoon, fax, gsm, huwelijksverjaardag, werk (en hier ook adres, functies, 
> email, telefoon, ...), paar commentaarvelden (naam partner en kinderen 
> bvb.), ...
> Maar dan zit je in je tabel met een groot aantal lege velden omdat je niet 
> van iedereen de gegevens ivm werk wilt bijhouden.
> OK, het wordt dus een relationele databank met verschillende tabellen.
> Werk wordt een aparte tabel
> Land-informatie (naam land en int. telefooncode) kan ook in aparte tabel
> Provincies of staten per land kunnen ook in aparte tabel.
> ...
> Maar ben ik hier niet terug het wiel aan het uitvinden ? Hoe ziet de ultieme 
> adres-databank er uit ?
> Heb gegoogeld met trefwoorden zoals model adresdatabank database address 
> addresses datamodel, ... maar vond geen relevante links. (Was het na een 
> paar dozijn beu.)

Ik heb zelf een soortgelijk probleempje:

Ik heb tabel users:
user_id: bigint
<hier komt nog meer info over de gebruiker, doet er niet toe

tabel extra_velden
veld_id: bigint
veldnaam: varchar

tabel extra_opties
user_id: bigint
veld_id: bigint
waarde: tsja, wat doe ik hier? varchar?

en ook natuurlijk nog het probleem dat je dit nooit mooi met een query 
in 1x kan opvragen

(voor wie het nog niet begrepen had, bij extra_velden worden er velden 
gedefineerd die eventueel aan een gebruiker toegewezen kunnen worden, 
bijvoorbeeld geboorteplaats.
In extra_opties vind deze link plaats. user_id het gebruikersnummer, 
veld_id de identificatie voor wat er gedefineerd wordt, en in waarde de 
waarde, maar wat voor veldtype moet dat worden, en hoe krijg ik er in de 
resultaten van de SELECT query een veld "geboorteplaats" erbij 
(bijvoorbeeld))

In article <41c0a698$0$566$e4fe514c@news.xs4all.nl>, Yorn de Jong wrote:
> Ik heb tabel users:
> user_id: bigint
><hier komt nog meer info over de gebruiker, doet er niet toe
> 
> tabel extra_velden
> veld_id: bigint
> veldnaam: varchar
> 
> tabel extra_opties
> user_id: bigint
> veld_id: bigint
> waarde: tsja, wat doe ik hier? varchar?
> 
> (voor wie het nog niet begrepen had, bij extra_velden worden er velden 
> gedefineerd die eventueel aan een gebruiker toegewezen kunnen worden, 
> bijvoorbeeld geboorteplaats.
> In extra_opties vind deze link plaats. user_id het gebruikersnummer, 
> veld_id de identificatie voor wat er gedefineerd wordt, en in waarde de 
> waarde, maar wat voor veldtype moet dat worden, en hoe krijg ik er in de 
> resultaten van de SELECT query een veld "geboorteplaats" erbij 
> (bijvoorbeeld))

 iets als?
 
SELECT *, ev.waarde AS geboorteplaats
FROM users AS u
INNER JOIN extra_opties AS eo ON u.user_id=eo.user_id
INNER JOIN extra_velden AS ev ON eo.veld_id=ev.veld_id
WHERE ev.veldnaam='geboorteplaats';

-- 
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

Yorn de Jong schreef:

> Ik heb zelf een soortgelijk probleempje:
> 
> Ik heb tabel users:
> user_id: bigint
> <hier komt nog meer info over de gebruiker, doet er niet toe
> 
> tabel extra_velden
> veld_id: bigint
> veldnaam: varchar
> 
> tabel extra_opties
> user_id: bigint
> veld_id: bigint
> waarde: tsja, wat doe ik hier? varchar?

Vertel eens wat voor soort waardes je erin wilt stoppen. Een datum is 
gewoon iets anders dan een foto of een ja/nee vraag.

> en ook natuurlijk nog het probleem dat je dit nooit mooi met een query 
> in 1x kan opvragen
 > (voor wie het nog niet begrepen had, bij extra_velden worden er velden
 > gedefineerd die eventueel aan een gebruiker toegewezen kunnen worden,
 > bijvoorbeeld geboorteplaats.
 > In extra_opties vind deze link plaats. user_id het gebruikersnummer,
 > veld_id de identificatie voor wat er gedefineerd wordt, en in waarde de
 > waarde, maar wat voor veldtype moet dat worden, en hoe krijg ik er in de
 > resultaten van de SELECT query een veld "geboorteplaats" erbij
 > (bijvoorbeeld))

Met queries kun je heel veel (alles), maar inderdaad, je hebt soms 
meerdere queries nodig. Waarom is dat een probleem?
Vertel eens waarom je het niet in 1 tabel zet? Iedere gebruiker heeft 
een geboorteplaats.

Stel je wilt de "kinderen" van die users in een aparte tabel zetten, dan 
is het logisch. Want users kunnen veel kinderen hebben.

Of stel je wilt "overnachtingen" van de users in een aparte tabel zetten 
(denk aan een hotel), dan is het ook logisch.

Groet,
Paul.

Paul van der Vlis wrote:

> Yorn de Jong schreef:
> 
>> Ik heb zelf een soortgelijk probleempje:
>> 
>> Ik heb tabel users:
>> user_id: bigint
>> <hier komt nog meer info over de gebruiker, doet er niet toe
>> 
>> tabel extra_velden
>> veld_id: bigint
>> veldnaam: varchar
>> 
>> tabel extra_opties
>> user_id: bigint
>> veld_id: bigint
>> waarde: tsja, wat doe ik hier? varchar?
> 
> Vertel eens wat voor soort waardes je erin wilt stoppen. Een datum is
> gewoon iets anders dan een foto of een ja/nee vraag.
> 
>> en ook natuurlijk nog het probleem dat je dit nooit mooi met een query
>> in 1x kan opvragen
>  > (voor wie het nog niet begrepen had, bij extra_velden worden er velden
>  > gedefineerd die eventueel aan een gebruiker toegewezen kunnen worden,
>  > bijvoorbeeld geboorteplaats.
>  > In extra_opties vind deze link plaats. user_id het gebruikersnummer,
>  > veld_id de identificatie voor wat er gedefineerd wordt, en in waarde de
>  > waarde, maar wat voor veldtype moet dat worden, en hoe krijg ik er in
>  > de resultaten van de SELECT query een veld "geboorteplaats" erbij
>  > (bijvoorbeeld))
> 
> Met queries kun je heel veel (alles), maar inderdaad, je hebt soms
> meerdere queries nodig. Waarom is dat een probleem?
> Vertel eens waarom je het niet in 1 tabel zet? Iedere gebruiker heeft
> een geboorteplaats.
> 
> Stel je wilt de "kinderen" van die users in een aparte tabel zetten, dan
> is het logisch. Want users kunnen veel kinderen hebben.

Dat is nou juist helemaal niet logisch. Die kinderen zijn ook mensen, en kun
je dus in principe exact dezelfde gegevens voor opslaan, dus zou ik dat in
dezelfde tabel stoppen. Wat je wel in een andere tabel wilt is de relaties
tussen de personen. Maak b.v. een tabel user_rel aan met drie velden,
first_id, second_id, relation_type. Met een relation_type van b.v.
"parent_of" geef je aan dat de user in de user-table met userid first_id de
vader/moeder is van second_id.
Zo is het meteen mooi uitbreidbaar naar getrouwd, gescheiden, of wat voor
andere relaties je in de toekomst ook nog maar kunt verzinnen

Floris.

Floris Kruisselbrink schreef:

>>Stel je wilt de "kinderen" van die users in een aparte tabel zetten, dan
>>is het logisch. Want users kunnen veel kinderen hebben.
> 
> Dat is nou juist helemaal niet logisch. Die kinderen zijn ook mensen, en kun
> je dus in principe exact dezelfde gegevens voor opslaan, dus zou ik dat in
> dezelfde tabel stoppen. 

OK, ik heb misschien niet helemaal goed nagedacht over dat voorbeeld.

Het andere voorbeeld was misschien beter.

Groet,
Paul.

Someone referred to as: Paul van der Vlis <paul@vandervlis.nl>
 has comitted the herein quoted text :

[knipje]

> > je dus in principe exact dezelfde gegevens voor opslaan, dus zou ik dat in
> > dezelfde tabel stoppen.
> 
> OK, ik heb misschien niet helemaal goed nagedacht over dat voorbeeld.
> 
> Het andere voorbeeld was misschien beter.

Misschien een schrale troost: Databases ontwerpen doet men pas een jaar
of 50 ofzo, en nog steeds heeft men "The Holy Grail" op dat gebied
niet gevonden.

Vergelijk het bv met met de behoeften en wensen van een bepaald
"type auto" in een hele levensloop vanaf 18-80 ... ;-) 


Cor

-- 
(setq load-path (cons (expand-file-name "~/HyperSpec/") load-path))
         Any system is as safe as the dumbness of its keeper
		    Thou shall not worship false Operating-Systems

Paul van der Vlis wrote:
> Yorn de Jong schreef:
> 
>> Ik heb zelf een soortgelijk probleempje:
>>
>> Ik heb tabel users:
>> user_id: bigint
>> <hier komt nog meer info over de gebruiker, doet er niet toe
>>
>> tabel extra_velden
>> veld_id: bigint
>> veldnaam: varchar
>>
>> tabel extra_opties
>> user_id: bigint
>> veld_id: bigint
>> waarde: tsja, wat doe ik hier? varchar?
> 
> 
> Vertel eens wat voor soort waardes je erin wilt stoppen. Een datum is 
> gewoon iets anders dan een foto of een ja/nee vraag.
Da's dus juist afhankelijk van degene die de tabel beheert. 't kan een 
datum zijn, een foto, een ja/nee vraag, een tekstje, en nog wel veel 
meer. 't gaat er juist om dat de database makkelijk te "updaten" is

>> en ook natuurlijk nog het probleem dat je dit nooit mooi met een query 
>> in 1x kan opvragen
> 
>  > (voor wie het nog niet begrepen had, bij extra_velden worden er velden
>  > gedefineerd die eventueel aan een gebruiker toegewezen kunnen worden,
>  > bijvoorbeeld geboorteplaats.
>  > In extra_opties vind deze link plaats. user_id het gebruikersnummer,
>  > veld_id de identificatie voor wat er gedefineerd wordt, en in waarde de
>  > waarde, maar wat voor veldtype moet dat worden, en hoe krijg ik er in de
>  > resultaten van de SELECT query een veld "geboorteplaats" erbij
>  > (bijvoorbeeld))
> 
> Met queries kun je heel veel (alles), maar inderdaad, je hebt soms 
> meerdere queries nodig. Waarom is dat een probleem?
> Vertel eens waarom je het niet in 1 tabel zet? Iedere gebruiker heeft 
> een geboorteplaats.
Omdat de admin dingen mag toevoegen aan de vragen die aan de gebruikers 
worden gesteld.
Niet op iedere site wordt er naar je geboorteplaats of sofi-nummer gevraagd.

> Stel je wilt de "kinderen" van die users in een aparte tabel zetten, dan 
> is het logisch. Want users kunnen veel kinderen hebben.
> 
> Of stel je wilt "overnachtingen" van de users in een aparte tabel zetten 
> (denk aan een hotel), dan is het ook logisch.
't gaat hier juist om extra gegevens over een gebruiker op te slaan, 
niet om de gegevens die je toch al wel zou opslaan (als je een hotel 
hebt, zullen de users vast wel minimaal 1 nacht blijven slapen)

Yorn de Jong schreef:
> Paul van der Vlis wrote:
> 
>> Yorn de Jong schreef:
>>
>>> Ik heb zelf een soortgelijk probleempje:
>>>
>>> Ik heb tabel users:
>>> user_id: bigint
>>> <hier komt nog meer info over de gebruiker, doet er niet toe
>>>
>>> tabel extra_velden
>>> veld_id: bigint
>>> veldnaam: varchar
>>>
>>> tabel extra_opties
>>> user_id: bigint
>>> veld_id: bigint
>>> waarde: tsja, wat doe ik hier? varchar?
>>
>> Vertel eens wat voor soort waardes je erin wilt stoppen. Een datum is 
>> gewoon iets anders dan een foto of een ja/nee vraag.
> 
> Da's dus juist afhankelijk van degene die de tabel beheert. 't kan een 
> datum zijn, een foto, een ja/nee vraag, een tekstje, en nog wel veel 
> meer. 't gaat er juist om dat de database makkelijk te "updaten" is

Het lijkt me dat ze zoiets zouden kunnen doen door velden aan de tabel 
toe te voegen. Dan kunnen ze ook zelf bepalen welke velden.
Je zou een paar voorbeeldjes kunnen maken.

>> Met queries kun je heel veel (alles), maar inderdaad, je hebt soms 
>> meerdere queries nodig. Waarom is dat een probleem?
>> Vertel eens waarom je het niet in 1 tabel zet? Iedere gebruiker heeft 
>> een geboorteplaats.
> 
> Omdat de admin dingen mag toevoegen aan de vragen die aan de gebruikers 
> worden gesteld.
> Niet op iedere site wordt er naar je geboorteplaats of sofi-nummer 
> gevraagd.

OK, dat kan hij doen dus.

>> Stel je wilt de "kinderen" van die users in een aparte tabel zetten, 
>> dan is het logisch. Want users kunnen veel kinderen hebben.
>>
>> Of stel je wilt "overnachtingen" van de users in een aparte tabel 
>> zetten (denk aan een hotel), dan is het ook logisch.
> 
> 't gaat hier juist om extra gegevens over een gebruiker op te slaan, 
> niet om de gegevens die je toch al wel zou opslaan (als je een hotel 
> hebt, zullen de users vast wel minimaal 1 nacht blijven slapen)

Niet de mensen die alleen informatie opvragen.

Groet,
Paul.