[Database] 'dynamische' tabellen

[Yoshi|IA2]

Hallo,

Ik zou een database moeten opzetten die zeer flexibel is. Er zouden metadata van personen in komen te staan (leeftijd, gewicht, lengte, ...).
Dit zou redelijk simpel kunnen maar het probleem is dat het mogelijk moet zijn om simpel extra metadata toe te voegen.
Dit kan natuurlijk door telkens een tabel bij te voegen en deze te matchen op id. Maar dan zou de applicatie telkens opnieuw geschreven moeten worden.

Ik dacht in eerste instantie aan het volgende:
tabel 1: met toegelaten metadata, met attributen metadata-naam, type.
Het type kan maar een vast aantal waarden aannemen (bv int, smallint, string, ...)

Dan een aantal tabellen waar de de attributen zelf opgeslaan worden.
Dan zou er voor elk type een tabel aangemaakt moeten worden van de vorm id, attribuut, waarde. Dan heb je een 'stringtabel', 'inttabel', ...

Het voordeel dat ik hiervan zie is dat er makkelijk attributen bijgevoegd kunnen worden zondar dat er iets aan de applicatie of het database schema moet veranderen. De applicatie moet gewoon tabel1 uitlezen en dan weet hij welke metadata in welke tabel te vinden is.

Dit is de beste oplossing die ik tot nu toe gevonden heb. Heeft er iemand een betere oplossing, of ziet er iemand haken en ogen aan mijn oplossing?

[Sosabowski]

gewoon een kolom toevoegen aan de table?

[MisterData]

Denk ik nou te simpel of is het gewoon een tabel met de volgende velden:

persoon_id - attribuut_naam of een fk - inhoud van dat attribuut

Met als inhoud:

1,HAARKLEUR,Bruin
2,GESLACHT,Man
1,GESLACHT,Vrouw

[BoomSmurf]

MisterData schreef op 01 september 2004 @ 12:25:
Denk ik nou te simpel of is het gewoon een tabel met de volgende velden:

persoon_id - attribuut_naam of een fk - inhoud van dat attribuut

Met als inhoud:

1,HAARKLEUR,Bruin
2,GESLACHT,Man
1,GESLACHT,Vrouw

Dit is naar mijn mening ook de makkelijkste manier om dit voor elkaar te krijgen...

Edit: TS z'n toevoegen om verschillende tabellen voor verschillende types toe te voegen zou het wellicht nog het beste zijn. Dus wat dat betreft heb ik eigenlijk weinig toe te voegen

[ Voor 19% gewijzigd door BoomSmurf op 01-09-2004 12:51 ]

[lier]

Krijg je heel veel info in de database of zou een XML file ook volstaan ?
Naar mijn idee ga je een database misbruiken...

Wat is hier (in het algemeen) het nut van ???
En hoe maak je je front-end zo flexibel, dat deze met de extra data om kan gaan ?

[Alarmnummer]

In prolog kom ik dit soort problemen ook wel eens tegen en dan los ik het op door een nieuwe 'tabel' voor een eigenschap aan te maken.

haarkleur(jan,geel)
haarkleur(peter,zwart)

Op deze manier kan je onbeperkt eigenschappen aan entiteiten toevoegen (je maakt voor iedere nieuwe eigenschap een tabel aan, met 2 colommen: 1) de id van de entiteit waarop je die eigenschap gaat toevoegen, en in colom 2 kan de waarde van die eigenschap staan.

Maar ik weet niet hoe prettig dit zich laat vertalen naar een echte database.

[ Voor 4% gewijzigd door Alarmnummer op 01-09-2004 12:37 ]

[BoomSmurf]

lier schreef op 01 september 2004 @ 12:34:
Krijg je heel veel info in de database of zou een XML file ook volstaan ?
Naar mijn idee ga je een database misbruiken...

Waariom zou je hierdoor een database misbruiken? Een database is om data bij te houden en hij houdt er data in bij... What's the problem?

