[Database] Nieuw model, c&c gevraagd

[MicroWhale]

Ik ben bezig met het ontwerp van een soort database model, gebaseerd op enkele van de functionaliteiten van het menselijk brein. Het lijkt erg op een Network Model met maar één record structure en het is ook te vergelijken met het in de link beschreven Father of all models.

Op deze pagina staat uitgelegd wat ik bedoel. Het lijkt me niet verstandig het hele verhaal te posten, omdat het nogal een lap tekst is. Vandaar alleen de volgende quote met de essentie van het model, waarvan de werktitel "BubbleBase" is, in regels:

BubbleBase (= a Bubble-based Database System, it’s a working title):
1. Access
1.1. All concepts are immediately accessible by the user as a whole,
1.2. Concepts are more slowly accessible by searching "part-of-a-concept"
2. Storage of concepts is virtually unlimited,
3. All concepts can be linked to all other concepts,
4.1. Two Concepts are linked by another concept which states low-level context,
4.2. The model in the database is defined entirely in Concepts,
5. Database input is not bound to restrictions,
6. All single concepts are equally important.

Notes:
- Rule 5 can be dropped to create strong-linked models of a more relational type
- Rule 6 can be dropped to simulate "remembering", "forgetting".

Ik zie niet graag dingen (vooral: belangrijke dingen) over het hoofd, dus als je comments en critics hebt, zijn deze van harte welkom. Ik ben benieuwd wat jullie ervan vinden.

[RobIII]

Ik vind het maar een abstract verhaal. Ja, je zou vanalles in die "Father of all models" DB kunnen gooien. En die BubbleBase is...mja... leuk. Ook lekker abstract. Het hele verhaal zegt eigenlijk maar weinig. Of het (in de praktijk) bruikbaar is voor jouw applicatie kan jij alleen bepalen. Ik heb dan ook geen flauw idee wat je denkt over het hoofd te zien of wat je met dit topic wil bereiken
Als je het mij vraagt maak je een DB-in-een-DB en daar zie ik de gein niet zo van in. Als je al een RDBMS wil gaan gebruiken hiervoor voorzie ik nu al vele valkuilen zoals o.a. dat alles van hetzelfde type zal zijn ((var)char waarschijnlijk). Het is nogal lastig om een aantal, bedrag, verjaardag, omschrijving en image op te slaan in allemaal hetzelfde datatype in 1 tabel...
Anyhow; kun je eens wat uitwijden om ons allemaal te verlichten met wat je wil bereiken?

[ Voor 50% gewijzigd door RobIII op 30-08-2006 15:32 ]

[MicroWhale]

Het wordt niet in een RDBMS gestopt. Het wordt geen DB-in-een-DB. Het wordt (wat mij betreft) een DBMS op zichzelf. Dat is mijn doel.... tenminste, om te beginnen te bewijzen dat het een DBMS kan zijn.

En dan niet eentje met tabellen en modellen, maar eentje met één pool aan gegevens waarvan de structuur van de gegevens binnen diezelfde pool is vastgelegd. Zo kunnen door queries aan deze gegevens een context gegeven worden, waardoor er informatie uitkomt.

De database zal uiteraard numeriek-, datum-, blob- en karaktervelden hebben, al dan niet met een bepaalde format.

[RobIII]

...en wat is dan het nut van dit topic?
Je beschrijft je "probleem" maar érg globaal. Hoe moeten wij nu bepalen of je iets vergeet of niet? Je verhaal is dusdanig abstract en stelt dusdanig "vage" functionele eisen dat ik niet zie wat we er op zouden moeten aanmerken...
(Overigens geldt dat ook voor je document)

[ Voor 15% gewijzigd door RobIII op 30-08-2006 18:04 ]

[Creepy]

Maar hoe sla je dan nu alles op als je geen DB gebruikt? Een eigen bestandformaat? XML bestanden?

En, wat RobIII ook al aangeeft: wat wil je nu van ons? Je document is zo algemeen dat we er vrij weinig mee kunnen. Daarnaast heb je het over een implementatie die niet te vinden is?

Ben je niet een ODBMS aan het bedenken? En als het daar op lijkt, heb je daar de na- en voordelen al eens van op een rijtje gezet om maar niet te spreken over de nadelen die kleven aan een "father of all models" opzet?

[MicroWhale]

Het ging eigenlijk alleen over het mijn document (in de link), dat father of all models is maar een richting in welke je ongeveer moet denken. Net zoals dat het een specifiek soort network-model database zou zijn.

Omdat de definitie van een ODBMS nog nooit goed is vast gelegd, zou je kunnen zeggen dat het een soort ODBMS is met een heel specifieke vorm en functionaliteit.

Maar ja, dat is misschien ook weer te vaag. Echter, het ontwerpen van een systeem kan op meerdere abstractielagen plaatsvinden. De abstractielaag waarin ik dit heb geschreven zou de lezer, met een beetje lees- en denkwerk, genoeg materiaal moeten geven om zich een voorstelling te kunnen maken van het systeem.
Ik kan zelf nog niet teveel in detail treden omdat bepaalde zaken op lagere abstractienivo's simpelweg nog niet gemaakt zijn. Dat is de reden waarom ik op dit moment geen "hapklare brokken" kan presenteren.
Ik kan me voorstellen dat daardoor het doel van dit topic ook vaag wordt maar dat blijft, voor degenen die het begrijpen, om c&c te geven op dit conceptueel ontwerp.

[Creepy]

Maar in je document geef je aan dat je de meest genoemde punten al werkend hebt. Dus het lijkt me dat je over een aantal details toch al behoorlijk hebt nagedacht en uitgewerkt.

Als ik het document lees blijf ik terugkomen op een "father of al models" waarbij ik de voordelen van je aanpak er niet direct aan kan af zien. Maar dat komt misschien ook omdat ik enigzins zit vastgeroest aan de gangbare RDBMS'en

[MicroWhale]

ok, ik zal het wat practischer uit proberen te leggen. Voor het gemak laten we typering van velden even weg.

in een RDBMS zou je dit plaatje hebben:

