[alg]database ontwerp voor personenbeheer

[djluc]

Ik ben bezig met het ontwerpen van een database waarin personen komen te staan. Dit wordt dus zoals je al merkt heel algemeen: personen. Het zijn dus geen gebruikers, werknemers of wat dan ook, maar dat kunnen ze wel worden.

Waar gaat het gebruikt worden: alles wat ik ga maken. Dit wordt namelijk een onderdeel van mijn soort van frameworkje waardoor ik het ontwikkelen van mijn applicaties wil versnellen.

Om maar even wat minder vaag te doen: ik heb 2 opzetjes bedacht:

code:

tabel people
-id
-name
-adress etc.

OF:

code:

tabel people
-id
-name

table people_properties
-id
-property_id
-people_id
-value //hier komt dus bijvoorbeeld het adres in te staan

table properties
-id
-name

Het voordeel van de 2de manier mag duidelijk zijn. Je kunt er zonder enige softwarematige aanpassingen eenvoudig andere gegevens in stoppen als je de applicatie op de juiste manier opzet.

Vervolgens ga ik nadenken over een groepen systeem e.d. maar ik wil eerst dit ontwerp helemaal ok maken.

[Creepy]

En je vraag is nu?

[slm]

En je vraag was?

Persoonlijk zou ik meer gaan voor optie 1. Het is simpel en overzichtelijk. Pas wanneer er een grote standaarddeviatie is tov de gebruikte velden in de verschillende apps is optie 2 interessant. Je mag/moet je afvragen in hoeverre die situatie zal gaan ontstaan.

Nou ben ik geen normaliseer held, maar ik vraag me toch af waarom je bij optie 2 de property "naam" toch in de tabel people hebt staan? Dat is toch ook gewoon een prop.?

[ Voor 3% gewijzigd door slm op 15-06-2004 17:17 ]

[djluc]

slm schreef op 15 juni 2004 @ 17:05:
En je vraag was?
Persoonlijk zou ik meer gaan voor optie 1. Het is simpel en overzichtelijk. Pas wanneer er een grote standaarddeviatie is tov de gebruikte velden in de verschillende apps is optie 2 interessant. Je mag/moet je afvragen in hoeverre die situatie zal gaan ontstaan.

Dat is inderdaad een interessant aspect. Ik ben echter tot de conclusie gekomen dat ik toch een soort van properties tabel nodig heb om daar meerdere emailadressen in kwijt te kunnen.

Nou ben ik geen normaliseer held, maar ik vraag me toch af waarom je bij optie 2 de property "naam" toch in de tabel people hebt staan? Dat is toch ook gewoon een prop.?

Anders heeft de ID in mijn ogen geen waarde meer, een tabel met alleen een id veld lijkt me vrij nutteloos. Misschien zou ik die tabel wel gewoon helemaal weg kunnen laten? Dan moet ik echter weer zelf iets bedenken om een unieke id te genereren.

Creepy schreef op 15 juni 2004 @ 17:01:
En je vraag is nu?

Niet zo flauw hè Creepy: er zijn 2 mogelijkheden met elk voor en nadelen. De vraag is dus welke te kiezen voor het geval je het echt niet begrepen had

[ Voor 13% gewijzigd door djluc op 15-06-2004 17:24 ]

[Creepy]

djluc schreef op 15 juni 2004 @ 17:23:
[...]
Niet zo flauw hè Creepy: er zijn 2 mogelijkheden met elk voor en nadelen. De vraag is dus welke te kiezen voor het geval je het echt niet begrepen had

Anyway. Als je van te voren niet weet wat je aan properties gaat krijgen, en deze on the fly wilt toevoegen dan zou ik zeker voor optie 2 gaan.
Nadelen? "Complexere" queries. Maar dat weegt niet op tegen de flexibiliteit die je nu hebt.

Oplossing 1 zou ik alleen kiezen als je zeker weetdat er nagenoeg niks aan je datamodel gaat veranderen. Maar aangezien je met een framework voor personen bezig bent ...

[slm]

Misschien een DNA-veldje?

Voor verschillende email velden kan je ook email1, email2, email3 velden verzinnen in optie 1. Als dat het enige is iig. Als je een stuk meer van dat soort properties hebt, is optie 2 idd beter anders zit je met bijzonder veel overhead.

Ik moet je zeggen dat ik die opzet van jou zelf ook eens in eerste instantie had bedacht maar er later niet meer uitkwam. Kan natuurlijk komen omdat mijn kennis niet zo ver reikt, maar wat ik me er van kan herinneren is met name een probleem met het value gedeelte.
Een tabel met property names is namelijk erg logisch, maar de waardes? Waar en hoe sla je die op? Intvals? Strings? Reals? etc etc? Hoe ga je daarmee om? Alles in een varchar veldje?