Wat is hier (in het algemeen) het nut van ???
En hoe maak je je front-end zo flexibel, dat deze met de extra data om kan gaan ?

Dat kan op heel veel verschillende manieren. Of je maakt er een lelijke grid van, of je gaat dynamische db edit boxen aanmaken of iets, etc.

[BoomSmurf]

Alarmnummer schreef op 01 september 2004 @ 12:36:
In prolog kom ik dit soort problemen ook wel eens tegen en dan los ik het op door een nieuwe 'tabel' voor een eigenschap aan te maken.

haarkleur(jan,geel)
haarkleur(peter,zwart)

Op deze manier kan je onbeperkt eigenschappen aan entiteiten toevoegen (je maakt voor iedere nieuwe eigenschap een tabel aan, met 2 colommen: 1) de id van de entiteit waarop je die eigenschap gaat toevoegen, en in colom 2 kan de waarde van die eigenschap staan.

Maar ik weet niet hoe prettig dit zich laat vertalen naar een echte database.

Het probleem met 'on-the-fly' tabellen en kollommen toevoegen is dat dit een hele 'dure' operatie is, en verder niet volledig ondersteund wordt door verschillende DBMS'en. Je zult echt moeten weten welke DBMS er gebruikt wordt en hoe vaak zulke dingen gebeuren om te kunnen zeggen of dit wel of niet kan en handig is.

Ik zou het zelf nooit zo doen, simpelweg omdat de database er niet fijner op wordt om even met een db-editor dingen te gaan lopen wijzigen als dat nodig is

[Alarmnummer]

BoomSmurf schreef op 01 september 2004 @ 12:39:
[...]
Het probleem met 'on-the-fly' tabellen en kollommen toevoegen is dat dit een hele 'dure' operatie is, en verder niet volledig ondersteund wordt door verschillende DBMS'en.

Het lijkt me stug dat een database geen DDL commando`s kan uitvoeren. Dus je kan altijd 'on the fly' tabellen aanmaken.

Ik zou het zelf nooit zo doen, simpelweg omdat de database er niet fijner op wordt om even met een db-editor dingen te gaan lopen wijzigen als dat nodig is

Ik weet ook niet of ik het zelf zo zou aanpakken, maar in Prolog is het de manier om informatie toe te voegen aan entiteiten.

[BoomSmurf]

Alarmnummer schreef op 01 september 2004 @ 12:43:
Het lijkt me stug dat een database geen DDL commando`s kan uitvoeren. Dus je kan altijd 'on the fly' tabellen aanmaken.

Ik had duidelijker moeten zijn: ik doelde hier vooral op het kolommen aanmaken in een bestaande tabel. Tabellen aanmaken zou iedere DBMS moeten kunnen Nu had jij het alleen maar over tabellen, maar een stukje naar boven hadden ze het over kolommen toevoegen.

Ik weet ook niet of ik het zelf zo zou aanpakken, maar in Prolog is het de manier om informatie toe te voegen aan entiteiten.

Ik ken geen Prolog, dus als jij het zegt

[ Voor 10% gewijzigd door BoomSmurf op 01-09-2004 12:48 ]

[Verwijderd]

Misschien een idee, waar ik ongetwijfeld veel kritiek op ga krijgen:

je kunt ook gewoon een tabel aanmaken met een 'oneindig' aantal kolommen. Dus zoveel dat je in de toekomst niet verwacht uberhaupt nog meer eigenschappen van een persoon te kunnen verzinnen, laat staan bijhouden.
Deze kolommen nummer je oplopend. Vervolgens maak je nog een extra coderingstabel aan, en daarin zet je pas wat iedere kolom voorstelt.
Probleem is natuurlijk dat je dan in de eerste tabel niet de juiste gegevenstypen hebt. Ik weet zelf niet precies hoe, maar er is ongetwijfeld iemand die je kan vertellen hoe je dit automatisch kunt wijzigen door het aanroepen van een functie.

[ripexx]