record "persoon"
veldnaam1 -> inhoud1
veldnaam2 -> inhoud2
veldnaam3 -> inhoud3

We nemen een tabel "personen" met 2 record:
ID, naam, functie
1, stefan, vakkenvuller
2, marieke, kassiere

Hierbij is "record" een voorgedefinieerd blok en de inhoud is in deze definitie meegenomen. Hierdoor krijg je een vrij blokkerige en rigide datastructuur, die vrij moeilijk te veranderen is.

als je dit in mijn model zou stoppen zou er dit in zitten:

persoon1 -> naam -> stefan
persoon1 -> functie -> vakkenvuller
persoon2 -> naam -> marieke
persoon2 -> functie -> kassiere

hierbij wordt opgemerkt dat er dan 8 elementen in de database zitten, te weten:
persoon1, naam, stefan, functie, vakkenvuller, persoon2, marieke en kassiere.

Deze zijn onderling zo verbonden dat de informatie in een soort "oneindige boom" hangt, waaruit de informatie zoals boven weergegeven te halen is. Ik zal hiervan als ik weer thuis ben een visuele representatie posten.

[Verwijderd]

In een RDBMS kan dat gewoon zo:

Functie
1, Vakkenvuller, Vakkenvulster
2, Kassier, Kassiere

PersoonNaamGeslacht
1, Stefan, m
2, Marieke, v

PersoonFunctie
1, 1 (Persoon 1 Functie 1)
2, 2 (Persoon 2 Functie 2)

[ Voor 10% gewijzigd door Verwijderd op 31-08-2006 10:11 ]

[MicroWhale]

dat kan ook gewoon zo playroll. Zoals ik in mijn artikel zeg, loopt dat enorm uit de hand als je alles zo gaat modellen in een RDBMS. Je datastructuur wordt onbeheersbaar groot en je queries nemen ongekende proporties aan als het gaat om tijd en grootte.

[ Voor 3% gewijzigd door MicroWhale op 31-08-2006 10:26 ]

[RobIII]

Verwijderd schreef op donderdag 31 augustus 2006 @ 10:10:
In een RDBMS kan dat gewoon zo:

Functie
1, Vakkenvuller, Vakkenvulster
2, Kassier, Kassiere

PersoonNaamGeslacht
1, Stefan, m
2, Marieke, v

PersoonFunctie
1, 1 (Persoon 1 Functie 1)
2, 2 (Persoon 2 Functie 2)

Erger: het kan ook zo:

Key	Value
Persoon 1	Stefan
Persoon 1	Vakkenvuller
Persoon 1	Amsterdam
Persoon 1	03/05/1982
Persoon 2	Marieke
Persoon 2	Kassiere
Persoon 2	Rotterdam
Persoon 2	18/07/1972

En dat is het enige dat ik uit het verhaal terughaal (behalve dan dat je dezelfde records onderling ook nog eens associeërt):

Key	Value
Vakkenvuller	Persoon 1
Vakkenvuller	Kassiere
...	...
Amsterdam	Persoon 1
Rotterdam	Persoon 2
...	...

En aan die "keys" hang je dan weer een type attribuut en dat soort "flauwekul". Het is niks anders dan een ontzettend simpel metadata model dat "het menselijk brein" probeert te vangen in begrijpelijke modellen.

Dat is wat ik zie als ik kijk naar "The Father of all models" en als ik TS z'n verhaal lees. En of je dat nou in een RDBMS stopt, of in een XML/CSV/EDI/Binary file of whatever... het komt allemaal op hetzelfde neer... Een "datamodel" dat belooft "alles" te kunnen opslaan in "oneindige" capaciteit. En in de praktijk is het trieste ellende om er iets nuttigs mee te kunnen doen.

[ Voor 23% gewijzigd door RobIII op 31-08-2006 10:38 ]

[Verwijderd]

Een brein werkt zeker niet op de manier zoals jij het beschrijft. Het is geen enorme database waar continue associaties aan worden toegevoegd als zijnde een compleet nieuw element. Hoe het wel precies werkt zijn ze nog niet uit, maar jouw simplificatie klopt in ieder geval voor geen meter.

Je eerste link geeft zelf al aan dat zo'n methode compleet onwerkbaar is; de oplossing die ik gaf geeft in ieder geval nog duidelijkheid hoe bepaalde gegevens gekoppeld kunnen worden, bepaalde tabellen kunnen geoptimaliseerd worden naar gelang de inhoud en structuur, etc. terwijl in jouw oplossing alles in een paar grote tabellen wordt opgeslagen, wat de queries er niet makkelijker en zeker niet sneller op maakt.

Ik heb liever een ongekend grote datastructuur dan een enorm kleine met een ongekend grote hoeveelheid aan verschillende data.

@RobIII: Sorry, ik was nog niet zo lang wakker

[ Voor 13% gewijzigd door Verwijderd op 31-08-2006 11:56 ]

[RobIII]

Verwijderd schreef op donderdag 31 augustus 2006 @ 10:47:
Een brein werkt zeker niet op de manier zoals jij het beschrijft. Het is geen enorme database waar continue associaties aan worden toegevoegd als zijnde een compleet nieuw element. Hoe het wel precies werkt zijn ze nog niet uit, maar jouw simplificatie klopt in ieder geval voor geen meter.

Je eerste link geeft zelf al aan dat zo'n methode compleet onwerkbaar is; de oplossing die ik gaf geeft in ieder geval nog duidelijkheid hoe bepaalde gegevens gekoppeld kunnen worden, bepaalde tabellen kunnen geoptimaliseerd worden naar gelang de inhoud en structuur, etc. terwijl in jouw oplossing alles in een paar grote tabellen wordt opgeslagen, wat de queries er niet makkelijker en zeker niet sneller op maakt.

Ik heb liever een ongekend grote datastructuur dan een enorm kleine met een ongekend grote hoeveelheid aan verschillende data.

