[ALG] Opzet contacten database

[BierPul]

Ik ben bezig een flexibele contacten database op te zetten.
Deze wil ik graag zeer uitbreidbaar hebben zonder er achteraf al teveel aan te hoevel sleutelen als er een wijzging in een profiel is.

Ik was begonnen met voor elk contact type een andere tabel te definieren maar daardoor zet ik mezelf vrij snel vast waarna ik toch als er een wijziging gedaan moet worden flink in de code of database zou moeten duiken.

Ik heb ooit wel eens wat gelezen met betrekking van een soort van key/value tabel en dat lijkt me zeer flexibel.
Hier zijn ook flink nadelen aan als je kijkt naar queries en sorteren etc, graag wil ik jullie ervaringen of ideeen weten/ discussie openenen

Ik had in mn hoofd een structuur als deze:

code:

CREATE TABLE `tbl_contacts` (
  `id` int(11) NOT NULL auto_increment,
  `type` int(11) NOT NULL,
  `parent` int(11) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Elk contact heeft 1 overeenkomst een ID, type een parent. De parent zie ik voor me als een key die bijvoorbeeld een contact persoon aan een bedrijf koppeld.

vb

Contact blokker (id=1) type = 1 (winkel), parent=0
Contact Bierpul (id=2) type = 0, parent=1

code:

CREATE TABLE `tbl_contact_information` (
  `contact_id` int(11) NOT NULL,
  `key` varchar(255) NOT NULL,
  `value` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Elk contact heeft wat info bijv:

contact_id=1
key=naam
value=blokker

key=telefoon
value=020-545454545

contact_id=2
key=voornaam
value=Michael

key=email
value=[e-mail]

code:

CREATE TABLE `tbl_contact_types` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(255) NOT NULL,
  `description` text NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ;

In deze tabel staan de contact types die we in tbl_contacts kunnen gebruiken.

Op zich zal het invoeren van deze data niet zo'n probleem zijn lijkt me, voor elk type contact zou ik een array maken van de key velden en de waardes om dynamisch mn form op te kunnen bouwen.

PHP:

<?
    //ff ter test....
    $dbOutput['name'] = "Michael";
    $dbOutput['email'] = "[e-mail]";
    
    //definitie van een contact persoon, deze wijkt dus af voor andere type contacten
    $formfields[0]['name'] = 'name';
    $formfields[0]['fieldtype'] = 'text';
    $formfields[0]['displayname'] = 'naam';
    $formfields[1]['name'] = 'email';
    $formfields[1]['fieldtype'] = 'text';
    $formfields[1]['displayname'] = 'e-mail adres';
    
    //simpel maar kan natuurlijk een mooie template voor gemaakt worden die voor verschillende formfieldtypes andere velden laat zien
    $i=0;
    foreach($formfields as $key => $value) {
        echo($formfields[$i]['displayname'].'&nbsp;<input type="'.$formfields[$i]['fieldtype'].'" value="'.$dbOutput[$formfields[$i]['name']].'"/><br/>');
        $i++;
    }
?>  

Het opvragen lijkt me een stuk lastiger.

Als ik kijk naar dat ik bijvoorbeeld alle contacten zou willen hebben met de naam BierPul zou ik eerst alles moeten ophalen om dan via een eigen functie alle key/value velden na te lopen waar de value BierPul is en het key veld naam.

Of heeft er iemand een andere visie?

[ Voor 21% gewijzigd door BierPul op 29-12-2005 23:45 ]

[ripexx]

Waarom wil zo flexibel zijn. Want als je het echt helemaal flexibel wil maken zal je dus je output dynamisch moeten opbouwen aan de hand van een definitie en dus ook je query's en loops dynamisch aanpassen. Het kan allemaal wel maar weet je zeker dat je dit wil? Want je kan bij een redelijk goede opzet vrij eenvoudig uibreidingen maken, maar dan moet je wel netjes coden. Verder is het niet handig om dit voor voornaam, achternaam, email etc te doen. Want je zal zien dat je deze velden toch nodig zal hebben. Zorg er gewoon voor dat je een goede analyse maakt van je wensen en eisen en zorg ervoor dat je overzichtelijke code maakt waarin je vrij eenvoudig een extra veld kan toevoegen of verwijderen.

[BierPul]

ripexx schreef op vrijdag 30 december 2005 @ 00:05:
Waarom wil zo flexibel zijn. Want als je het echt helemaal flexibel wil maken zal je dus je output dynamisch moeten opbouwen aan de hand van een definitie en dus ook je query's en loops dynamisch aanpassen. Het kan allemaal wel maar weet je zeker dat je dit wil? Want je kan bij een redelijk goede opzet vrij eenvoudig uibreidingen maken, maar dan moet je wel netjes coden. Verder is het niet handig om dit voor voornaam, achternaam, email etc te doen. Want je zal zien dat je deze velden toch nodig zal hebben. Zorg er gewoon voor dat je een goede analyse maakt van je wensen en eisen en zorg ervoor dat je overzichtelijke code maakt waarin je vrij eenvoudig een extra veld kan toevoegen of verwijderen.

Ik kan me inderdaad vinden in je punten

Maar het leek me zo mooi als ik een nieuw conatct type nodig had.

Bijvoorbeeld tennisleraar dat ik dan alleen een nieuw definitie hoefde te maken
naam
telefoon
club
speelsterkte
leeftijd

en klaar

Het zal op zich niet nodig zijn en net coden zodat het makkelijk aan te passen is is ook geen probleem.. zie het meer als een idealistisch idee

[djluc]

Ik ben er ook mee bezig geweest: [rml][ alg]database ontwerp voor personenbeheer[/rml] Hier staan wel enkele goede puntjes in wat mogelijk is maar ook wat handig is en juist niet.

[H!GHGuY]

misschien kun je werken met 1-1 relaties. die kun je normaal wel uitbreiden. vb:

tabel contacten
ID:int
naam:varchar
parent:int
type:int

tabel personen
ID: int REF contacten
email: varchar

tabel winkels
ID: int REF contacten
adres: varchar of zoiets
winkeltype: int REF winkeltypes

je hebt dus 1 tabel met voor alle obj gemeenschappelijke data
de andere tabellen hebben een 1-1 relatie en breiden deze data uit.
in de tabel contacten duidt type voor de gemakkelijkheid aan welke tabel de rest bevat hoewel dit niet strikt verplicht is.
je kunt hierdoor uitbreiden zoveel je wil als het maar voldoet aan de tabel contacten

[ Voor 4% gewijzigd door H!GHGuY op 31-12-2005 09:49 ]

[edeboeck]

En kan je niet het beste van beide manieren combineren?

Wat ik bedoel:

ripexx schreef op vrijdag 30 december 2005 @ 00:05:
Waarom wil zo flexibel zijn. Want als je het echt helemaal flexibel wil maken zal je dus je output dynamisch moeten opbouwen aan de hand van een definitie en dus ook je query's en loops dynamisch aanpassen. Het kan allemaal wel maar weet je zeker dat je dit wil? Want je kan bij een redelijk goede opzet vrij eenvoudig uibreidingen maken, maar dan moet je wel netjes coden. Verder is het niet handig om dit voor voornaam, achternaam, email etc te doen. Want je zal zien dat je deze velden toch nodig zal hebben. Zorg er gewoon voor dat je een goede analyse maakt van je wensen en eisen en zorg ervoor dat je overzichtelijke code maakt waarin je vrij eenvoudig een extra veld kan toevoegen of verwijderen.

Gegevens die door iedereen gedeeld worden kan je in een vaste structuur steken, maar die breid je uit met je eigen idee van key/value in een extra tabel.

Je behoudt dus je tbl_contacts, maar voegt er die velden aan toe die na analyse door zowat iedereen gedeeld blijken te worden (en waar je ook vrij flexibel mee kan omspringen, ik denk aan het veld naam dat voor personen de achternaam bevat en van winkels de eigenlijke naam, waartegenover het veld voornaam voor personen de voornaam zal bevatten en bij winkels leeg kan blijven).

Je behoudt ook je tbl_contact_information en slaat daar in key/value-formaat de contactinfo op.

Op deze manier denk ik dat je zowel je overhead onder controle houdt, als je performantie op peil zonder toch je flexibiliteit te verliezen.

offtopic:
Dit is misschien wel op het randje van de forumregels, maar ik zou toch graag TS willen feliciteren voor de zeer degelijke startpost.

edit:

djluc schreef op vrijdag 30 december 2005 @ 15:24:
Ik ben er ook mee bezig geweest: [rml][ alg]database ontwerp voor personenbeheer[/rml] Hier staan wel enkele goede puntjes in wat mogelijk is maar ook wat handig is en juist niet.

Na het doorlezen van dit topic, kom ik net tot de vaststelling dat mijn hele uitleg hier, ook daar staat

[ Voor 11% gewijzigd door edeboeck op 31-12-2005 10:16 ]