Verwijderd schreef op 01 september 2004 @ 13:00:
Misschien een idee, waar ik ongetwijfeld veel kritiek op ga krijgen:

Jup

je kunt ook gewoon een tabel aanmaken met een 'oneindig' aantal kolommen. Dus zoveel dat je in de toekomst niet verwacht uberhaupt nog meer eigenschappen van een persoon te kunnen verzinnen, laat staan bijhouden.
Deze kolommen nummer je oplopend. Vervolgens maak je nog een extra coderingstabel aan, en daarin zet je pas wat iedere kolom voorstelt.
Probleem is natuurlijk dat je dan in de eerste tabel niet de juiste gegevenstypen hebt. Ik weet zelf niet precies hoe, maar er is ongetwijfeld iemand die je kan vertellen hoe je dit automatisch kunt wijzigen door het aanroepen van een functie.

Als je gata normaliseren dan kom je al snel tot de conclusie dat deze ozpetten alleen maar meer werk gaan opleveren. Afhankelijk van de kenmerk eigenschappen heb je een 1:n of n:m relatie. Daarnaast wil je snel meta dat kunnen toevoegen en ophalen. In dat geval zou ik uit gaan van vier tabellen:

- persoon
- persoon-kenmerk (koppel-tabel)
- kenmerk
- kenmerkgroep

In de tabel persoon kenmerk is een id/FK op genomen naar de persoon table en naar de kenmerk tabel. Verder heeft elk kenmerk een groep id/FK Hiermee kan je eindeloos zaken toevoegen aanpassen etc etc. Natuurlijk kan je minder of meer uitgebreid maken dan het nu is maar al met al is het dus een zeer flexibele oplossing die zeer goed te onderhouden is. Het aanmaken van extra tabellen en kolomen wil je eigenlijk niet maar das een persoonlijk mening. Maar als je het goed gaat uitwerken en normaliserten zal je op een soortgelijk systeem gaan uitkomen.

[Yoshi|IA2]

ripexx schreef op 01 september 2004 @ 13:20:

Als je gata normaliseren dan kom je al snel tot de conclusie dat deze ozpetten alleen maar meer werk gaan opleveren. Afhankelijk van de kenmerk eigenschappen heb je een 1:n of n:m relatie. Daarnaast wil je snel meta dat kunnen toevoegen en ophalen. In dat geval zou ik uit gaan van vier tabellen:

- persoon
- persoon-kenmerk (koppel-tabel)
- kenmerk
- kenmerkgroep

In de tabel persoon kenmerk is een id/FK op genomen naar de persoon table en naar de kenmerk tabel. Verder heeft elk kenmerk een groep id/FK Hiermee kan je eindeloos zaken toevoegen aanpassen etc etc. Natuurlijk kan je minder of meer uitgebreid maken dan het nu is maar al met al is het dus een zeer flexibele oplossing die zeer goed te onderhouden is. Het aanmaken van extra tabellen en kolomen wil je eigenlijk niet maar das een persoonlijk mening. Maar als je het goed gaat uitwerken en normaliserten zal je op een soortgelijk systeem gaan uitkomen.

tabel persoon:

code:

  id    |   persoon
----------------------
  1     |    jan
  2     |    jef

tabel persoon-kenmerk:

code:

  persoonid    |   kenmerkid
----------------------------------
         1     |    1
         1     |    2
         2     |    3
         2     |    4

tabel kenmerk:

code:

  kenmerkid  |   waarde
----------------------------------
       1     |    rood
       2     |    groen
       3     |    geel
       4     |    oranje

tabel kenmerkgroep

code:

  kenmerkid  |   groep
----------------------------------
       1     |    Kleur ogen
       2     |    Kleur haar
       3     |    Kleur ogen
       4     |    Kleur haar

Is dit wat je bedoelt?

[MisterData]

yoshi_rules schreef op 01 september 2004 @ 13:37:
[...]


tabel persoon:

code:

  id    |   persoon