Dat is nu precies wat ik aan het beweren ben
Het is helaas wat onduidelijk, maar mijn post was sarcastisch bedoeld (daarom begint de post met het woordje "erger:" ) Dat "menselijk brein" staat niet voor niets tussen quotes en kijk dan even goed naar mijn laatste zin.
Lees de rest van mijn posts in dit topic ook maar even

[ Voor 8% gewijzigd door RobIII op 31-08-2006 11:43 ]

[The Eagle]

het verhaal van de TS doet me een beetje denken aan wat men mindmapping noemt. Wil je dit in een DB vangen, dan betekent dat dat je per element moet toestaan dat je een oneindig aantal koppelpunten (foreign keys) kunt hebben. Dat kan op zich wel geprogrammeerd worden. Alleen zul je dan zien dat als je wilt gaan zoeken, je als je geen restrictie aan het aantal gekoppelde paden / relaties geeft, constant een full DB search moet gaan doen Immers, je wilt dan alle onderlinge relaties weten - en alles is met elkaar verbonden.

[MicroWhale]

Verwijderd schreef op donderdag 31 augustus 2006 @ 10:47:
Een brein werkt zeker niet op de manier zoals jij het beschrijft. [..]

Ik heb liever een ongekend grote datastructuur dan een enorm kleine met een ongekend grote hoeveelheid aan verschillende data.

Correct, daarom is een discussie hierover ook niet noodzakelijk.

Als je met "verschillende" bedoelt "ongestructureerde", dan wijs ik op

4.2. The model in the database is defined entirely in Concepts,

Alsin: De structuur van de database is vastgelegd in de database zelf.
Niet te verwarren met: De structuur van de database is de database zelf.

[RobIII]

Logos schreef op donderdag 31 augustus 2006 @ 13:45:
Alsin: De structuur van de database is vastgelegd in de database zelf.
Niet te verwarren met: De structuur van de database is de database zelf.

Kun je dan, alsje alsjeblieft, eens met een voorbeeld en/of stuk(je) code komen? Want ik snap er geen kont meer van, en velen met mij hier denk ik. Ik denk nog steeds dat wij je of niet begrijpen, of dat jij ons niet begrijpt
Zoals al vaker gezegd; je document zegt eigenlijk helemaal niks, je posts maken het niet veel duidelijker en wellicht hebben wij het "inzicht" niet om jouw idee te kunnen "bevatten".

Voorzetje: Leg jouw persoontje (geboortedatum, woonplaats, salaris, haarkleur, hobbies, foto, stamboom, feitjes die je weet over geschiedenis, belevingen op de kermis, en nog wat gegevens* die met jou geassocieerd worden) eens in een voorbeeld voor aan ons. Want dat zeg je in je "BubbleBase" te kunnen "beschrijven"/"opslaan".

* Uiteraard mag je fictieve gegevens gebruiken

[ Voor 49% gewijzigd door RobIII op 31-08-2006 14:03 ]

[Verwijderd]

Logos schreef op donderdag 31 augustus 2006 @ 13:45:
Als je met "verschillende" bedoelt "ongestructureerde"...

Nee, ik bedoel verschillende soorten data. Zoals als voorbeeld is gegeven; geboortedata en namen in het zelfde veld, zonder dat de database qua opslag hier onderscheid in maakt.

[P_de_B]

De uitwerking misschien niet, maar de gedachte wel, doet me een beetje aan dit topic denken: [Datamodel] Systeem maken met maar één tabel

misschien aardig als referentie

[MicroWhale]

De database in dat topic lijkt inderdaad heel erg op die van mij.

Ik geloof dat ik, in de RDBMS-zin van het woord, dan 2 tabellen heb:
tabel1: "ID,data"
tabel2: ID1,ID2,ID3

maar dat heeft hij volgens mij ook als ik dat uit zijn uitleg opmaak. Het is op zich niet zo'n probleem om dit in een RDBMS te stoppen, het is een probleem dat een RDBMS dit gewoon niet aankan. Dit terwijl het, volgens mij, een hele goede manier van opslag kán zijn. Het wordt mijns inziens alleen een leuke manier van gegevens opslaan als datgene wat je erin stopt ook op een dusdanige manier georganiseerd is dat je er informatie uit krijgt.

Hieronder een voorbeeld van een "BubbleBase"


Voorbeelden
ID1,ID2,ID3
{B36...}, Voornaam, char(20)
{D26....},Voornaam,leonie
"Table.Personen","Table.Structure",{B36...}

Een lookup van alle ID1's van alle ID3's met "leonie" levert twee records op. (het record zelf en een andere leonie)

[RobIII]

En toch ben je nu een DB-in-een-DB aan het bouwen. Wat doet die tabel "Table Structure" er anders? Wat denk je dat er in je Master table in een database zit?
Je benoemt veldnamen "in" een tabel, terwijl de tabel zélf die velden zou moeten hebben. Maar ja, dat is niet zo "flexibel" he?

[ Voor 28% gewijzigd door RobIII op 31-08-2006 17:33 ]

[SPee]

Ik werk nu ook kort met een applicatie die zo'n structuur gedefineerd heeft:
een tabel property_set en een tabel property
Met de tabel property geeft je de key-value waardes op en in de tabel property_set geef je de variable van de key op.

Ik - als programmeur - vindt dat heel erg slecht werken (naast dat het (bijna) niet performt).
Je weet niet welke waardes je allemaal gebruikt of die beschikbaar zijn, welke waardes je wel mag gebruiken. En om iets te bekijken in de database heb je gelijk 2 tabellen nodig, tenzij je wilt/kunt werken met de id's van de key.
Dus als programmeur wil je liever weten wat je uit de database kunt halen en hoe. Met een 'normale' DB model kun je al vrij snel zien wat er in de velden moet komen en wat je er dus uit kunt halen en hoe.

[MicroWhale]

RobIII schreef op donderdag 31 augustus 2006 @ 17:32:
En toch ben je nu een DB-in-een-DB aan het bouwen. Wat doet die tabel "Table Structure" er anders? Wat denk je dat er in je Master table in een database zit?
Je benoemt veldnamen "in" een tabel, terwijl de tabel zélf die velden zou moeten hebben. Maar ja, dat is niet zo "flexibel" he?