Edit:
Ander probleem waren de queries. Ik kwam niet verder dan queries die alle props met waardes voor 1 persoon weergaf. Voor een lijstvorm, dus voor meerdere personen zou ik dan steeds een aparte query moeten uitvoeren per persoon.

[ Voor 15% gewijzigd door slm op 15-06-2004 17:40 ]

[djluc]

slm schreef op 15 juni 2004 @ 17:33:
Misschien een DNA-veldje?

Dat mag de klant inderdaad zelf aanmaken

Voor verschillende email velden kan je ook email1, email2, email3 velden verzinnen in optie 1. Als dat het enige is iig. Als je een stuk meer van dat soort properties hebt, is optie 2 idd beter anders zit je met bijzonder veel overhead.

Dat mag dus inderdaad niet volgens de normalisatie regels. Verder heb je dan alsnog een beperkt aantal email adressen wat dus niet de bedoeling is.

Ik moet je zeggen dat ik die opzet van jou [...]Een tabel met property names is namelijk erg logisch, maar de waardes? Waar en hoe sla je die op? Intvals? Strings? Reals? etc etc? Hoe ga je daarmee om? Alles in een varchar veldje?

Varchar lijkt me inderdaad de beste optie. Verder hoeven er geen sorteeracties op uitgevoerd te worden dus het is dus niet echt belangrijk dat ik ze opsla in een veld met het juiste type.

Ander probleem waren de queries. Ik kwam niet verder dan queries die alle props met waardes voor 1 persoon weergaf. Voor een lijstvorm, dus voor meerdere personen zou ik dan steeds een aparte query moeten uitvoeren per persoon.

Als je kennis iets verder reikt kom je er achter dat je dat mooi met joins op kunt lossen

[slm]

djluc schreef op 15 juni 2004 @ 17:54:
Dat mag dus inderdaad niet volgens de normalisatie regels. Verder heb je dan alsnog een beperkt aantal email adressen wat dus niet de bedoeling is.
[...]
Varchar lijkt me inderdaad de beste optie. Verder hoeven er geen sorteeracties op uitgevoerd te worden dus het is dus niet echt belangrijk dat ik ze opsla in een veld met het juiste type.

Zijn er geen regels dat je het veldtype moet gebruiken wat zo veel mogelijk met de data overeenkomt? Geen idee, maar ik kan me zo voorstellen van wel. In ieder geval - ook al heb je geen sorteeracties in de props. - is het wél lastig als je gaat joinen met die props. Stel bv iets heel simpels als een Land-prop. Is het niet inefficient als er gejoined wordt dmv id's die varchar velden zijn als terwijl eigenlijk int velden zouden moeten zijn?

[...]
Als je kennis iets verder reikt kom je er achter dat je dat mooi met joins op kunt lossen :)[/quote]
Hah Nou ik ben benieuwd. Het is alweer een paar maandjes geleden, maar ik kwam er inderdaad niet uit, dus geef eens een voorbeeld als je wilt van zo'n query (en dan zonder subqueries svp). Misschien dat ik na deze topic dan ook weer besluit iets dergelijks op te zetten (maar dan voor producten ipv personen).

[JaQ]

Naar mijn smaak is optie twee veel beter, maar de complexiteit van de queries gaat enorm omhoog (vooral in dat flat filesystem dat zich database noemt) en de performance wordt veel minder. Maar begin je niet op een te laat punt?

Een eerste relevante vraag is eigenlijk: welke database wil je gaan gebruiken? Doe eens gek en gebruik eens wat anders dan de (redelijk) standaard MySql. Er is namelijk echt een goede reden waarom directories meestal in LDAP zitten (Oracle Internet Directory, Novell E-Directory, MicroSoft Active Directory etc.)

[tijn]

djluc schreef op 15 juni 2004 @ 17:54:
[...over queries...]
Als je kennis iets verder reikt kom je er achter dat je dat mooi met joins op kunt lossen

Zo simpel ligt het denk ik niet. Wat nou als je een resultset van personen wilt hebben met de properties als kolommen (vroeg of laat heb je het gewoon nodig)? Dit is niet met 1 gangbaar SQL statement te querien, alleen met een kruistabel-achtige functionaliteit.

[JaQ]

tijn schreef op 15 juni 2004 @ 18:31:
[...]