----------------------
  1     |    jan
  2     |    jef

tabel persoon-kenmerk:

code:

  persoonid    |   kenmerkid
----------------------------------
         1     |    1
         1     |    2
         2     |    3
         2     |    4

tabel kenmerk:

code:

  kenmerkid  |   waarde
----------------------------------
       1     |    rood
       2     |    groen
       3     |    geel
       4     |    oranje

tabel kenmerkgroep

code:

  kenmerkid  |   groep
----------------------------------
       1     |    Kleur ogen
       2     |    Kleur haar
       3     |    Kleur ogen
       4     |    Kleur haar

Is dit wat je bedoelt?

Dat lijkt mij in iedergeval de meest logische oplossing

[ripexx]

Bijna,

Alleen ziet de tabel kenmerk er iets anders uit

code:

Kenmerken

id | kenmerkgroep_id | kenmerk
 1 |               1 |  groen
 2 |               1 |  blauw
 3 |               1 |  bruin
 4 |               2 |  bruin
 5 |               2 |  rood


Kenmerkgroepen

id | groep
 1 | kleur ogen
 2 | kleur haar

[Yoshi|IA2]

ripexx schreef op 01 september 2004 @ 13:56:
Bijna,

Alleen ziet de tabel kenmerk er iets anders uit

code:

Kenmerken

id | kenmerkgroep_id | kenmerk
 1 |               1 |  groen
 2 |               1 |  blauw
 3 |               1 |  bruin
 4 |               2 |  bruin
 5 |               2 |  rood


Kenmerkgroepen

id | groep
 1 | kleur ogen
 2 | kleur haar

Aaja, natuurlijk...

Dit is ook in principe de structuur die ik in gedachten had. Enkel zou ik de tabel persoon weglaten omdat dit eigenlijk maar een tabel is met alleen id's. (de naam die ik hierboven erbij zetten kan eigenlijk ook gewoon in de kenmerk tabel)

[Verwijderd]

ripexx schreef op 01 september 2004 @ 13:20:
...van vier tabellen:

- persoon
- persoon-kenmerk (koppel-tabel)
- kenmerk
- kenmerkgroep

waarom 4?

Kenmerk kan toch gewoon in de koppeltabel? Daar wil je toch je kenmerk koppelen aan een groep en persoon?

Dan houd je dus 3 tabellen over, of zie ik iets over het hoofd?

[ripexx]

Verwijderd schreef op 01 september 2004 @ 14:11:
[...]


waarom 4?

Kenmerk kan toch gewoon in de koppeltabel? Daar wil je toch je kenmerk koppelen aan een groep en persoon?

Dan houd je dus 3 tabellen over, of zie ik iets over het hoofd?

Je hebt kenmerken, kenmerkgroepen en personen. Daarnaast wil je de zaak koppelen. Welke manier je ook bedenkt ik kom toch echt op 4? Zoals gezegt ligt het een beetje aan je normalisatie proces en de gebruikte data, wensen en eisen. Pas dan kan je de exacte tabel definitie bepalen. Ik gaf alleen een voorbeeld.

[lier]

BoomSmurf schreef op 01 september 2004 @ 12:36:
[...]


Waariom zou je hierdoor een database misbruiken? Een database is om data bij te houden en hij houdt er data in bij... What's the problem?

LIER: Zonder de juiste context is het moeilijk om bij te dragen aan deze manier van ontwerpen. Waarom een database, hoeveel gegevens, hoeveel mutaties, welk front-end, hoeveel concurrent gebruikers, enz. Dit doet overigens niet af aan je "grappige" aanpak !

[...]

Dat kan op heel veel verschillende manieren. Of je maakt er een lelijke grid van, of je gaat dynamische db edit boxen aanmaken of iets, etc.

LIER: Oplossingen te over, helemaal mee eens.

[ Voor 3% gewijzigd door lier op 01-09-2004 14:21 ]

[Verwijderd]

ripexx schreef op 01 september 2004 @ 14:14:
[...]