Je bent wel sceptisch zeg

Ik bouw "tabellen" in een eigengemaakt DB, waarvan onderhuids één van de onderdelen een tabel is waarin alle data staat. Vreemd is dat op zich niet, dat doen de grote db-bouwers ook. Die gebruiken onderhuids ook een eigen structuur en tabellen. Het verschil is dat zij niet vertellen hoe die structuur in elkaar zit. Ik doe dat nu wel.

Het enige wat dit betekent is dat mijn DB ook een DB uit een RDBMS zou kunnen bevatten.

Bovendien is het niet noodzakelijk om die tabellen-structuur te gebruiken. Die heb ik verzonnen omdat een van jullie vroeg hoe ik persoonsgegevens uit een tabel op zou slaan. Je kunt er ook andere dingen mee, zoals:

ID1, ID2, ID3
tafel, heeft, poten
tafel, is, voorwerp
vlieg, heeft, vleugels
lucht, bevat, zuurstof
cirkel, is, rond
etc...

Dit geeft een totaal andere functie aan de database. En door de opbouw wordt mijn DB er niet traag van. Ten eerste omdat hij speciaal om deze structuur heen gebouwd is, ten tweede omdat ik hierdoor op een leuke manier wat algoritmes erop los kan laten.
Het is ook jammer dat ik "ID1, ID2 en ID3" als voorbeeld moet gebruiken, omdat dit mensen doet denken aan een RDBMS tabel en dat suggereert weer dat dit inderdaad niet zo flexibel en snel is.

[MicroWhale]

SPee schreef op donderdag 31 augustus 2006 @ 17:58:
Ik werk nu ook kort met een applicatie die zo'n structuur gedefineerd heeft:
een tabel property_set en een tabel property
Met de tabel property geeft je de key-value waardes op en in de tabel property_set geef je de variable van de key op.

Ik - als programmeur - vindt dat heel erg slecht werken (naast dat het (bijna) niet performt).
Je weet niet welke waardes je allemaal gebruikt of die beschikbaar zijn, welke waardes je wel mag gebruiken. En om iets te bekijken in de database heb je gelijk 2 tabellen nodig, tenzij je wilt/kunt werken met de id's van de key.
Dus als programmeur wil je liever weten wat je uit de database kunt halen en hoe. Met een 'normale' DB model kun je al vrij snel zien wat er in de velden moet komen en wat je er dus uit kunt halen en hoe.

Welke applicatie is dat precies?

Dank je wel voor de tips.

[Creepy]

Logos schreef op donderdag 31 augustus 2006 @ 19:44:
[...]


Je bent wel sceptisch zeg

Ik bouw "tabellen" in een eigengemaakt DB, waarvan onderhuids één van de onderdelen een tabel is waarin alle data staat. Vreemd is dat op zich niet, dat doen de grote db-bouwers ook. Die gebruiken onderhuids ook een eigen structuur en tabellen. Het verschil is dat zij niet vertellen hoe die structuur in elkaar zit. Ik doe dat nu wel.

Een RDBMS ziet toch iets anders in elkaar want hoe een tabel eruit ziet sla jij op in een tabel (even simpel gezegd) waardoor je nooit in 1 keer de correct date eruit kan halen. Een RDMBS slaat z'n eigen data niet altijd op dezelfde manier op als alle andere data in die DB waardoor je op een andere manier kan achterhalen wat er nu bijv. in een tabel zit.

Het enige wat dit betekent is dat mijn DB ook een DB uit een RDBMS zou kunnen bevatten.

Bovendien is het niet noodzakelijk om die tabellen-structuur te gebruiken. Die heb ik verzonnen omdat een van jullie vroeg hoe ik persoonsgegevens uit een tabel op zou slaan. Je kunt er ook andere dingen mee, zoals:

ID1, ID2, ID3
tafel, heeft, poten
tafel, is, voorwerp
vlieg, heeft, vleugels
lucht, bevat, zuurstof
cirkel, is, rond
etc...

Dit geeft een totaal andere functie aan de database. En door de opbouw wordt mijn DB er niet traag
van. Ten eerste omdat hij speciaal om deze structuur heen gebouwd is, ten tweede omdat ik hierdoor op een leuke manier wat algoritmes erop los kan laten.

Dus dit wordt niet traag? Mag ik vragen waarom je dat denkt? Wat heb je bedacht om dit soort gegevens bevraagbaar te maken en snel op te kunnen halen? Nogmaals: het lijkt erop alsof je al een daadwerkelijke implementatie hebt draaien maar je komt *alleen* met een theoretisch verhaal. Hoe houdt zich dat nu in de praktijk? Dus hoe heb je nu je systeen opgezet om dit soort zaken makkelijk en snel te kunnen bevragen?

Het is ook jammer dat ik "ID1, ID2 en ID3" als voorbeeld moet gebruiken, omdat dit mensen doet denken aan een RDBMS tabel en dat suggereert weer dat dit inderdaad niet zo flexibel en snel is.

Ook ik blijf bij dit idee steken. Je voorbeeld van "tafel is voorwerp" etc. maakt het mij al duidelijker wat je nu ongeveer wilt maken maar data op die manier opslaan is volgens mij niet de manier.
Maar je grijpt zelf ook steeds terug op het RDMBS verhaal. Kan je voorbeelden op een andere manier geven? Of ga je dan weer richting een ODMBS gebeuren inclusief de nadelen die hieraan kleven?

offtopic:
shitload aan vraagtekens zeg

[ Voor 4% gewijzigd door Creepy op 31-08-2006 20:26 ]

[RobIII]

Ok. Dus ik zeg tegen een computer: tafel, heeft, poten. En daarna zeg ik tafel, is, voorwerp.
Heeft een voorwerp dan poten? En een glas water? Da's toch ook een voorwerp? Maar dat heeft geen poten. En een tafel is niet nat.