Zo simpel ligt het denk ik niet. Wat nou als je een resultset van personen wilt hebben met de properties als kolommen (vroeg of laat heb je het gewoon nodig)? Dit is niet met 1 gangbaar SQL statement te querien, alleen met een kruistabel-achtige functionaliteit.

zegt connect by prior je iets? (of is Oracle geen geldig rdbms in dit geval )

[tijn]

DrFrankenstoner schreef op 15 juni 2004 @ 18:47:
[...]


zegt connect by prior je iets? (of is Oracle geen geldig rdbms in dit geval )

Dat zet ik, gangbaar SQL statement . Veel RDBMS-en hebben wel een of andere uitbreiding om dit wat makkelijker te maken, maar ze doen het allemaal weer anders en op een of andere manier heb ik het gevoel dat TS met MySQL aan de gang wil .
Die opmerking over LDAP is trouwens wel een goede voor dit soort situaties.

[ Voor 18% gewijzigd door tijn op 15-06-2004 18:56 ]

[djluc]

Over LDAP heb ik inderdaad ook gedacht. Mijn motivatie om de gegevens in een database te bewaren: eenvoud van installatie en configuratie op locatie. Ik ben op dit moment al zo ver dat ik module ondersteuning in het systeem heb ingebouwd, inclusief een compleet installatie systeem. Compleet met installatie wizzards e.d. Ik kan als ik met een normale DB werk het bestaande module en update systeem gebruiken, wat voor mij een belangrijke reden is. Ik mag namelijk niet zomaar ergens een LDAP server maken. Eventueel kan ik later een module maken die via een cronjobje een LDAP server op basis van de database up-to-date houdt.

props. - is het wél lastig als je gaat joinen met die props. Stel bv iets heel simpels als een Land-prop. Is het niet inefficient als er gejoined wordt dmv id's die varchar velden zijn als terwijl eigenlijk int velden zouden moeten zijn?

Dit is een interessant iets. Ik bedoelde met eenvoudig joinen meer eenvoudige zaken als een adres veld. Dat heeft een relatie met de persoon en met de property. Een land heeft echter ook nog een relatie met een landen tabel. Daar ga ik even over nadenken.

[djluc]

Ik heb een klein aantal voorbeelden opgeschreven die voor zouden kunnen komen. Verder heb ik bedacht dat het misschien handig is om naast mensen ook bedrijven en groepen te mixen in de tabel. Hiervoor had ik o.a. als argumenten het volgende bedacht:
• een bedrijf kan ook specifieke properties hebben
• een groot deel van de prorties komen overeen(adres/tel nummer/fax nummer komen ook mogelijk bij een persoon voor)

Verder kan ik dan door eenvoudigweg een veldje parentid toe te voegen meteen de mensen onder groepen hangen. Hierdoor kan ik met een betrekkelijk eenvoudige query alle gegeven op de juiste manier uitlezen en ben ik enorm flexibel door de object-achtige tree structuur.

Het grote probleem is het feit dat ik geen flauw idee heb wat er later nog allemaal bij komt. Er werd bijvoorbeeld een DNA veld als voorbeeld aagehaald Als een klant dergelijke info wil opslaan moet dat mogelijk zijn. Daarom is een properties opzet sowieso niet te vermijden heb ik het idee.

Om standaard in de people tabel al enkele basiseigenschappen op te nemen zie ik eerlijk gezegd ook niet zitten. Dan krijg ik allerlei verschillende methoden voor het ophalen van de gegevens. Eventueel is een username nog wel geschikt om in die tabel te zetten.

[Verwijderd]

Ik zou zeker voor een heldere genormaliseerde (waar praktisch) oplossing gaan en die propertybende achterwege laten.

1. je hebt nu al problemen (no offense) met de juiste queries te schrijven,
laat staan als je kweeniehoeveel properties hebt (die straks ook weer properties hebben ? ).