Je hebt kenmerken, kenmerkgroepen en personen. Daarnaast wil je de zaak koppelen. Welke manier je ook bedenkt ik kom toch echt op 4? Zoals gezegt ligt het een beetje aan je normalisatie proces en de gebruikte data, wensen en eisen. Pas dan kan je de exacte tabel definitie bepalen. Ik gaf alleen een voorbeeld.

Ik zag alleen geen mogelijkheid om kenmerk te koppelen zonder naar groep en persoon te verwijzen. Dus dan zou je 2 koppel tabellen moeten krijgen.

Zonder een 2e koppeltabel zou ik dit krijgen:

[BoomSmurf]

lier schreef op 01 september 2004 @ 14:21:
LIER: Zonder de juiste context is het moeilijk om bij te dragen aan deze manier van ontwerpen. Waarom een database, hoeveel gegevens, hoeveel mutaties, welk front-end, hoeveel concurrent gebruikers, enz. Dit doet overigens niet af aan je "grappige" aanpak !

Ik volg even niet wat er "grappig" aan is. Of je bent denegrerend waarvoor ik je graag door verwijs naar de netiquette, of je vind iets grappig wat ik zo niet zie.

De TS zit met een probleem en vraagt hiervoor een oplossing, hij vraagt niet of we misschien na willen gaan of hij wel een database nodig heeft en geeft verder geen informatie over dingen als frequentie van mutaties. Verder doet de front-end er blijkbaar ook niet toe, anders had dit wel in de OP gestaan. Deze dingen laat ik dus allemaal buiten beschouwing en geef mijn mening puur over het gegeven probleem. Daar is weinig "grappigs" aan.

[Yoshi|IA2]

BoomSmurf schreef op 01 september 2004 @ 14:58:
[...]
De TS zit met een probleem en vraagt hiervoor een oplossing, hij vraagt niet of we misschien na willen gaan of hij wel een database nodig heeft en geeft verder geen informatie over dingen als frequentie van mutaties. Verder doet de front-end er blijkbaar ook niet toe, anders had dit wel in de OP gestaan. Deze dingen laat ik dus allemaal buiten beschouwing en geef mijn mening puur over het gegeven probleem. Daar is weinig "grappigs" aan.

Over het aantal mutaties heb ik zelf nog geen informatie, al zal de database zeker meer gequeried worden. Updates zullen bijna niet voorkomen, wel inserts. Maar hoe zich dat verhoud tot het aantal queries weet ik dus nog niet.

Front-end maakt in principe toch niet veel uit, niet?

[lier]

offtopic:
Grappig was niet grappig bedoeld. En zeker niet denigrerend...

Of het front end niets uit maakt, lijkt mij iets te voorbarig. Dit met name omdat hierin gedefinieerd wordt hoe de data getoond wordt (uit de database op halen, lukt "altijd" wel...)

De netste (naar mijn bescheiden mening) oplossing is twee extra tabellen, waarbij de een gebruikt wordt voor de koppeling en de ander gebruikt wordt voor het opslaan van de gegevens.

Normaliseren lijkt me in dit verhaal niet van toepassing. Je zou op z'n minst het aantal "voorkomens" moeten weten van de verschillende kenmerken en inzage hebben in het aantal gegevens, voordat je van normaliseren kan spreken !

[BoomSmurf]

yoshi_rules schreef op 01 september 2004 @ 15:07:
Over het aantal mutaties heb ik zelf nog geen informatie, al zal de database zeker meer gequeried worden. Updates zullen bijna niet voorkomen, wel inserts. Maar hoe zich dat verhoud tot het aantal queries weet ik dus nog niet.

De queries zelf zullen hoogstwaarschijnlijk ook niet de meeste tijd kosten. Zeker met een paar goed gelegde indexen niet. Je moet er wel rekening mee houden dat inserts wat langer zullen duren als de informatie over meerdere tabellen verspreid worden, maar je hoeft er echt geen kop koffie voor te gaan zetten Maar dit zal volgens mij meer zijn als je voor elk attribuut dynamisch een tabel in elkaar gaat zetten dan als je maar een paar voorgedifinieerde tabellen hebt waar je deze 'extra' informatie in kwijt kan.