Ga nou eens concreet in op de vragen die we je stellen om ons duidelijk te maken wat je idee is, vooral Creepy heeft er nogal wat En als je al een werkende implementatie hebt (wat je glashard beweert in je "proof of concept", omschrijf die dan eens; of better yet: toon het ons )

[ Voor 9% gewijzigd door RobIII op 31-08-2006 22:49 ]

[Technicality]

Als je het creëren van de links tussen de 'bubbles' ook maar *iets* automatiseerd heb je in feite al hetzelfde als nu gebruikt wordt. De relaties tussen deze zullen namelijk altijd hetzelfde zijn (bijvoorbeeld kat - plaatje van een poes en hond - plaatje van een hond, in beide gevallen gaat het om dier-plaatje) en dus kun je het vergelijken met een tabel.

edit: als je het niet automatiseerd wens ik je veel succes, wie wil nou een DB waarbij je elke relatie apart moet aangeven?

Mmh, dit venster heeft per ongeluk een dag opengestaan vandaag...

[ Voor 21% gewijzigd door Technicality op 31-08-2006 23:42 ]

[MicroWhale]

RobIII schreef op donderdag 31 augustus 2006 @ 22:47:
Ok. Dus ik zeg tegen een computer: tafel, heeft, poten. En daarna zeg ik tafel, is, voorwerp.
Heeft een voorwerp dan poten? En een glas water? Da's toch ook een voorwerp? Maar dat heeft geen poten. En een tafel is niet nat.

Ga nou eens concreet in op de vragen die we je stellen om ons duidelijk te maken wat je idee is, vooral Creepy heeft er nogal wat En als je al een werkende implementatie hebt (wat je glashard beweert in je "proof of concept", omschrijf die dan eens; of better yet: toon het ons )

Je maakt een denkfout: Als je een relatie legt tussen twee concepten, betekent dat niet dat die relatie per definitie ook andersom geldt. Als dat wel zo is, dan kun je dat invoeren. "Voorwerp, is, tafel" geldt ook niet per definitie namelijk, terwijl je dit wel suggereert met je vraagstelling.

Ik heb tot nu toe concreet antwoord gegeven op de vragen. Ik merk dat sommige mensen de goede kant op zitten met hun beeldvorming (of er al zijn) en andere mensen niet.
En wat probeer jij te bereiken met jouw vragen? Het lijkt er namelijk op dat je me, op een niet al te vriendelijk overkomende manier, uit de tent probeert te lokken. Ben je frustie dat je het niet begrijpt? Er is troost: Ik heb hier al met meerdere mensen over gepraat en heb gemerkt dat sommigen het wel en sommigen het niet begrijpen, ook al laat je het ze tig keer zien.
Ik heb nog geen tijd gehad om Creepy zijn vragen te beantwoorden. Dit ga ik zeker doen, maar niet nu.

[RobIII]

Logos schreef op vrijdag 01 september 2006 @ 08:25:
[...]

Je maakt een denkfout: Als je een relatie legt tussen twee concepten, betekent dat niet dat die relatie per definitie ook andersom geldt. Als dat wel zo is, dan kun je dat invoeren. "Voorwerp, is, tafel" geldt ook niet per definitie namelijk, terwijl je dit wel suggereert met je vraagstelling.

Dat zie ik, daarvoor, je nergens zeggen. In de wiskunde (bijvoorbeeld) is het erg gebruikelijk dat als A = B dat dan B = A hetzelfde is Dat bedoelen we dan ook als we zeggen dat je vaag bent in je bewoordingen. Je stelt alles zo breed dat er niets concreets uit is af te leiden. Dus proberen we je concretere uitspraken te ontlokken. Wij kunnen niet ruiken / raden dat concepten maar "one way" relaties hebben. Het is jouw idee, dat zul jij ons dus moeten vertellen. Laat ik het zo zeggen; je hebt het over een concept dat dusdang complex is als je beweert; hoe kun je het dan in anderhalve pagina tekst (je document) en een paar posts helemaal uitleggen zonder vaag te zijn en alle details te omschrijven?

Logos schreef op vrijdag 01 september 2006 @ 08:25:
Ik heb tot nu toe concreet antwoord gegeven op de vragen. Ik merk dat sommige mensen de goede kant op zitten met hun beeldvorming (of er al zijn) en andere mensen niet.
En wat probeer jij te bereiken met jouw vragen? Het lijkt er namelijk op dat je me, op een niet al te vriendelijk overkomende manier, uit de tent probeert te lokken.

Ja natuurlijk proberen we je uit de tent te lokken want we hebben nog steeds geen idee waar je het over hebt. We proberen je idee af te tasten en een beeld te vormen van wat je nou bedoelt, maar we moeten het wel uit je trekken. Er komt, zoals gezegd, niets concreets uit.

Logos schreef op vrijdag 01 september 2006 @ 08:25:
Ben je frustie dat je het niet begrijpt? Er is troost: Ik heb hier al met meerdere mensen over gepraat en heb gemerkt dat sommigen het wel en sommigen het niet begrijpen, ook al laat je het ze tig keer zien.

Zullen we niet met modder gaan gooien?
Ik ben me erg bewust van het feit dat ik niet alles kan / zal begrijpen. Ik ben ook maar een mensch en ergens houdt het voor mij ook op. Maar ik kan wel heel erg mijn best doen. En dat is precies wat ik nu doe; ik doe heel erg mijn best om iets zinnigs uit je verhaal te halen. Maar tot nu toe zie ik nog steeds niet wat je met dit topic wil en wat je er al mee zou hebben bereikt. Los daarvan heb ik in dit topic nog geen één inhoudelijke comment/critic gezien op je idee (en dat was toch het doel van dit topic?), enkel op het "Father of all models" idee. Wat voor meerwaarde haal je uit dit topic dan?