2. ik voorspel dat je op een bepaald moment toch niet onder het hardcoden uitkomt (stel dat je ergens in een rapportje of zo alleen de adresproperties moet hebben ? of op je scherm bepaalde properties bij elkaar wil tonen ?

3. KIS -> Keep It Simple. bedenk toch van te voren maar wat je wil opnemen in je database en maak bv. als er een oneindig aantal emailadressen moeten worden opgegeven gewoon een emailtabel met foreignkey naar je peopletabel. ik denk dat zo je slaagkans hoger wordt IMHO....

maarrrr : goed bezig !


oh ja, connect by prior is om een boomstructuur te querien, afaik niet om rijen als kolommen weer te geven...

[djluc]

Verwijderd schreef op 16 juni 2004 @ 17:29:Ik zou zeker voor een heldere genormaliseerde (waar praktisch) oplossing gaan en die propertybende achterwege laten.

Helder normaliseren is imo helaas niet een tabel met een groot aantal properties, waar je een kolommetje toeveogt als je weer eens een veldje extra wilt hebben.

1. je hebt nu al problemen (no offense) met de juiste queries te schrijven,
laat staan als je kweeniehoeveel properties hebt (die straks ook weer properties hebben ? ).

In een goed genormaliseerd systeem maakt het aantal properties niets uit. Properties van properties zou eventueel zelfs mogelijk zijn, maar dan moet je gaan werken met een treevorm binnen de properties. Erg leuke amterie. Daar ga ik nog even naar kijken maar volgens mij levert dat meer overhead dan voordeel op. Ik kan geen realistisch voorbeeld bedenken namelijk.

2. ik voorspel dat je op een bepaald moment toch niet onder het hardcoden uitkomt (stel dat je ergens in een rapportje of zo alleen de adresproperties moet hebben ? of op je scherm bepaalde properties bij elkaar wil tonen?

Met een fatsoenlijke interface in je rapporten module is het toch geen probleem om de juiste properties die je wilt tonen uit een lijstje te selecteren? Of zie jij nog andere problemen?

3. KIS -> Keep It Simple. bedenk toch van te voren maar wat je wil opnemen in je database en maak bv. als er een oneindig aantal emailadressen moeten worden opgegeven gewoon een emailtabel met foreignkey naar je peopletabel. ik denk dat zo je slaagkans hoger wordt IMHO....

Weet je: het wordt een framework. Ik denk dat je om een slagingskans te kunnen bepalen eerst een doel moet hebben. Het probleem wat ik heb is dat ik niet precies weet wat ik in de toekomst op dat framework ga bouwen. Dus ik kan ook nog niet precies zeggen welke gegevens ik wil saven.

[zneek]

Hoe wil je in situatie 2 gegevens validatie gaan doen? Dan moet je al datatypen gaan toevoegen aan properties oid. Maar hoe krijg je die in die people_properties tabel? Stel ik wil een property geboortedatum, postcode en meisjesnaam toevoegen. Dat kun je toch moeilijk allemaal in 1 generiek veld gooien. En hoe vang je bij het toevoegen van een persoon invoer fouten af?

Misschien is de algemene vraag die je moet stellen: zijn er eigenschappen van personen die later toegevoegd moeten worden? Of zijn dat misschien eerder gerelateerde gegevens, die op zich niet in de tabel persoon horen. Als ik zo naar dit datamodel kijk kun je de tabellen net zo goed table, tablecolumn en column noemen, en kun je alles er in kwijt.

Misschien moet je je framework niet zo db afhankelijk maken. Kun je met een O/R mapper niet het gewenste resultaat bereiken?

[djluc]

zneek schreef op 16 juni 2004 @ 19:54:
Hoe wil je in situatie 2 gegevens validatie gaan doen? Dan moet je al datatypen gaan toevoegen aan properties oid. Maar hoe krijg je die in die people_properties tabel?

Het geaccepteerde van een property is inderdaad te controleren door bijvoorbeeld een kolom datatype in de propertytabel. Als daar bijvoorbeeld date staat kan je controleren of het ook daadwerkelijk een datum is.

Misschien is de algemene vraag die je moet stellen: zijn er eigenschappen van personen die later toegevoegd moeten worden? Of zijn dat misschien eerder gerelateerde gegevens, die op zich niet in de tabel persoon horen. Als ik zo naar dit datamodel kijk kun je de tabellen net zo goed table, tablecolumn en column noemen, en kun je alles er in kwijt.

Neem bijvoorbeeld een extreem voorbeeld: die van het DNA. Ik zie het dus zeker niet al onmogelijk. De vraag is natuurlijk: wat is de effectiefste oplossing? Het ontwikkelen kost meer tijd maar het latere uitbreiden is enorm eenvoudig. Ik maak als ik opzet 2 kies een soort van admin waarmee ik de properies kan editten en dan heb ik een enorm flexibel systeem. Ik ben bezig om te kijken wat er redelijkerwijs allemaal toegevoegd kan worden aan een persoonsobject.

Misschien moet je je framework niet zo db afhankelijk maken. Kun je met een O/R mapper niet het gewenste resultaat bereiken?

Wat is een O/R mapper? Is dat zo'n opzet waarbij je objecten in een database op gaat slaan?

[zneek]

djluc schreef op 16 juni 2004 @ 20:05:
Wat is een O/R mapper? Is dat zo'n opzet waarbij je objecten in een database op gaat slaan?

O/R mappers zijn er in verschillende uitvoeringen. In het ideale geval verzorgt een O/R mapper een mapping tussen Objecten en een Relationele database, waarbij je .

Ik gebruik zelf EJB CMP, niet helemaal O/R mapper (veel meer) maar principe is grotendeels hetzelfde. Ik maak een objectdefinitie met alle eigenschappen die ik nodig heb, inclusief relaties naar andere objecten. De J2EE server verzorgt de persistentie en verdere vertaling naar de (instelbare) database.

Zoek maar eens op SourceForge naar Hibernate. Als ik me niet vergis is die er voor Java en voor .Net. Wij hebben zelf al eens een projectje gedaan in .Net met LLBLGen, een O/R mapper door een Nederlander gemaakt (die je ook in person kunt mailen met vragen)

[JaQ]

zneek schreef op 16 juni 2004 @ 19:54:
Hoe wil je in situatie 2 gegevens validatie gaan doen? Dan moet je al datatypen gaan toevoegen aan properties oid. Maar hoe krijg je die in die people_properties tabel? Stel ik wil een property geboortedatum, postcode en meisjesnaam toevoegen. Dat kun je toch moeilijk allemaal in 1 generiek veld gooien. En hoe vang je bij het toevoegen van een persoon invoer fouten af?

Juist in het geval van een framework is dat dus goed mogelijk. Ik heb ooit eens een formbuilder gebouwd in php. Als ik dat datamodel grofweg zou vertalen naar deze situatie zou je dit krijgen:

code:

object 1--N object_properties N--1 properties 1--N property_validations 

property_validations  N--1 validations N--1 program_languages

(even geknipt voor de layout)

Hierbij is het dus mogelijk om validaties te bepalen voor properties in verschillende talen (php, js, pl/sql, whatever), verschillende validaties aan een property te hangen en een object met meerdere properties uit te rusten.

Uiteraard worden je queries er niet makkelijker op (je logica ook niet trouwens), maar uiteindelijk zal het resultaat prima zijn.

offtopic:
connect by prior is in dit geval perfect, want eigenlijk maak je een boom (of eigenlijk een graaf) en daarvoor moet je altijd eerst een parent weten, maar misschien zie ik dat helemaal verkeerd

[djluc]

Dus even concreet: het heeft zeker voordelen aangezien je flexibeler bent. Mogelijke prolemen die we tot nu toe gevonden hebben zijn allen netjes op te lossen. Zij eht met wat extra werk, maar dat is iets wat niet ernstig is. Het gaat er om dat er een solide basis ontstaat waarop verder gebouwt kan worden.

[Verwijderd]

Ik zou, als ik jou was, niet uitgaan van een database ontwerp maar van een Object model. Je zou het boek van Fowler : Analysis Patterns: Reusable Object Models eens door moeten lezen. Daar staat een hoofdstuk in over het modeleren van organizaties. Hij abstraheerd de entiteit persoon nog verder.
Als je je object model goed hebt, dan ga je nadenken over het mappen van het object model naar een relationeel model. En hier kun je dan een OR mapper voor gebruiken (als je wilt) of zelf de persistence layer schrijven.

[djluc]

Verwijderd schreef op 17 juni 2004 @ 11:10:
Ik zou, als ik jou was, niet uitgaan van een database ontwerp maar van een Object model. Je zou het boek van Fowler : Analysis Patterns: Reusable Object Models eens door moeten lezen. Daar staat een hoofdstuk in over het modeleren van organizaties. Hij abstraheerd de entiteit persoon nog verder.
Als je je object model goed hebt, dan ga je nadenken over het mappen van het object model naar een relationeel model. En hier kun je dan een OR mapper voor gebruiken (als je wilt) of zelf de persistence layer schrijven.

Bedankt voor die tip voor dat boek! Ik zal eens op internet gaan kijken wat er allemaal mogelijk is met zo'n OR mapper. Ook zal ik eens kijken of dit in PHP wel een beetje fatsoenlijk te realiseren is. Als ik zo'n OR mapper gebruik kan ik dit natuurlijk voor meerdere dingen gebruiken. * djluc denk weer aan het topic over een systeemopzet met maar 1 tabel

[zneek]

djluc schreef op 17 juni 2004 @ 14:20:
[...]
Bedankt voor die tip voor dat boek! Ik zal eens op internet gaan kijken wat er allemaal mogelijk is met zo'n OR mapper. Ook zal ik eens kijken of dit in PHP wel een beetje fatsoenlijk te realiseren is. Als ik zo'n OR mapper gebruik kan ik dit natuurlijk voor meerdere dingen gebruiken. * djluc denk weer aan het topic over een systeemopzet met maar 1 tabel

Let wel op. Er zit verschil tussen de opzet zoals je hem voorstelde in je TS en het gebruik van een OR mapper. Met een OR mapper kun je makkelijker onderhoud doen en je systeem uitbreiden. In jouw opzet zou je zonder te programmeren je systeem uit kunnen breiden.

[Delphi32]

Ik loop ook al langer met een dergelijk probleem rond; dit topic heeft me ertoe gebracht om mn gedachten uit te werken en als een soort proof of concept te gaan implementeren. Laat ik mn overwegingen en keuzes maar hier neerzetten, misschien heeft TS er ook wat aan Misschien probeer ik gewoon het wiel opnieuw uit te vinden (dan hoor ik dat graag), maar ik trek me op aan de gedachte dat ik dan tenminste in staat blijk om het wiel überhaupt uit te vinden
De twee opties die genoemd zijn (tabellen netjes normaliseren versus 1 grote 'properties'-tabel) vind ik allebei niet kunnen. De eerste levert mij teveel starheid en daarmee een onderhoudsnachtmerrie op (om van de gebruiker nog maar te zwijgen), de tweede queries die me veel te ingewikkeld worden. Ik wil een tussenvorm, die van beide opties de sterke punten meeneemt. Die realiseer ik als volgt: mn database heeft 2 tabellen, MetaTable en MetaField. Beide beschrijven de 'brug' tussen wat de gebruiker ziet en hoe de tabellen in de database geïmplementeerd worden. Nieuwe tabel erbij = nieuw record in MetaTable aanmaken (met evt wat records in MetaFields erbij, maar dat mag ook later), app detecteert dat er een nieuw record in MetaTable gemaakt is en maakt automatisch de fysieke tabel aan met een auto-generated Id primary key field. Nieuw veld erbij = nieuw record in MetaField, app detecteert een veld dat nog niet in de database zit, dus doet een Alter Table op de table om het nieuwe veld toe te voegen.

Zo heb ik dus altijd een beschrijvend model van mijn database, dat ik kan gebruiken om menu's en schermen op te bouwen, en bied ik de gebruiker de mogelijkheid om die gegevens bij te houden die voor hem van belang zijn.

Ik zie nog mogelijkheden om dit framework uit te breiden: velden met FK naar andere tabellen zijn mogelijk, ondersteuning voor user-defined views is haalbaar en ik denk ook nog na over een algemeen rechten-systeem. Ook database-onafhankelijk werken is een optie, maar voorlopig richt ik me op de implementatie van het tabel-field-systeem. En al wordt dit misschien niet dé app die je bij al je gebruikers neer zal willen zetten, het gaat voor mij een handige tool worden om snel applicaties in elkaar te zetten.

[slm]

Delphi32 schreef op 18 juni 2004 @ 00:51:
mn database heeft 2 tabellen, MetaTable en MetaField. Beide beschrijven de 'brug' tussen wat de gebruiker ziet en hoe de tabellen in de database geïmplementeerd worden. Nieuwe tabel erbij = nieuw record in MetaTable aanmaken (met evt wat records in MetaFields erbij, maar dat mag ook later), app detecteert dat er een nieuw record in MetaTable gemaakt is en maakt automatisch de fysieke tabel aan met een auto-generated Id primary key field. Nieuw veld erbij = nieuw record in MetaField, app detecteert een veld dat nog niet in de database zit, dus doet een Alter Table op de table om het nieuwe veld toe te voegen.

Nadeel hierbij lijkt me het gebruik van Joins, tenzij je alles in 1 tabel zet en dan is je normalisatie ook weer verdwenen. Een extra MetaJoins tabel zou dan misschien wel uitkomst bieden.

[Delphi32]

Goed punt; ben ik nog niet over uitgedacht (ik wil eerst de basis goed krijgen) maar ik zie wel mogelijkheden. De 'truc' is dat ik begin met het extracten van de metadata uit de database zelf. Door te analyseren hoe de database in elkaar zit, kan ik bepalen hoe de applicatie moet werken.
Voor 1:n-tabellen kan het handig zijn om de relatie te cachen in een MetaJoin tabel, ja. Voor zover ik nu kan overzien is dat in principe niet nodig (de info zit immers al in de database).

[slm]

Hoe ga je dan om met het snelheidsverlies dat optreed bij het analyseren zonder een jointabel te gebruiken?

Ik gebruik een join-tabel en een specialfields-tabel voor een databasemodule die zich aanpast aan wat voor tabellen je ook in je database hebt staan (een soort van phpmyadmin voor eindgebruikers). Aangezien de relaties in de database ingevoerd kunnen worden, valt het qua snelheidsverlies wel mee.

[kasper_vk]

Als ik de opzet van Delphi32 lees, dan denk ik: een DBMS slaat z'n meta-info toch al op in dergelijke tabellen?
Is het voor dit probleem dan misschien zinvol (en mogelijk?) om de 'echte' meta-tabellen van de database te gebruiken op de manier die Delphi32 beschrijft?

Daarnaast: heeft de TS al een hibride oplossing overwogen:

• heel gangbare properties (naam, geboortedatum, enz) als normale tabelvelden
• meer toepassingsspecifieke velden (DNA, verzekeringsnummer, weetikhetwatvoorexotischveld) volgens zo'n property constructie?

Voor 'gangbare' properties als e-mail adressen, telefoonnummer, e.d. waarvan je er dus meerdere hebt, is het dan wel raadzaam om netjes te normaliseren.
Dus aparte tabellen voor mailadressen en telefoonnummers te maken, die dan zwak zijn t.o.v. de tabel persoon. Dit in plaats van velden als email1, email2, enz waar mijn hart meestal van overslaat

[ Voor 7% gewijzigd door kasper_vk op 18-06-2004 11:39 ]

[slm]

Hij had al daarover iets gezegd:

djluc schreef op 16 juni 2004 @ 16:30:
[...]
Om standaard in de people tabel al enkele basiseigenschappen op te nemen zie ik eerlijk gezegd ook niet zitten. Dan krijg ik allerlei verschillende methoden voor het ophalen van de gegevens. Eventueel is een username nog wel geschikt om in die tabel te zetten.

Het is overigens niet goed voor je gezondheid als je hart te vaak overslaat van dat soort dingen. Regels zijn er om met voeten te betreden

[ Voor 4% gewijzigd door slm op 18-06-2004 11:57 ]

[kasper_vk]

Is ook zo, maar dat staat wel verstandig Wanneer iets herbruikbaar / echt serieus wilt maken, is verstandig zijn toch belangrijker dan gemak .
Verder had ik daar dus overheen gelezen.

En die meta-info optie (Delphi32-manier of DBMS-tabellen)? Die klinkt dan nog wel errug zinvol.

EDIT:
Daarbij denk ik nogsteeds wel dat een hybride oplossing een groot voordeel biedt: geen ingewikkelde query's voor al die standaardvelden. Dan kun je die standaarddingen met het framework al direct gebruiken en kun je je dus direct op de interessante, toepassingsspecifieke dingen storten. En dat lijkt me juist het doel van een framework, niet?
En met een klein beetje infromatica inzicht (of documentatie ) snapt hij of een ander later ook wel dat er dus 2 manieren toegepast worden, om een best-of-both situatie te bereiken.

[ Voor 70% gewijzigd door kasper_vk op 18-06-2004 12:22 ]

[Delphi32]

Die meta-data zit idd al in de database. Wil ik echter ondersteuning bieden voor velden die er voor de gebruiker een naam hebben als '% omzet vorig jaar', of een veldnaam die een reserved word is, dan moet ik een conversiemethode bedenken tussen 'user-name' van de tabel/field en de database-name (de werkelijke dus) van tabel/field. Daarom kom ik met de RDBMS-metadata niet uit.

[kasper_vk]

Ah, natuurlijk.
Dat brengt gelijk ook de mogelijkheid mee om b.v. internationalisatie te realiseren, zonder de feitelijk DB-structuur aan te hoeven raken. Handig!

[JaQ]

Delphi32 schreef op 18 juni 2004 @ 00:51:
een heleboel tekst die een datadictonary, of eigenlijk de werking van een database

Ik vind het erg stoer van je dat je je eigen datadictiornary wilt maken (of beter nog: je eigen database), maar om nou een "nieuw" (R)DBMS in een (R)DBMS te maken vind ik persoonlijk een beetje jammer. Ik denk dus dat je een beetje je doel aan het voorbijschieten bent.

Mocht je nou toch dit alles willen gaan maken, denk dan eens aan dingen als:
- een procedurele taal
- foreign keys
- referenciele integriteit
( en zo nog een lijstje, zoek maar eens naar de sig. van ACM en pak het lijstje gebreken aan mysql, dan ben je er bijna )

uiteraard zijn dit alleen mijn 0.02 en NOFI

[edit: toevoeging] kijk eens naar dingen als EULA (end user abstraction layer), aliasen en views als je tijd over hebt... [/edit]

[ Voor 9% gewijzigd door JaQ op 18-06-2004 13:57 ]

[Delphi32]

DrFrankenstoner schreef op 18 juni 2004 @ 13:55:
[...]
- een procedurele taal
- foreign keys
- referenciele integriteit
kijk eens naar dingen als EULA (end user abstraction layer), aliasen en views als je tijd over hebt...

Bedankt voor je toevoeging End User Abstraction Layer klinkt behoorlijk naar wat ik wil hebben ja, ga ik zeker nader onderzoeken. FKs en referentiële integriteit stonden (uiteraard) al op mijn lijstje. Kan je me kort uitleggen wat je in dit verband met procedurele taal bedoelt, en waarom ik daar over na moet denken?
Overigens gaat dit projectje (hobby) natuurlijk veel verder dan alleen een data dictionary. Mijn doel is om uiteindelijk functionaliteit aan de applicatie te hangen die tot op een behoorlijk niveau los staat van de achterliggende database. Dat moet mijn ontwikkelsnelheid drastisch kunnen verhogen namelijk. Mocht dat niet lukken, dan heb ik altijd nog een fijn werkende database editor gemaakt

[JaQ]

Delphi32 schreef op 19 juni 2004 @ 00:14:
[...]

Bedankt voor je toevoeging End User Abstraction Layer klinkt behoorlijk naar wat ik wil hebben ja, ga ik zeker nader onderzoeken. FKs en referentiële integriteit stonden (uiteraard) al op mijn lijstje. Kan je me kort uitleggen wat je in dit verband met procedurele taal bedoelt, en waarom ik daar over na moet denken?
Overigens gaat dit projectje (hobby) natuurlijk veel verder dan alleen een data dictionary. Mijn doel is om uiteindelijk functionaliteit aan de applicatie te hangen die tot op een behoorlijk niveau los staat van de achterliggende database. Dat moet mijn ontwikkelsnelheid drastisch kunnen verhogen namelijk. Mocht dat niet lukken, dan heb ik altijd nog een fijn werkende database editor gemaakt

Een end user abstaction layer (EULA dus) is een laag van voorgedefinieerde views/queries waarmee de "gebruikers" zelf eenvoudig rapportages etc. kunnen maken (de bloksteentjes zijn er, enkel combineren). Als je er echt eens leuk naar wilt kijken, kijk dan eens naar oracle discoverer. Dat paket werkt op die manier (je definieerd dus tabellen, keys etc allemaal voor, of beter gezegt: je neemt ze over uit de database, en "sleept" een rapport in elkaar, a la excell).

Wat ik bedoel met een procedurele taal in dit geval: Als je "dynamisch" tabellen en attributen kan aanmaken, is het ook wel prettig als je die kan validaren (of op bepaalde events een trigger af te laten gaan). b.v. dus een check of een geboortedatum wel geldig is etc. etc. De events/triggers ken je ongetwijfeld al uit gui gebruik (als er op een button geklikt wordt dan moet je bla bla bla doen). Dat kan je dus ook on-insert, on-update etc. etc. doen. postgresql heeft een redelijk uitgebreide procedurele taal (of eigenlijk meerdere talen, maar dat even terzijde), net zoals oracle, ms-sql, firebird (informix). etc.

Toch denk ik zelf dat je beter de datadictionary van de door jou gekozen database kan gaan gebruiken. Ik heb in ieder geval zelf niet de ilusie dat ik een beter rdbms kan maken door een eigen database engine te schrijven in datzelfde rdbms. Maar misschien ben ik daar ook wel niet goed genoeg voor of zo...

[Olaf van der Spek]

djluc schreef op 15 juni 2004 @ 16:55:
Het voordeel van de 2de manier mag duidelijk zijn. Je kunt er zonder enige softwarematige aanpassingen eenvoudig andere gegevens in stoppen als je de applicatie op de juiste manier opzet.

Geldt hetzelfde niet voor manier 1 (met misschien de toevoeging van een meta-data tabel zodat de code de structuur van die tabel begrijpt)?

djluc schreef op 16 juni 2004 @ 16:30:
Verder kan ik dan door eenvoudigweg een veldje parentid toe te voegen meteen de mensen onder groepen hangen. Hierdoor kan ik met een betrekkelijk eenvoudige query alle gegeven op de juiste manier uitlezen en ben ik enorm flexibel door de object-achtige tree structuur.

Maar je bent beperkt tot een parent.

DrFrankenstoner schreef op 19 juni 2004 @ 04:13:
Een end user abstaction layer (EULA dus)

End User Layer d'Abstraction?
Of EUAL?

Edit: Misschien had ik eerst even verder moeten lezen ....

[ Voor 50% gewijzigd door Olaf van der Spek op 19-06-2004 12:15 ]