Front-end maakt in principe toch niet veel uit, niet?

Als je dynamische velden hebt zul je altijd wat 'creatief' moeten coden, dus in principe maakt het voor de front-end idd ook niet zo heel veel uit hoe je dit precies in de database geimplementeerd hebt. Het probleem blijft hetzelfde, de implementatie 'achter de schermen' in de front-end veranderd misschien een beetje.

[Delphi32]

Ik ben toevallig zelf bezig met het bouwen van een applicatie waarin de gebruiker zelf zijn tabellen kan definiëren, en ik heb gekozen voor de volgende opzet (misschien heb je er wat aan):
- tabel MetaTable in de database met beschrijving van de tabellen in gebruikerstaal;
- tabel MetaField in database waarin alle velden beschreven staan: bij welke tabel ze horen, welk datatype ze hebben, join-informatie (om lookup combo's te faciliteren) en ook weer gebruikerstaal
- bij creëren van record in MetaTable wordt een tabel gecreëerd met de velden die de gebruiker erin wil hebben; info van de velden wordt opgeslagen in MetaField
- editen van MetaField levert dus intern altijd een ALTER TABLE op;
- grids worden automatisch van de gewenste kolommen voorzien
- edit forms worden automatisch opgebouwd
- een nieuw veld toevoegen levert me dus zonder 1 extra regel code een gewijzigd invoerscherm op

Ik heb gekozen voor het principe 'hou de db zo consistent mogelijk, laat de meta-info daar maar een afspiegeling van zijn' om ook andere applicaties van de database gebruik te kunnen laten maken. Bovendien vind ik het idee van een (of meer) algemene 'properties'-tabellen meestal minder geslaagd als er op het systeem queries uitgevoerd moeten worden die op meerdere attributen (properties) voorwaarden zetten.
Om het voorbeeld 'haarkleur' van hierboven aan te halen: dat wordt bij mij dus als volgt. Tabel Haarkleur eerst aanmaken, 1 veld genaamd Kleur (Id-veld wordt automatisch toegevoegd). Tabel Persoon aanmaken, veld Naam, en een veld Haarkleur (type Opzoekveld, bron tabel Haarkleur, displayveld Haarkleur.Kleur, joinveld Id). Dit laatste veld wordt in de db dan FKHaarkleur, met een keurige Foreign Key-constraint.

[klinz]

Delphi32 schreef op 01 september 2004 @ 23:46:
Ik heb gekozen voor het principe 'hou de db zo consistent mogelijk, laat de meta-info daar maar een afspiegeling van zijn' om ook andere applicaties van de database gebruik te kunnen laten maken.

[nofi]Dit lijkt in tegenspraak met het uitvoeren van ALTER TABLE door de applicatie. Hoe verklaar je dat?[/nofi]

[Delphi32]

klinz schreef op 02 september 2004 @ 00:01:
[nofi]Dit lijkt in tegenspraak met het uitvoeren van ALTER TABLE door de applicatie. Hoe verklaar je dat?[/nofi]

Misschien niet helemaal lekker geformuleerd, maar ik bedoel natuurlijk dat ik liever een ALTER TABLE uitvoer om een extra kolom toe te voegen, dan een extra record in een properties-tabel te inserten. Met de ALTER TABLE kan ik lekker gebruik maken van alle features die een DBMS me biedt: null/not null, default waardes, foreign keys etc. Allemaal zaken die in een property-structuur veel lastiger te realiseren zijn.
Consistent is dan ook niet 'nooit meer wijzigbaar', maar 'genormaliseerd' (zover de gebruiker dat zelf opgeeft uiteraard). Zo duidelijker?

[mocean]

Je kan een zogenaamd object georienteerde database gebruiken, zie hetvolgende plaatje:


Het systeem werkt met objecten die binnen het databasemodel zijn gedefinieerd. Elk object is van een bepaald objecttype. Objecttypes hebben een set eigenschappen die karakteristiek zijn voor het object. Voor de eigenschappen van een object gebruik ik zelf drie tabellen, voor de data Date/Char/Text.

Je definieert een set van 'propertytypes', elk van een datatype. Zo kan je verschillende objecten ook eenzelfde property geven. Een voorbeeld:

Je maakt devolgende propertytypes:
Naam (Char)
Omschrijving (Text)
Content (Text)
Geboortedatum (Date)
Sorteervolgorde (Char)
Voornaam (Char)

Nu kan je met deze set properties objecten gaan definieren, bijvoorbeeld:
Pagina (Naam / Omschrijving / Content / Sorteervolgorde)
Persoon (Naam / Voornaam / Geboortedatum)

etc. etc.

Op het Smarty forum heb ik eens een en ander uitgebreider uitgelegd:
http://www.phpinsider.com/smarty-forum/viewtopic.php?t=892

Binnen dit systeem kan je een beheertoepassing maken waarin je de definities van je objecten en dergelijke ook makkelijk aanpast. In het geval van een website kan je zo een dynamisch CMS maken dat voor alle (nieuwe) objecten ook werkt.

[ Voor 11% gewijzigd door mocean op 02-09-2004 00:37 ]

[mjax]

Je gaat hier vroeg of laat toch tegen problemen aan lopen. In principe wil je je applicatie van functionaliteiten voorzien waarmee de eindgebruiker zonder tussenkomst van een programmeur "maatwerk" aanpassingen kan doen.

Ik ben hier ook al in een grote applicatie twee jaar mee bezig (niet fulltime!) en alleen al het juist vastleggen van alle bij een veld horende controles is een crime.

Als iemand een veld toevoegt aan je applicatie, moet je moet rekening gaan houden met:

* attribuut constraints: bv. postcode moet aan een bepaalde formaat voldoen
* tupel constraints: bv. als het veld Is_Bedrijf==1 dan moet KvK nummer ingevuld worden
* tabel contraints: bv. een gebruikersnaam moet uniek binnen de tabel zijn
* database constraints: bv. foreign key relaties

Dat zijn natuurlijk pas de constraints en uiteindelijk voert een eindgebruiker meestal data op die op een of andere manier een afspiegeling van de business logica is. Stel nu dat een gebruiker een veld met de naam 'Gezondheid' wil toevoegen dat een berekend veld volgens een bepaalde logica op basis van leeftijd, gewicht en lengte. Hoe ga je dat aanpakken? Dit zijn nog maar eenvoudige voorbeelden.

Hoe langer je hier mee bezig bent, hoe meer je applicatie op een ontwikkelomgeving gaat lijken en dan ben je dus eigenlijk weer terug bij af. Mijn ervaringen zijn tot nu toe dan ook dat hoe flexibel je je applicatie ook op probeert te zetten, een klant/gebruiker weet altijd wel weer iets te verzinnen waar maatwerk voor noodzakelijk is.

[ Voor 4% gewijzigd door mjax op 02-09-2004 00:52 ]

[Verwijderd]

yoshi_rules schreef op 01 september 2004 @ 12:16:
Ik zou een database moeten opzetten die zeer flexibel is. Er zouden metadata van personen in komen te staan (leeftijd, gewicht, lengte, ...).

Ik heb de thread verder niet helemaal gelezen, maar even als purist: dit is geen metadata, dit is gewoon data.

Metadata zijn gegevens over gegevens.

[Yoshi|IA2]

Verwijderd schreef op 02 september 2004 @ 00:58:
[...]


Ik heb de thread verder niet helemaal gelezen, maar even als purist: dit is geen metadata, dit is gewoon data.

Metadata zijn gegevens over gegevens.

Ja, in principe wel.