Vooralsnog mis ik nog steeds antwoorden op de meest basic vragen zoals; waar sla je je concepts nu dan in op? In een RDBMS? Nee? In een binary file? In een XML file? ... En heb je, zoals je beweert in je document, dan al een werkend concept? En wat doet dat dan? Wat heb je daar al mee bereikt? Wat voor zinnigs kun je er mee doen? En als wij (ik) stellen dat je een DB-in-een-DB aan het bouwen bent (of een DB an sich), maar jij zegt dat het niet zo is; overtuig ons er dan eens van? Waar zit het verschil dan? En wat doet het "Father of all models" in je verhaal als je model zo anders is? En toon dan eens aan dat je geen "Father of all models" gebruikt? Want dat zie ik in je schema wel terug...
Vragen, vragen, vragen...

Logos schreef op vrijdag 01 september 2006 @ 08:25:
Ik heb nog geen tijd gehad om Creepy zijn vragen te beantwoorden. Dit ga ik zeker doen, maar niet nu.

Succes! Ik ben benieuwd! Dat zal zeker veel verhelderen.

[ Voor 23% gewijzigd door RobIII op 01-09-2006 16:51 ]

[Spruit_elf]

hmmm ik snap wel waar de TS heen wilt met zijn DB

de problemen die ik zo ff snel zie aankomen...

- elke db moet zijn data opslaan dus ook deze, hoe wil je dat gaan doen, ik ben namelijk bang dat je als je al een werkbare db maakt op deze manier, je je data alsnog moet gaan verwerken omdat je hem niet op precies de zelfde manier op kan slaan als je hem toegankelijk wilt hebben.
als je dan niet uit kijkt ben je in feite een wrapper voor een bestaande db type aan het schrijven en dat is performance wise niet echt handig, tenzij er een applicatie is die echt heel veel baat heeft bij een dergelijke structuur.
- het voordeel van een RDBMS is dat het veld waarop je selecteerd voor alle entry's/blobs wat dan ook gelijk is en het vergelijken daarvan dus erg makkelijk gaat. ik ben bang dat je als je toestaat dat een concept 'alles' kan zijn dat het nogal moeilijk wordt om daar op een goede en niet ambigue manier tussen te verglijken. misschien dat dit probleem wel te overzien is als je ervoor zorgt dat er nooit veel 'gelijke' nodes zijn om te vergelijken
- ik heb een beetje het idee dat je een soort ODBMS aan het maken bent op deze manier, of igg dat het met een ODBMS ook mogelijk is om een deze structuur te maken, als ik jouw was zou ik me ff inlezen in de voor en nadelen van ODBMSen (eerlijk gezegd ben ik bijna zeker dat wat de TS voorstelt een ODBMS met een aantal restricties is) Edit: dat laatste neem ik terug, voor zover ik weet is multiple inheritance in OOP al moeilijk genoeg, geen idee of er uberhaupt ODBMS zijn die dat goed kunnen. als je pech hebt loop je dus ook tegen dat probleem aan als je geluk hebt niet

wat doe je als je de catergorie voorwerpen wilt benaderen doormiddel van de part-of-concepts tafel en tak? hoe weet de DB dat jij voorwerpen zoekt en niet alle woorden die met ta beginnen?
moet je om een concept via zijn delen te vinden alle delen geven of mag het ook met een subset?
wat doe je als 2 concepten precies de zelfde part-of-concepts hebben? zijn ze dan het zelfde?


al met al vind ik het op zich een hele interesant vraagstuk echter ik ben bang dat je hier heel lang over na moet gaan denken, danwel heel brilliant moet zijn wil je hier echt iets nuttigs uit halen (voorop gesteld dat het niet allang bestaat of niet te doen is..).

eerlijk gezegd denk ik dat je nog niet eens zo gek ver van de werking van (een deel van) de hersenen af zit met dit idee, maar als ik jouw was zou ik me daarom ook meer focussen op het vergeten gedeelte aangezien ik denk dat er daar nog best iets intressants te doen is (stel je voor een RDBMS die uit zichzelf rows dropt ) bijv om te voorkomen dat je dataset te groot wordt oid

offtopic:
doet de TS soms iets in de richting (C)KI ?

[ Voor 12% gewijzigd door Spruit_elf op 02-09-2006 02:27 ]

[Spruit_elf]

RobIII schreef op vrijdag 01 september 2006 @ 16:14:
[...]

Dat zie ik, daarvoor, je nergens zeggen. In de wiskunde (bijvoorbeeld) is het erg gebruikelijk dat als A = B dat dan B = A hetzelfde is Dat bedoelen we dan ook als we zeggen dat je vaag bent in je bewoordingen. Je stelt alles zo breed dat er niets concreets uit is af te leiden. Dus proberen we je concretere uitspraken te ontlokken. Wij kunnen niet ruiken / raden dat concepten maar "one way" relaties hebben. Het is jouw idee, dat zul jij ons dus moeten vertellen. Laat ik het zo zeggen; je hebt het over een concept dat dusdang complex is als je beweert; hoe kun je het dan in anderhalve pagina tekst (je document) en een paar posts helemaal uitleggen zonder vaag te zijn en alle details te omschrijven?

ik denk dat het wat duidelijker wordt als je in verzamelingen gaat praten, je hebt de verzameling voorwerpen en daar zitten zowel tafels als glazen water in, echter die zitten allebei in hun eigen sub verzameling waardoor ze weldegelijk apart eigenschappen kunnen hebben maar ze hebben de 'relatie' dat ze allebij voorwerpen zijn. Wellicht dat dit gebruik van relatie in de context van DB's niet bijdraagt aan de duidlijkheid

[...]

Ja natuurlijk proberen we je uit de tent te lokken want we hebben nog steeds geen idee waar je het over hebt. We proberen je idee af te tasten en een beeld te vormen van wat je nou bedoelt, maar we moeten het wel uit je trekken. Er komt, zoals gezegd, niets concreets uit.

probeer er eens met een open mind naar te kijken, niet iedereen heeft de zelfde achtergrond of knowhow over een bepaald onderwerp en zal soms met de zelfde woorden iets anders bedoelen. ik geef je gelijk dat het nog niet concreet is, maar als je dat persee wilt kan je beter naar prg gaan oid niet iedereen heeft het in zich om een idee gelijk goed uit te leggen

[Orphix]

Ik kan me voorstellen dat met de komst van quantum computing in de toekomst de opslag en verwerking van databases geheel zal veranderen. Immers zijn dergelijke computers (voor zover ik heb begrepen) in staat om veel taken parallel uit te kunnen voeren. Dan zou een voorgesteld datamodel realistisch kunnen zijn qua performance. Wellicht is het een idee om te zoeken of hier al meer ideen over zijn? (Dus icm quantum computing).

[MicroWhale]

Creepy schreef op donderdag 31 augustus 2006 @ 20:24:
[...]

Dus dit wordt niet traag? Mag ik vragen waarom je dat denkt? Wat heb je bedacht om dit soort gegevens bevraagbaar te maken en snel op te kunnen halen? Nogmaals: het lijkt erop alsof je al een daadwerkelijke implementatie hebt draaien maar je komt *alleen* met een theoretisch verhaal. Hoe houdt zich dat nu in de praktijk? Dus hoe heb je nu je systeen opgezet om dit soort zaken makkelijk en snel te kunnen bevragen?
[...]

offtopic:
shitload aan vraagtekens zeg

Het zijn inderdaad heel wat vraagtekens, maar het kan nog erger hoor (zie paar posts terug )

Het is niet traag op het moment dat je weet waarnaar je zoekt. Dit komt omdat ik hashes gebruik om elementen te zoeken. Echter ik kwam er vandaag achter dat ik, als ik op een deel van een woord of een range wil gaan zoeken, een probleem heb. Dit is inderdaad takke-traag. Hier zijn meerdere oplossingen voor, waarvan er een in aanmerking komt. Die ga ik later implementeren. Of ie werkt, weet ik dus nog niet.

Op veler verzoek, qua implementatie zit het zo in elkaar:

DataFile - Alle inhoudelijke data. Binair en sequentieel.

LinkFile - Per Item (ID1) een praktisch "oneindige" lijst van "ID2,ID3". Dit is opgeslagen in "blokken" om snel meerdere LinkItems tegelijkertijd te laden.

DataList - Hierin zit de type-info + filepos van datafile + filepos van eerste linkitemblok in LinkFile. Ook weer hapklare brokken, om snel te kunnen seeken.

HashFile - Hashes van alle hashbare items. "hash,datalist-filepos" (dit is in een file-gebaseerde tree gestopt met 10 buckets (0..9)).

Een hash is in maximaal "diepste bucket+1" seeks te vinden.
Een datalist element in "diepste bucket+2"
En de data zelf of de links dus in "diepste bucket+3".

Wordt dit niet enorm groot? Ja, dit wordt groot. Maar ja, het blijft een proof of concept.

Ik ben aan het testen met een paar tabellen van ongeveer een half miljoen records (ongeveer 4.8 miljoen velden, waarvan ong. 2 miljoen unieke elementen). Dit groeit met ongeveer 400% van de originele dbf. De diepste bucket is voor deze file 4.

Mocht je me willen bekritiseren over deze implementatie: Ik weet dat het links en rechts efficiënter en beter kan, maar daar gaat het me nu niet om. Het gaat om wat je er uiteindelijk wel en niet mee kan. Het interesseert me vooralsnog niet of de data in een binaire file of in een xml opgeslagen zit. Het is voor nu alleen relevant om te focussen op het mechanisme niet op de implementatie zelf. De puntjes op de i komen later.

[MBV]

Ik heb de laatste pagina niet helemaal meer gelezen, maar het doet mij gedeeltelijk denken aan RDF. Eigenlijk is een 'bubble tree' zoals jij die beschrijft een gerichte graaf (directed graph). En dat is wat je in RDF kan opslaan.
Kijk anders eens naar de eerste presentatie van dit vak wat ik gisteren kreeg Volgens mij kan je met RDF namelijk precies wat jij wilt.
Los daarvan denk ik dat elke eis qua prestatie jouw idee onmogelijk maakt, magoed, da's een ander verhaal

[ Voor 1% gewijzigd door MBV op 06-09-2006 22:22 . Reden: fout linkje ]

[RobIII]

MBV schreef op woensdag 06 september 2006 @ 15:06:
Ik heb de laatste pagina niet helemaal meer gelezen, maar het doet mij gedeeltelijk denken aan RDF. Eigenlijk is een 'bubble tree' zoals jij die beschrijft een gerichte graaf (directed graph). En dat is wat je in RDF kan opslaan.
Kijk anders eens naar de eerste presentatie van dit vak wat ik gisteren kreeg Volgens mij kan je met RDF namelijk precies wat jij wilt.
Los daarvan denk ik dat elke eis qua prestatie jouw idee onmogelijk maakt, magoed, da's een ander verhaal

offtopic:
Die PPT presentatie zegt he-le-maal niks over RDF of uberhaupt iets dat met dit topic te maken heeft... link je wel naar de juiste?

edit:

Ah, na wat zoeken kwam ik op de pagina die je linkte het volgende tegen: http://wwwis.win.tue.nl/~houben/wis/wis-rdf-class.pdf
Ziet er in ieder geval naar uit dat je dat bedoelde Nu nog eens kijken wat het inhoudelijk omvat
Hmm, just as I thought, "gewoon" RDF. Er zijn 1001 metadata modellen, waarvan RDF er idd 1 is, maar het zoeken naar zo'n model is niet waar dit topic in essentie om draait

[ Voor 19% gewijzigd door RobIII op 06-09-2006 15:41 ]

[MicroWhale]

MBV schreef op woensdag 06 september 2006 @ 15:06:
Ik heb de laatste pagina niet helemaal meer gelezen, maar het doet mij gedeeltelijk denken aan RDF. Eigenlijk is een 'bubble tree' zoals jij die beschrijft een gerichte graaf (directed graph). En dat is wat je in RDF kan opslaan.
Kijk anders eens naar de eerste presentatie van dit vak wat ik gisteren kreeg Volgens mij kan je met RDF namelijk precies wat jij wilt.
Los daarvan denk ik dat elke eis qua prestatie jouw idee onmogelijk maakt, magoed, da's een ander verhaal

ik heb vol interesse naar de gegeven links gekeken (en ook die van RobIII hierboven) en dat RDF komt er in feite wel op neer ja. Hier geldt dan helaas voor dat je eerst alles moet definiëren wat je erin op wilt slaan, maar in principe kun je alles ook in dat RDF kwijt.
Bedankt voor de tip. Ik zal in de zeer nabije toekomst eens wat meer gaan lezen over RDF. Hij heeft potentieel en kan zeer interessante informatie/ideeën opleveren.

Kun je die laatste zin nog eens uitleggen? Bedoel je dat ik geen enkele eis wat betreft prestaties mag hebben, omdat ik anders m'n idee niet kan uitwerken?

[GarBaGe]

Waarom neem je geen LDAP ??
Dit is in feite een DB-in-een-DB, maar ook niet helemaal (dus precies wat je wilt). De structuur van de LDAP boom wordt ook in de onderliggende DB opgeslagen, net als de data zelf.

Edit: Oh ja, en een LDAP is in feite een boom structuur.

[ Voor 12% gewijzigd door GarBaGe op 06-09-2006 17:05 ]

[MBV]

RobIII schreef op woensdag 06 september 2006 @ 15:10:
[...]

offtopic:
Die PPT presentatie zegt he-le-maal niks over RDF of uberhaupt iets dat met dit topic te maken heeft... link je wel naar de juiste?

[edit]
Ah, na wat zoeken kwam ik op de pagina die je linkte het volgende tegen: http://wwwis.win.tue.nl/~houben/wis/wis-rdf-class.pdf

Ehm, sorry, 'k had haast, zal mijn post zo aanpassen.

Ziet er in ieder geval naar uit dat je dat bedoelde Nu nog eens kijken wat het inhoudelijk omvat
Hmm, just as I thought, "gewoon" RDF. Er zijn 1001 metadata modellen, waarvan RDF er idd 1 is, maar het zoeken naar zo'n model is niet waar dit topic in essentie om draait

Wat het voordeel is: je kan er gebruik van maken, performance zal misschien beter zijn dan wanneer je zelf het wiel opnieuw uitvindt. En die presentatie gaf ik om een snelle intro te geven richting RDF, niet omdat ik hem zo geweldig vond _{die presentatie duurde 1,5 uur}

Logos schreef op woensdag 06 september 2006 @ 16:56:
[...]
Kun je die laatste zin nog eens uitleggen? Bedoel je dat ik geen enkele eis wat betreft prestaties mag hebben, omdat ik anders m'n idee niet kan uitwerken?

Ik bedoel dat voor zover ik weet, al dat soort dingen supertraag is. Zeker met een grotere database etc. Vandaar dat RDF alleen wordt gebruikt voor het beschrijven van metadata, en niet de data zelf.

GarBaGe schreef op woensdag 06 september 2006 @ 17:04:
Waarom neem je geen LDAP ??
Dit is in feite een DB-in-een-DB, maar ook niet helemaal (dus precies wat je wilt). De structuur van de LDAP boom wordt ook in de onderliggende DB opgeslagen, net als de data zelf.

Edit: Oh ja, en een LDAP is in feite een boom structuur.

Boom is minder vrij dan de TS wil, volgens mij. Je geeft het zelf al aan, een boom, en die heeft geen takken die terugverwijzen naar boven enzo

[MicroWhale]

MBV schreef op woensdag 06 september 2006 @ 22:21:
[...]

Wat het voordeel is: je kan er gebruik van maken, performance zal misschien beter zijn dan wanneer je zelf het wiel opnieuw uitvindt. En die presentatie gaf ik om een snelle intro te geven richting RDF, niet omdat ik hem zo geweldig vond _{die presentatie duurde 1,5 uur}

[...]

Ik bedoel dat voor zover ik weet, al dat soort dingen supertraag is. Zeker met een grotere database etc. Vandaar dat RDF alleen wordt gebruikt voor het beschrijven van metadata, en niet de data zelf.

Kun je mij dan misschien een voorbeeld geven van een app. en een rdf-document met ongeveer een miljoen entries waarin ik kan rondbladeren? Minder mag ook hoor

[GarBaGe]

MBV schreef op woensdag 06 september 2006 @ 22:21:
Boom is minder vrij dan de TS wil, volgens mij. Je geeft het zelf al aan, een boom, en die heeft geen takken die terugverwijzen naar boven enzo

Je kan wel "shortcuts" maken die verwijzen naar een ander deel van de boom en daardoor effectief een graaf creeeren...

[MBV]

da's waar, maar om nou te zeggen dat je dan makkelijk kan zoeken en linken... Voor zover ik weet kan je niet in 1 query zoeken op 'computers met een link naar printers met HP in de naam', zoiets als

SQL:

SELECT *
FROM printers p computers c
WHERE p.id = computer.printerID AND p.name LIKE '*HP*'

Dat kan met RDF dus wel. Syntax heb ik me alleen nog niet in verdiept

@logos: in de sheet staat een linkje naar www.openrdf.org, daar kan je wat queries online proberen. Ik weet van RDF niet meer dan in die slides staat, en zeker niet zelf toegepast 't is alleen het algemene probleem van 'te algemene' databases.

[MicroWhale]

Ik heb van het weekend flink zitten sleutelen en testen. De structuur is nu volledig en ik ga vanavond beginnen met een query-object. Hiervoor neem ik als voorbeeld de sql taal die bij RDF gebruikt wordt. Dit ziet er heel logisch uit, goed toepasbaar en begrijpbaar voor anderen.

Het lezen en schrijven van items gaat met tussen de 20000-30000 per seconde. Dit is niet bijster snel, doch zeer acceptabel. Als je er een 'tabel' in aanmaakt is de snelheid per record "max. snelheid" / "aantal velden". Dus een record met 10 velden doet 2000-3000 per seconde. Het zal dus in mindere mate geschikt gaan zijn voor RDBMS-achtige dingen. Ik weet overigens niet wat normale RDBMS-en doen qua records per seconde enzo (iemand statistics?), maar dat zal waarschijnlijk een stuk hoger liggen.