[Datamodel] Systeem maken met maar één tabel

[seweso]

Op veler verzoek hier een topic om te discussieren of je een systeem kan maken welke gebruik maakt van maar één tabel. Dus waar je allerlei objecten kan opslaan met allerlei eigenschappen.

Zie deze post waar het allemaal mee begon

Ik zeg:
- Het kan
- Het is super flexibel
- Je kunt zoeken
- Je gebruikt indexen
- En het is cool

(en ik heb al een werkend systeem gemaakt btw)

Documentatie (van een nieuwe versie) staat hier

[ Voor 10% gewijzigd door seweso op 09-04-2004 11:50 ]

[djluc]

Je ziet het dan als één grote tree volgens mij, dus met een parentid er bij. Dan kun je in principe alles structureel ok opslaan, maar of het ook goed is voor de performance? Je maakt dan veel minder gebruik van eenvoudige query's omdat alles recursief is, en daar zijn de gewone relationele databases als mysql meestal niet zo goed in.

[P_de_B]

In een object georienteerde db misschien. In een relationele database is het onzin, een andere term heb ik er helaas niet voor.

Indexen gebruiken op objecten in een relationele db kun je wel vergeten.

En of het cool is je datamodel te verprutsen en daarop een systeem te bouwen is nog maar de vraag. eFBe heeft denk ik duidelijk genoeg uitgelegd dat een goed model belangrijk is voor je app.

[seweso]

djluc schreef op 09 april 2004 @ 11:49:
Je ziet het dan als één grote tree volgens mij, dus met een parentid er bij. Dan kun je in principe alles structureel ok opslaan, maar of het ook goed is voor de performance? Je maakt dan veel minder gebruik van eenvoudige query's omdat alles recursief is, en daar zijn de gewone relationele databases als mysql meestal niet zo goed in.

Uiteraard zijn er performance penalties. Maar je hoeft voor een simpel object (dus één die niet uit sub-objecten bestaat) geen joins te maken. Dat betekent dat de query nog steeds simpel is:
"SELECT * FROM `objecten` WHERE `from` = '$id'";
het enige verschil is dat je altijd dezelfde velden terugkrijgt maar dat het aantal rijen voor één object verschillend is.

[ Voor 3% gewijzigd door seweso op 09-04-2004 11:58 ]

[whoami]

Waarom zou je je hele datamodel vernaggelen, en daarmee de performance , stabiliteit en onderhoudbaarheid van je applicatie op de helling zetten?
Omdat het 'cool' is?
Het relationele model is er gekomen na onderzoek, en heeft z'n nut al meer dan genoeg bewezen in de praktijk.

Ik kan enkel met P_de_B akkoord gaan: het is onzin.

Je applicatie staat of valt met een goede / slechte datastructuur.

[ Voor 10% gewijzigd door whoami op 09-04-2004 11:58 ]

[gorgi_19]

Da's onzin. Je kan namelijk net zo goed tekstbestanden op het FS neerzetten, heb je helemaal geen database nog nodig ook.

* gorgi_19 mept whoami, doe eens niet voorkruipen?

[ Voor 46% gewijzigd door gorgi_19 op 09-04-2004 11:58 ]

[whoami]

(uit het andere topic)

seweso schreef op 09 april 2004 @ 10:57:
[...]
Een database is toch wel een heel stuk sneller dan een tekst bestand, mits je gericht informatie zoekt.

Een databank is sneller dan textfiles mits je een goed datamodel hebt, zodat er gebruik gemaakt kan worden van indexen en andere voordelen die een DBMS biedt.
Hoe ga jij trouwens in een datamodel met slechts 1 tabel data-integriteit gaan afdwingen?

Als de TS ook met classen wil werken (dus dat je voor een bed andere eigenschappen kan bijhouden dan bij een vork) dan is dit niet offtopic en anders moet die discussie wellicht ergens anders gevoerd worden (als men het nog niet snapt).

Als je met objecten werkt, zijn er andere manieren om verschillende objecten in je DB bij te houden.

[jurri@n]

Ik heb een systeem gezien waarin dit mogelijk was, maar die had wel meer dan 1 tabel...

1 voor de datatypen, 1 voor de data zelf, en zo verder...

Die oplossing was niet efficient / goed voor de preformance... maar het maakte het wel mogelijk. Het was zeker goed bruikbaar voor kleine sites / applicaties.

[ Voor 36% gewijzigd door jurri@n op 09-04-2004 12:09 ]

[seweso]

gorgi_19 schreef op 09 april 2004 @ 11:57:
Da's onzin. Je kan namelijk net zo goed tekstbestanden op het FS neerzetten, heb je helemaal geen database nog nodig ook.

* gorgi_19 mept whoami, doe eens niet voorkruipen?

Ik ben erg benieuwd wat je redenatie daar achter is.

whoami schreef op 09 april 2004 @ 11:57:
Waarom zou je je hele datamodel vernaggelen, en daarmee de performance , stabiliteit en onderhoudbaarheid van je applicatie op de helling zetten?
Omdat het 'cool' is?
Het relationele model is er gekomen na onderzoek, en heeft z'n nut al meer dan genoeg bewezen in de praktijk.

Ik kan enkel met P_de_B akkoord gaan: het is onzin.

Je applicatie staat of valt met een goede / slechte datastructuur.

Ja maar wat als je van te voren niet weet welke velden er nodig zijn? Dus dat een nono velden moet kunnen toevoegen? Een dynamisch enquete systeem zoals http://www.formdesk.nl/ is hier een mooi voorbeeld van. Waar ik het over heb is om dat laatste nog verder door te voeren waardoor echt alles dynamisch is.

whoami schreef op 09 april 2004 @ 12:03:
(uit het andere topic)
Een databank is sneller dan textfiles mits je een goed datamodel hebt, zodat er gebruik gemaakt kan worden van indexen en andere voordelen die een DBMS biedt.

Ik gebruik uiteraard ook indexen, ik ben gekke henkie niet.

Hoe ga jij trouwens in een datamodel met slechts 1 tabel data-integriteit gaan afdwingen?

Eeh daar ben ik nog niet helemaal uit. Maar waarschijnlijk zoiets zo dat een class een object is met properties (ook objecten) en dat een property van een property een constraint is.

Als je met objecten werkt, zijn er andere manieren om verschillende objecten in je DB bij te houden.

Verschillende objecten is één (vooraf bekend), maar de mogelijkheid om oneindig veel verschillende objecten opslaan is iets anders.

jurri@n schreef op 09 april 2004 @ 12:07:
Ik heb een systeem gezien waarin dit mogelijk was, maar die had wel meer dan 1 tabel...

1 voor de datatypen, 1 voor de data zelf, en zo verder...

Die oplossing was niet efficient / goed voor de preformance... maar het maakte het wel mogelijk. Het was zeker goed bruikbaar voor kleine sites / applicaties.

Performance is volgens mij een probleem bij elk revolutionair nieuw systeem . Optimalisatie (op low-level niveau) komt later.

[gorgi_19]

seweso schreef op 09 april 2004 @ 12:12:
[...]
Ik ben erg benieuwd wat je redenatie daar achter is.

1 tabel met een referentie naar ID. Past perfect op het FS, lijkt me? Alle opties van relaties etc. afdwingen heb je niet. Gratis row locking zelfs ook nog, database ongebonden. Enige is dat je zelf moet kijken naar een locking mechanisme, maar dat lijkt me niet zo lastig in elkaar te zetten.

Ja maar wat als je van te voren niet weet welke velden er nodig zijn? Dus dat een nono velden moet kunnen toevoegen? Een dynamisch enquete systeem zoals http://www.formdesk.nl/ is hier een mooi voorbeeld van. Waar ik het over heb is om dat laatste nog verder door te voeren waardoor echt alles dynamisch is.

Gaaf, die dynamische enquetemodules..Zelf ook een tijdje in verdiept. Hierbij is niet de applicatie de enquete zelf, maar de enquetemaker. En die enquetemaker moet je normaliseren; een enquete zelf is als gevolg hiervan dus niet te normaliseren (want die is niet bekend ten tijde van het ontwikkelen van de applicatie).

Ik gebruik uiteraard ook indexen, ik ben gekke henkie niet.

Waarbij je bijzonder beperkt bent in het aantal indexen wat je kan gebruiken, omdat je maar 1 tabel hebt en je alleen indexen op kolommen of combinaties hiervan kan leggen.

Performance is volgens mij een probleem bij elk revolutionair nieuw systeem . Optimalisatie (op low-level niveau) komt later.

Als je een nieuw revolutionair systeem bedenkt, akkoord. Maar ga dan niet je oplossing in een bestaand iets proberen te duwen wat er helemaal niet voor gebouwd is.

[ Voor 64% gewijzigd door gorgi_19 op 09-04-2004 12:19 ]

[P_de_B]

seweso schreef op 09 april 2004 @ 12:12:
[...]
Ik ben erg benieuwd wat je redenatie daar achter is.
[...]
Ja maar wat als je van te voren niet weet welke velden er nodig zijn? Dus dat een nono velden moet kunnen toevoegen? Een dynamisch enquete systeem zoals http://www.formdesk.nl/ is hier een mooi voorbeeld van. Waar ik het over heb is om dat laatste nog verder door te voeren waardoor echt alles dynamisch is.
[...]
Ik gebruik uiteraard ook indexen, ik ben gekke henkie niet.

Hoe dan? In de RDBMSen die ik ken is dat niet mogelijk met jouw 'datamodel'


Trouwens, zo revolutionair is jouw idee niet. Het bestaat al lang. Zoek maar eens op object georienteerde databases. Maar dat idee toepassen op een relationele db kun je echt wel vergeten.

[ Voor 15% gewijzigd door P_de_B op 09-04-2004 12:23 ]

[seweso]

gorgi_19 schreef op 09 april 2004 @ 12:14:
[...]

1 tabel met een referentie naar ID. Past perfect op het FS, lijkt me? Alle opties van relaties etc. afdwingen heb je niet. Gratis row locking zelfs ook nog, database ongebonden. Enige is dat je zelf moet kijken naar een locking mechanisme, maar dat lijkt me niet zo lastig in elkaar te zetten.

Ja maar als ik bijvoorbeeld personen in mijn systeem invoer... hoe moet ik dan een persoon zoeken met de schermnaam "gorgi_19"?

Voor het geval dat mensen beginnen te roepen dat dat in één tabel ook niet kan hier in het kort de uitleg: Stel dat gorgi_19 in mijn database onder het id 666 is opgeslagen en dat de eigenschap "schermnaam" het id 123 heeft. Dan is zijn schermnaam op de volgende manier opgeslagen: from=666, type=123, data="gorgi_19". Met een index op type en data kan ik nu met de volgende query een persoon met die naam vinden: "SELECT id FROM `object` WHERE type = '$schermnaam' and data = '$zoekstring'";

Gaaf, die dynamische enquetemodules..Zelf ook een tijdje in verdiept. Hierbij is niet de applicatie de enquete zelf, maar de enquetemaker. En die enquetemaker moet je normaliseren; een enquete zelf is als gevolg hiervan dus niet te normaliseren (want die is niet bekend ten tijde van het ontwikkelen van de applicatie).

[...]

Waarbij je bijzonder beperkt bent in het aantal indexen wat je kan gebruiken, omdat je maar 1 tabel hebt en je alleen indexen op kolommen of combinaties hiervan kan leggen.

Dat is op te lossen door redundante informatie toe te voegen. Dus een soort index/property toe te voegen die gegenereerd word (een normale index in een RDBMS is eigenlijk precies hetzelfde ).

Als je een nieuw revolutionair systeem bedenkt, akkoord. Maar ga dan niet je oplossing in een bestaand iets proberen te duwen wat er helemaal niet voor gebouwd is.

Precies maar ik heb nu even niets beters... ga jij voor mij het systeem in c++ schrijven zodat het op elke hardware snel werkt doordat het toegespitst is op deze manier van werken?

_{als jij je post wijzigd achteraf doe ik dat ook}

[ Voor 40% gewijzigd door seweso op 09-04-2004 12:30 ]

[P_de_B]

seweso schreef op 09 april 2004 @ 12:23:
[...]
Ja maar als ik bijvoorbeeld personen in mijn systeem invoer... hoe moet ik dan een persoon zoeken met de schermnaam "gorgi_19"?

Voor het geval dat mensen beginnen te roepen dat dat in één tabel ook niet kan hier in het kort de uitleg: Stel dat gorgi_19 in mijn database onder het id 666 is opgeslagen en dat de eigenschap "schermnaam" het id 123 heeft. Dan is zijn schermnaam op de volgende manier opgeslagen: from=666, type=123, data="gorgi_19". Met een index op type en data kan ik nu met de volgende query een persoon met die naam vinden: "SELECT id FROM `object` WHERE type = '$schermnaam' and data = '$zoekstring'";

Dus jouw objecten tabel ziet er als volgt uit

Id
type
Data


Hoe sla je nu naw gegevens van een klant op, om maar eens een voorbeeld te noemen?

[gorgi_19]

seweso schreef op 09 april 2004 @ 12:23:
[...]
Ja maar als ik bijvoorbeeld personen in mijn systeem invoer... hoe moet ik dan een persoon zoeken met de schermnaam "gorgi_19"?

Wordt netjes alle bestandjes openen en bekijken. Veel gebruikte operaties lijken me cachable.

Precies maar ik heb nu even niets beters... ga jij voor mij het systeem in c++ schrijven zodat het op elke hardware snel werkt doordat het toegespitst is op deze manier van werken?

Je moet het probleem nu niet opeens naar mij verleggen. Ik geef aan dat de huidige databases niet geschikt zijn om dit efficient af te handelen en er niet voor geschikt zijn. Het is dan niet om mij om het dan maar voor jou op te lossen.

_{als jij je post wijzigd achteraf doe ik dat ook}

mag dat niet meer dan?

[ Voor 3% gewijzigd door gorgi_19 op 09-04-2004 12:32 ]

[EfBe]

TS: Je snapt weinig van relationele modellen en de theorie erachter. Ik daarentegen snap deze thread dan weer niet. Probeer je nu, door je gebrek aan kennis op dit gebied, ons te vertellen dat relationele modellen beter kunnen? Wellicht is het verstandig diep in OODBMS-en te duiken, kom je er vanzelf achter dat rondom het object gewoon een relationeel (heee waar kennen we die van) model is gebouwd.

[seweso]

P_de_B schreef op 09 april 2004 @ 12:29:
Dus jouw objecten tabel ziet er als volgt uit

Id
type
Data

Hoe sla je nu naw gegevens van een klant op, om maar eens een voorbeeld te noemen?

Zoiets ja alleen dan anders. Zie http://test.seweso.com/woovi.php voor voorbeelden.

gorgi_19 schreef op 09 april 2004 @ 12:31:
[...]

Wordt netjes alle bestandjes openen en bekijken. Veel gebruikte operaties lijken me cachable.

[...]

Je moet het probleem nu niet opeens naar mij verleggen. Ik geef aan dat de huidige databases niet geschikt zijn om dit efficient af te handelen en er niet voor geschikt zijn. Het is dan niet om mij om het dan maar voor jou op te lossen.

[...]

mag dat niet meer dan?

Ik dacht dat jij het systeem ging implementeren boven op een FS. Jammer.

En ik zei niet dat dat niet mocht, maar als jij wijzigingen maakt dan kan ik niet achterblijven...anders ziet het er zo raar uit.

En nogmaals: ik heb reeds een werkende applicatie, die ook nog eens razendsnel werkt. Maar:
• Deze versie maakt stiekum gebruik van 2x zoveel tabellen
• Als je wijzigingen in de structuur wil maken (nieuwe classen/nieuwe properties) dan moet je een beetje low-level-ongebruiksvriendelijk dingen toevoegen aan de database (maar het resultaat is coolie!)
• Het is in visual-foxpro gemaakt

Ik zal zo snel mogelijk (als ik thuis ben) hem wel uploaden en hier neerploefen.

[gorgi_19]

Ik dacht dat jij het systeem ging implementeren boven op een FS. Jammer.

Neuh, Relationele databases, al dan niet icm een O/R mapper, is ruim voldoende voor mij.

En nogmaals: ik heb reeds een werkende applicatie, die ook nog eens razendsnel werkt.

Altijd, leuk; wat is snel? Waar bestond je test uit? Waarmee heb je het vergeleken? Hoe groot was je dataset? Hoe groot was de load?

[ Voor 35% gewijzigd door gorgi_19 op 09-04-2004 13:00 ]

[cameodski]

Ik ben erg benieuwd hoe jij met zo'n constructie om wilt gaat met de verschillende datatypes.
Als je bijvoorbeeld een datum in een tekst veld stopt dan wordt het tamelijk lastig om te vergelijken met andere datums en wat denk je van floats.

[ Voor 3% gewijzigd door cameodski op 09-04-2004 12:56 ]

[seweso]

EfBe schreef op 09 april 2004 @ 12:46:
TS: Je snapt weinig van relationele modellen en de theorie erachter. Ik daarentegen snap deze thread dan weer niet. Probeer je nu, door je gebrek aan kennis op dit gebied, ons te vertellen dat relationele modellen beter kunnen? Wellicht is het verstandig diep in OODBMS-en te duiken, kom je er vanzelf achter dat rondom het object gewoon een relationeel (heee waar kennen we die van) model is gebouwd.

Ik heb 'toevallig' een heel onderzoek gedaan op het gebied van OODB's (toen hebben we OODBMS-en ook bekeken). Dus daar weet ik wel het een en ander over. Ik werd alleen niet echt vrolijk van de manier waarop de meeste waren opgebouwd. Je had namelijk nog steeds een statisch classen-diagram nodig. Waarbij je juist een heel stuk dynamiteit mist.

Als je niet die mate van dynamiteit nodig hebt dan moet je natuurlijk alles wat ik hier zeg negeren. Het is wél interessant als je bezig bent met:
• Single-point of defenition
• Objecten
• Dynamisch genereren van user-interfaces
• e.a.

[mulder]

seweso schreef op 09 april 2004 @ 13:05:
[...]
Als je niet die mate van dynamiteit nodig hebt dan moet je natuurlijk alles wat ik hier zeg negeren. Het is wél interessant als je bezig bent met:
• Single-point of defenition
• Objecten
• Dynamisch genereren van user-interfaces
• e.a.

Kan hier niet echt voordelen in zien die voor jou systeem gelden. Deze dingen kunnen net zo makkelijk in een ander systeem.

[Verwijderd]

Heb je toevallig je systeem ook al eens getest met een flink gevulde database?

Zal een leuke performance geven. Waarom gaan we niet gewoon grep met een regex gebruiken op een tekstfile dan?

Wat wil je gaan doen tegen dataduplicatie/dataintegriteit, want daar ontkom je simpelweg gewoon niet aan?

Of wil je gaan zeggen, dat je ook niet vastlegt hoe data in de tabel moet komen staan (ofwel dat velden gewoon willekeurig gevuld kunnen worden afhankelijk van het type object).

Verder is het kul om als argument aan te dragen dat het afwezig zijn van joins voordelen biedt en dat dat dus een sterk argument is om maar 1 tabel te gebruiken. Zeker als je dus niet eens vast kunt leggen hoe je data er uit moet zien.

Tot slot....dynamiteit?!?! Als je zorgt voor een goed datamodel dan kun je op een fatsoenlijke en nette manier uitbreidingen in de toekomst maken. Moet je alleen wel weten waar je mee bezig bent ja.

I.m.o. doe je alsof je heel erg veel verstand van zaken hebt, maar alles wijst erop dat je nog een heleboel te leren hebt...... (NOFI)

[Creepy]

Affijn, wat zitten we weer vast aan traditionele ideeen.

Seweso stipt wel een interresant punt aan. Ikzelf weet er niet precies het fijne van, maar wat ik wel weet is dat er bedrijven zijn, met een produkt dat draait op een redelijk gevulde database (HRM systeem) die een database gebruiken met daarin maar 1 tabel met al hun data (draait Oracle). VOor dataexport e.d. maken ze dan weer een "gekantelde" database aan waar alles weer in "normale" tabellen staan zodat op een "normale" manier alle data benadert kan worden.

Voor deze opzet is gekozen vanwege performance (!!) en flexibiliteit.

Concluse: Ja het is goed mogeljk om te doen, ja het kan zeker snel genoeg zijn, met SP e.d. is dataintegriteit e.d. ook te bewaken. En ja, met een "normaal" database model kan dit ook.

Dat de voordelen die Seweso noemt niet erg relevant zijn (het is cool? ), is weer een verhaal apart

[ Voor 18% gewijzigd door Creepy op 09-04-2004 13:46 ]

[bille]

ik heb de opmerking gedeeltelijk voorbij zien komen, maar nogmaals:
De constraints in je datamodel zijn een onderdeel van je businesslogica. Een relationele database leent zich daar ook uitermate goed voor, dmv uniciteitsconstraints, unique indexes e.d. Een dynamisch model is aardig, maar je hebt totaal geen controle over de data op DB niveau waardoor je per definitie alle businesslogica in de applicatie moet bouwen. Opzich is dat geen ramp, zij het dat je totaal geen inzicht meer hebt in de opgeslagen data zonder je applicatie, hetgeen imho niet wenselijk is. Tevens krijg je één tabel met enkele honderduizenden rijen (bij een beetje fatsoenlijke applicatie) waarin je bijv. op username (text) wilt gaan zoeken hetgeen performance wise ook geen pretje is.

Ik heb zelf ook wel eens gespeeld met de gedachte, maar kwam zelf tot de conclusie dat een volledig dynamisch model niet te prefereren valt boven een gedeeltelijk dynamisch model, waarbij je bijv. kiest voor het datamodelmatig dynamisch maken van objecten waarvan je verwacht dat ze uitbreiden wat betreft attributen. Het moet ook een beargumenteerbare keuze zijn: Ben jij in je applicatie genoodzaakt om een volledig dynamisch model te bouwen gebasseerd op 1 tabel? Zo niet, dan zou ik het niet doen, zo wel.. dan is er niets mis mee

Het datamodel dat de TS heeft gemaakt zou ik uitbreiden met tabellen die veel gebruikte statische objecten representeren (users etc.).

[GrimaceODespair]

bille schreef op 09 april 2004 @ 13:34
maar je hebt totaal geen controle over de data op DB niveau waardoor [...] je totaal geen inzicht meer hebt in de opgeslagen data zonder je applicatie

Maar dat geldt natuurlijk voor alles wat digitaal is. De vraag of informatie beheerbaar is, komt altijd neer op de vraag: bestaan er applicaties voor? De bits op je HD zijn ook niet beheerbaar zonder een OS.

[cameodski]

Creepy schreef op 09 april 2004 @ 13:26:
Concluse: Ja het is goed mogeljk om te doen, ja het kan zeker snel genoeg zijn, met SP e.d. is dataintegriteit e.d. ook te bewaken. En ja, met een "normaal" database model kan dit ook.

Ja ja. En wil je dan ook controleren of bijvoorbeeld een datum ook echt een datum is? En hoe wil je unique constraints leggen? Moet je die ook dynamisch aanbrengen.
En als je nu meerdere foreign keys hebt, hoe gaan we dat dan oplossen?

Voor een beperkt aantal toepassingen is het misschien wel mogelijk, maar er kleven zo veel nadelen aan mbt integriteit, performance e.d. dat je toch eerst wel twintig keer achter je oren moet krabben, voordat je zoiets gaan doen.

[seweso]

bille schreef op 09 april 2004 @ 13:34:
ik heb de opmerking gedeeltelijk voorbij zien komen, maar nogmaals:
De constraints in je datamodel zijn een onderdeel van je businesslogica. Een relationele database leent zich daar ook uitermate goed voor, dmv uniciteitsconstraints, unique indexes e.d. Een dynamisch model is aardig, maar je hebt totaal geen controle over de data op DB niveau waardoor je per definitie alle businesslogica in de applicatie moet bouwen. Opzich is dat geen ramp, zij het dat je totaal geen inzicht meer hebt in de opgeslagen data zonder je applicatie, hetgeen imho niet wenselijk is. Tevens krijg je één tabel met enkele honderduizenden rijen (bij een beetje fatsoenlijke applicatie) waarin je bijv. op username (text) wilt gaan zoeken hetgeen performance wise ook geen pretje is.

Ik heb zelf ook wel eens gespeeld met de gedachte, maar kwam zelf tot de conclusie dat een volledig dynamisch model niet te prefereren valt boven een gedeeltelijk dynamisch model, waarbij je bijv. kiest voor het datamodelmatig dynamisch maken van objecten waarvan je verwacht dat ze uitbreiden wat betreft attributen. Het moet ook een beargumenteerbare keuze zijn: Ben jij in je applicatie genoodzaakt om een volledig dynamisch model te bouwen gebasseerd op 1 tabel? Zo niet, dan zou ik het niet doen, zo wel.. dan is er niets mis mee

Het datamodel dat de TS heeft gemaakt zou ik uitbreiden met tabellen die veel gebruikte statische objecten representeren (users etc.).

Ik hou van je! Jij snapt het. Er zijn inderdaad hybride oplossingen mogelijk waar je bepaalde gegevens 'normaal' opslaat en wanneer je een dynamisch aantal velden/eigenschappen nodig hebt gebruik je een systeem zoals deze.`

Wat ik hier merk is dat iedereen een beetje denkt in zijn/haar straatje, dus het project waar ze nu mee bezig zijn. En dus dat je het vaak niet nodig hebt. Toevallig kom ik wél veel problemen tegen waar ik oplossingen zoals ik hier aandraag nodig heb:
• Een ziekteverzuim programma waarbij je een x aantal verschillende documenten moet opleveren als iemand een x dagen ziek is. Daarbij heeft elk document een x aantal vragen die beantwoord moet worden. Nu had ik voor elk document-type een aparte tabel kunnen maken, of een meer generieke oplossing bouwen waardoor de GUI gegegeneerd word met dezelfde informatie die het systeem om de documenten in pdf-formaat te genereren.
• Een systeem voor telemarketing om antwoorden in te voeren. Het lijkt me vanzelfsprekend dat je niet voor elk script gaat lopen programeren c.q. een datamodel gaat maken.

[Jacco Swart]

seweso schreef op 09 april 2004 @ 14:07:
[...]
• Een systeem voor telemarketing om antwoorden in te voeren. Het lijkt me vanzelfsprekend dat je niet voor elk script gaat lopen programeren c.q. een datamodel gaat maken.

Dit kan je toch makkelijk oplossen met relationele database? Je kan toch een model maken met vragen en daaraan een id en dan een tabel met antwoorden en daarin een id?

[gorgi_19]

seweso schreef op 09 april 2004 @ 14:07:
• Een ziekteverzuim programma waarbij je een x aantal verschillende documenten moet opleveren als iemand een x dagen ziek is. Daarbij heeft elk document een x aantal vragen die beantwoord moet worden. Nu had ik voor elk document-type een aparte tabel kunnen maken, of een meer generieke oplossing bouwen waardoor de GUI gegegeneerd word met dezelfde informatie die het systeem om de documenten in pdf-formaat te genereren.
• Een systeem voor telemarketing om antwoorden in te voeren. Het lijkt me vanzelfsprekend dat je niet voor elk script gaat lopen programeren c.q. een datamodel gaat maken.

Ook dit lijkt me goed te maken met een relationeel database model. Wat is je applicatie? Niet het betreffende formulier. Ook niet de betreffende vragenlijst. Je maakt een formuliergenerator-applicatie, niet een formulier an sich.

[Creepy]

seweso schreef op 09 april 2004 @ 14:07:
[...]
Ik hou van je! Jij snapt het. Er zijn inderdaad hybride oplossingen mogelijk waar je bepaalde gegevens 'normaal' opslaat en wanneer je een dynamisch aantal velden/eigenschappen nodig hebt gebruik je een systeem zoals deze.`

Wat ik hier merk is dat iedereen een beetje denkt in zijn/haar straatje, dus het project waar ze nu mee bezig zijn. En dus dat je het vaak niet nodig hebt. Toevallig kom ik wél veel problemen tegen waar ik oplossingen zoals ik hier aandraag nodig heb:
• Een ziekteverzuim programma waarbij je een x aantal verschillende documenten moet opleveren als iemand een x dagen ziek is. Daarbij heeft elk document een x aantal vragen die beantwoord moet worden. Nu had ik voor elk document-type een aparte tabel kunnen maken, of een meer generieke oplossing bouwen waardoor de GUI gegegeneerd word met dezelfde informatie die het systeem om de documenten in pdf-formaat te genereren.
• Een systeem voor telemarketing om antwoorden in te voeren. Het lijkt me vanzelfsprekend dat je niet voor elk script gaat lopen programeren c.q. een datamodel gaat maken.

Ik mag dan net wel gezegd hebben dat ik het redelijk met je eens ben, maar nu toch niet meer
Je kan dit prima in een normaal relationeel model opslaan (edit: *pets* Wat gorgi_19 zegt dus)

[EfBe]

Wat ik hier merk is dat iedereen een beetje denkt in zijn/haar straatje, dus het project waar ze nu mee bezig zijn.

Nee niet echt, want dan zou ik puur vanuit OO DB's denken.

Ik snap alleen nooit de volledig niet onderbouwde redenaties die denormalization prediken en willens en wetens maar zo'n algemeen mogelijke bak maken. Zoals ik al in een andere thread zei: Je hebt maar 1 table nodig en 2 fields: ID (GUID) en Data (Blob). In Data serialize je je object en klaar ben je. Toch? Nou niet echt.

En deze opmerking geeft aan dat je er niets van snapt:

Er zijn inderdaad hybride oplossingen mogelijk waar je bepaalde gegevens 'normaal' opslaat en wanneer je een dynamisch aantal velden/eigenschappen nodig hebt gebruik je een systeem zoals deze.

Als je werkelijk denkt dat je generic databuckets nodig hebt omdat je anders dit soort gegevens niet kwijt kunt, begrijp je iets niet, nl. dat het mechanisme wat (mede) gegevens in informatie omzet de meta-data is die het model beschrijft waar de data in is opgeslagen, m.a.w. je relationele model.

Het lijkt me vanzelfsprekend dat je niet voor elk script gaat lopen programeren c.q. een datamodel gaat maken.

Lijkt me ook niet, maar daarom kun je hier nog wel een goed, correct relationeel model voor maken. Als je denkt van niet, zou ik het toch nog maar eens bekijken. Ik weet uit ervaring dat het kan.

Een ziekteverzuim programma waarbij je een x aantal verschillende documenten moet opleveren als iemand een x dagen ziek is. Daarbij heeft elk document een x aantal vragen die beantwoord moet worden. Nu had ik voor elk document-type een aparte tabel kunnen maken, of een meer generieke oplossing bouwen waardoor de GUI gegegeneerd word met dezelfde informatie die het systeem om de documenten in pdf-formaat te genereren.

Dit predikt ook weer de hotseknots methodiek die je toepast om je modellen te maken. Gebruik eens een modelleringstechniek als NIAM of ORM! Dit is zo simpel dat ik me echt afvraag of je er wel goed over nadenkt.

Verder maak je de beginnersfout door de GUI erbij te betrekken. Een relationeel model staat op zichzelf en moet t.a.t. worden gemodelleerd los van wat voor gui dan ook. De GUI reflecteert functionaliteit, je relationele model reflecteert hoe de data in de database zich tot elkaar verhoudt. De kauwgom ertussen is je programma. Mensen die liever lui dan moe zijn maken een database met voor elk scherm een tabel en programmeren de db logica direct achter de GUI (De OK / Save knop's handler is vaak erg lang).

Mag van mij hoor, maar ga het niet verkondigen als zijnde de juiste manier om software te bouwen. En al helemaal niet je gelijk proberen te halen door te verkondigen dat ieder weer in zn eigen straatje denkt.

[seweso]

Nu word het interessant: waarom is het wel 'normaal' om een dynamische aantal velden/eigenschappen de faciliteren t.b.v. documenten, maar niet voor generieke objecten?

Volgens mij kun je nog steeds een relationeel model hebben als je maar één tabel hebt:

code:

Database woovi wordt uitgevoerd op localhost 
# phpMyAdmin SQL Dump
# version 2.5.6
# http://www.phpmyadmin.net
#
# Host: localhost
# Generatie Tijd: 09 Apr 2004 om 14:35
# Server versie: 4.0.14
# PHP Versie: 4.3.3
# 
# Database : `woovi`
# 

# --------------------------------------------------------

#
# Tabel structuur voor tabel `object`
#

CREATE TABLE `object` (
  `id` bigint(20) NOT NULL auto_increment,
  `from` bigint(20) NOT NULL default '0',
  `type` bigint(20) NOT NULL default '0',
  `data` text NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `from` (`from`,`type`),
  KEY `zoek` (`data`(64),`type`),
  FULLTEXT KEY `data` (`data`)
) TYPE=MyISAM AUTO_INCREMENT=1 ;

#
# COMMENTS FOR TABLE `object`:
#   `data`
#       `de fysieke data die word bijgehouden`
#   `from`
#       `het object waar gegevens voor worden opgeslagen`
#   `id`
#       `uniek id`
#   `type`
#       `het type data wat word bijgehouden`
#

#
# RELATIONS FOR TABLE `object`:
#   `from`
#       `object` -> `id`
#   `type`
#       `object` -> `id`
#

[ Voor 5% gewijzigd door seweso op 09-04-2004 14:36 . Reden: Wijziging indexen ]

[Creepy]

seweso schreef op 09 april 2004 @ 14:33:
Nu word het interessant: waarom is het wel 'normaal' om een dynamische aantal velden/eigenschappen de faciliteren t.b.v. documenten, maar niet voor generieke objecten?

Volgens mij kun je nog steeds een relationeel model hebben als je maar één tabel hebt:

Ja het kan. Of het verstandig is, is een tweede. Zoals ik al zei ken ik een produkt dat gebruikt maakt van 1 tabel in een normale relationele DB. De snelheid van het produkt stond ik versteld van (lees: supersnel met veel data). Ik kan je echter wel vertellen dat er flink wat onderzoek aan is vooraf gegaan voordat ze dat voor elkaar hadden. Het werkt in elk geval niet op de manier zoals jij nu beschrijft.

[cameodski]

En hoe wil je nu zoeken mbv een index? Op een memo veld een index leggen, kan niet of is tamelijk zinloos.

[seweso]

Creepy schreef op 09 april 2004 @ 14:39:
[...]

Ja het kan. Of het verstandig is, is een tweede. Zoals ik al zei ken ik een produkt dat gebruikt maakt van 1 tabel in een normale relationele DB. De snelheid van het produkt stond ik versteld van (lees: supersnel met veel data). Ik kan je echter wel vertellen dat er flink wat onderzoek aan is vooraf gegaan voordat ze dat voor elkaar hadden. Het werkt in elk geval niet op de manier zoals jij nu beschrijft.

Ik ben hier al vanaf 1998 over na aan het denken, en dé manier om dit systeem te verwerkelijken heb ik nog niet gevonden. Als het in eerste instantie af is dan is het een soort combinatie van formdesk, phpMyadmin en MsAccess.

Aan de andere kant denk ik dat het niet zo moeilijk moet zijn aangezien ik de eerste test versie in een week in elkaar heb gezet (screenshots volgen zsm).

[seweso]

cameodski schreef op 09 april 2004 @ 14:45:
En hoe wil je nu zoeken mbv een index? Op een memo veld een index leggen, kan niet of is tamelijk zinloos.

Dat heb ik hier boven ergens al uitgelegd en daarnaast heb ik in het voorbeeld data-model al de benodigde index gelegd: KEY `zoek` (`data`(64),`type`)

[Creepy]

seweso schreef op 09 april 2004 @ 14:49:
[...]

Aan de andere kant denk ik dat het niet zo moeilijk moet zijn aangezien ik de eerste test versie in een week in elkaar heb gezet (screenshots volgen zsm).

Moeilijk zoals jij het nu doet is het niet nee. Het wordt echter wel moeilijk als je per "type" tien duizenden records hebt plus historische data, en het dan nog snel wilt houden(dat HRM systeem waar ik het over had, heeft dat dus, en draait toch supersnel).

En met die fulltext keys krijg je het naar mijn idee niet supersnel.

[ Voor 8% gewijzigd door Creepy op 09-04-2004 14:56 ]

[whoami]

seweso schreef op 09 april 2004 @ 14:33:
Volgens mij kun je nog steeds een relationeel model hebben als je maar één tabel hebt:

Als je alle eigenschappen in één veld gaat gaan serializen, dan is het 'relationeel' in je model gauw weg.

[whoami]

seweso schreef op 09 april 2004 @ 14:51:
[...]


Dat heb ik hier boven ergens al uitgelegd en daarnaast heb ik in het voorbeeld data-model al de benodigde index gelegd: KEY `zoek` (`data`(64),`type`)

Nee, ik wil alle records die een 'eigenschap' 'naam' hebben, en waarvoor die naam begint met 'DE'

[cameodski]

seweso schreef op 09 april 2004 @ 14:51:
Dat heb ik hier boven ergens al uitgelegd en daarnaast heb ik in het voorbeeld data-model al de benodigde index gelegd: KEY `zoek` (`data`(64),`type`)

Ja, dat heb ik wel gelezen, maar jij wilt een full-text index gebruiken om te zoeken. Maar hoe wil je dan bijvoorbeeld zoeken op bijvoorbeeld een datum range oid. Stel: je hebt klanten met facturen en nu wil je alle facturen van maart hebben. Dit zoeken doe je dan op basis van een factuurdatum, maar hoe .... ???

Een bijkomend probleem is ook nog dat je ergens een lijst met gaan bijhouden met wat al die types voorstellen met daarbij behorende logica. Vind je dat erg flexibel?

Ik denk dat je zo gauw als je business logica moet coderen, je dan ook wel even de tabel aan kunt passen, maar als het echt alleen maar invul-opvraag objecten of properties zijn, ja dan kan dat volgens mij ook wel dynamisch.

[ Voor 19% gewijzigd door cameodski op 09-04-2004 15:03 ]

[seweso]

cameodski schreef op 09 april 2004 @ 15:01:
[...]

Ja, dat heb ik wel gelezen, maar jij wilt een full-text index gebruiken om te zoeken. Maar hoe wil je dan bijvoorbeeld zoeken op bijvoorbeeld een datum range oid. Stel: je hebt klanten met facturen en nu wil je alle facturen van maart hebben. Dit zoeken doe je dan op basis van een factuurdatum, maar hoe .... ???

Een bijkomend probleem is ook nog dat je ergens een lijst met gaan bijhouden met wat al die types voorstellen met daarbij behorende logica. Vind je dat erg flexibel?

Ik denk dat je zo gauw als je business logica moet coderen, je dan ook wel even de tabel aan kunt passen, maar als het echt alleen maar invul-opvraag objecten of properties zijn, ja dan kan dat volgens mij ook wel dynamisch.

Ja eeh ik weet niet helemaal wat er in mijn hoofd omging toen ik die index op data+type legde maar die moet inderdaad andersom.

edit:
Een specifiek antwoord op je vraag: de eigenschap 'factuurdatum' heeft een id van 77, dan kun je alle facturen opvragen met "SELECT id FROM `object` WHERE type = 77 and data LIKE '2004-03%'" (soms doen likes niet helemaal wat je wil maar dan kun je uiteraard < en > gebruiken)

Inderdaad, het systeem gaat alle classen en eigenschappen intern opslaan (uiteraard allemaal in dezelfde tabel). Dat kun jij zien als een negatief punt, maar dat vind ik juist handig. Maar ja dat doet een RDBMS natuurlijk ook, dus ik zie het verschil niet.

Volgens mij heb ik nooit echt te maken gehad met heel uitgebreide business-logica... daardoor zal ik automatisch daar niet zo zwaar aan tillen. Maar ja ik wil ook geen ERP applicatie er mee maken. Eerder een knowledge-base, of misschien een crm-systeem.

Ooh misschien vinden jullie dit interessant: ik heb een online-crm systeem gebouwd welke in essentie ook maar één tabel gebruikt (exclusief een gebruikers, projecten tabel)... misschien lijd ik wel aan een ziekte

Nou ja ik hou gewoon heel erg van recursie en simplisme.

[ Voor 8% gewijzigd door seweso op 09-04-2004 15:28 . Reden: Specfieker antwoord op vraag ]

[EfBe]

Inderdaad, het systeem gaat alle classen en eigenschappen intern opslaan (uiteraard allemaal in dezelfde tabel). Dat kun jij zien als een negatief punt, maar dat vind ik juist handig. Maar ja dat doet een RDBMS natuurlijk ook, dus ik zie het verschil niet.

Heh, grapjas

Ik ken geen RDBMS dat metadata in 1 tabel opslaat. Sterker nog, het zijn er veelal meer dan 5.

Verder is je systeempje zo brak als wat. Sla de volgende gegevens eens op:
Customer (met CustomerID en andere relevante velden), Order (met o.a. CustomerID die verwijst naar Customer), Order Details (met als ID OrderID en ProductID en wat relevante velden) en Product (met ProductID en wat relevante velden, o.a. land van herkomst).

Welnu, ik wil graag alle klanten die een product hebben gekocht uit Zweden.

Veel plezier met je ene table.

[ Voor 37% gewijzigd door EfBe op 09-04-2004 15:34 ]

[cameodski]

seweso schreef op 09 april 2004 @ 15:24:

edit:
Een specifiek antwoord op je vraag: de eigenschap 'factuurdatum' heeft een id van 77, dan kun je alle facturen opvragen met "SELECT id FROM `object` WHERE type = 77 and data LIKE '2004-03%'" (soms doen likes niet helemaal wat je wil maar dan kun je uiteraard < en > gebruiken)

Goed, dan gaan we het nu wat ingewikkelder maken:
Je wilt verder alleen de facturen van de klanten uit Amsterdam en het factuurbedrag moet tussen 100 en 1000 euro zitten. En de facturen moeten ook al betaald zijn. Verder wil ik alleen de klanten van accountmanager A hebben (foreign key in klanten tabel).

seweso schreef op 09 april 2004 @ 15:24:
Volgens mij heb ik nooit echt te maken gehad met heel uitgebreide business-logica... daardoor zal ik automatisch daar niet zo zwaar aan tillen. Maar ja ik wil ook geen ERP applicatie er mee maken. Eerder een knowledge-base, of misschien een crm-systeem.

Kijk, dat verklaart al heel wat. Niet negatief bedoelt, maar als er veel business logica om de hoek kunt kijken, waarbij je veel properties nodig hebt dan wordt het opzoeken, filteren e.d. echt knap lastig.

Ik heb wel queries geschreven met 50 of meer joins. Als ik jouw oplossing gebruik, worden dat er al snel zo'n 5000 denk ik.

[ Voor 7% gewijzigd door cameodski op 09-04-2004 15:42 ]

[seweso]

EfBe schreef op 09 april 2004 @ 15:31:
[...]

Heh, grapjas

Ik ken geen RDBMS dat metadata in 1 tabel opslaat. Sterker nog, het zijn er veelal meer dan 5.

Verder is je systeempje zo brak als wat. Sla de volgende gegevens eens op:
Customer (met CustomerID en andere relevante velden), Order (met o.a. CustomerID die verwijst naar Customer), Order Details (met als ID OrderID en ProductID en wat relevante velden) en Product (met ProductID en wat relevante velden, o.a. land van herkomst).

Welnu, ik wil graag alle klanten die een product hebben gekocht uit Zweden.

Veel plezier met je ene table.

Ik heb al een systeem gemaakt waar ik de definitie én de data in dezelfde tabel opsla! Volgens mij geloven jullie mij gewoon niet. Maar jullie lachen wel anders als ik de wereld heb veroverd met mijn super-systeem.

En ik ga zeker die voorbeeld-case implementeren in mijn (ietwat denkbeeldige systeem) ... maar nu even niet. Ik moet nu even een overgedragen afspraak die via een crm-systeem van een klant binnenkomt, via een automatische koppeling met onze database intanken. Ik groet u allen

[Creepy]

seweso schreef op 09 april 2004 @ 15:50:
[...]

En ik ga zeker die voorbeeld-case implementeren in mijn (ietwat denkbeeldige systeem) ... maar nu even niet. Ik moet nu even een overgedragen afspraak die via een crm-systeem van een klant binnenkomt, via een automatische koppeling met onze database intanken. Ik groet u allen

offtopic:
Je hoeft je werkzaamheden hier niet te melden hoor, er zitten hier wel meer mensen die een baan hebben in de IT wereld...

[ Voor 9% gewijzigd door Creepy op 09-04-2004 16:08 ]

[seweso]

Creepy schreef op 09 april 2004 @ 16:03:[...]

offtopic:
Je hoeft je werkzaamheden hier niet te melden hoor, er zitten hier wel meer mensen die een baan hebben in de IT wereld...

offtopic:
Het was meer bedoeld voor mezelf om te zorgen dat ik ook daadwerkelijk weer aan het werk zou gaan ... , maar ik zal het niet meer doen hoor.

[Jaspertje]

Ik denk dat de user meer naar een DataWarehouse gaat dan naar een database model..

De performance die je verliest door joins te gebruiken, win je weer terug doordat je door veel minder records hoeft te zoeken. Bij 5 records zal het misschien nog wel sneller zijn wat de TS aandraagt, maar als er een miljoen instaan??

En verwijder eens iets. Als ik dat in een SQL Server doe die goede relaties (inclusief cascade delete heeft) dan is dat zo gebeurt. Hoe doet de TS dat?

En hoe zit het met de groote van de database? (ik weet niet hoe de db een ntext(16) opslaat, maar als ie daar altijd een bepaalde grootte voor reserveerd, dan is dat ook een issiue)

[EfBe]

seweso schreef op 09 april 2004 @ 15:50:
Ik heb al een systeem gemaakt waar ik de definitie én de data in dezelfde tabel opsla! Volgens mij geloven jullie mij gewoon niet. Maar jullie lachen wel anders als ik de wereld heb veroverd met mijn super-systeem.

Luistert. Ik heb in mijn leven al zoveel verschrikkelijke systemen mogen aanschouwen en helaas ermee moeten werken/uitbreiden, dat ik je best geloven wil dat je zo'n systeem hebt gebouwd. Dat het een super-systeem is... daar geloof ik helemaal niks van. Al jaren komt de ene na de andere grapjas naar boven drijven die het ei van columbus gevonden heeft en de meest fantastische db structuur heeft bedacht. In de research die wordt gedaan (al 25+ jaar) naar databases zal best enige progressie in zitten, maar zolang jouw systeem niet echt voorkomt in een boek van Celko (lees eens SQL for Smarties) geloof ik niet dat je iets revolutionairs op het spoor bent, immers Celko e.a. zijn al jaren full time aan het zoeken naar de meest optimale setup voor bepaalde situaties.

[ Voor 4% gewijzigd door EfBe op 09-04-2004 17:10 ]

[seweso]

Jaspertje schreef op 09 april 2004 @ 16:27:
Ik denk dat de user meer naar een DataWarehouse gaat dan naar een database model..

De performance die je verliest door joins te gebruiken, win je weer terug doordat je door veel minder records hoeft te zoeken. Bij 5 records zal het misschien nog wel sneller zijn wat de TS aandraagt, maar als er een miljoen instaan??

En verwijder eens iets. Als ik dat in een SQL Server doe die goede relaties (inclusief cascade delete heeft) dan is dat zo gebeurt. Hoe doet de TS dat?

En hoe zit het met de groote van de database? (ik weet niet hoe de db een ntext(16) opslaat, maar als ie daar altijd een bepaalde grootte voor reserveerd, dan is dat ook een issiue)

Persoonlijk denk ik dat wat ik voorstel in elke situatie langzamer is. Het gaat om gebruikers-gemak bij de ontwikkelaar. Neem bijvoorbeeld visual-basic: je weet dat als je daarmee een programma maakt dat het programma groter en slower zal zijn. Maar dat kan jou geen worst schelen want je hebt het programma binnen no-time in elkaar gezet. Je moet alleen niet denken dat je met VB een heel office-pakket in elkaar kan zetten, of een programma als 3dsmax. Of wat ik hier bedenk ooit echte (in tegenstelling tot theoretische) genoeg voordelen heeft die opwegen tegen de nadelen is iets wat ik graag te weten kom.

Cascading deletes kan hier ook boven-op geimplementeerd worden. Je kunt je voorstellen dat bij het verwijderen van een object het systeem weet welke kinderen mee-verwijdert moeten worden.

Het systeem zal qua grootte ook alles behalve efficient zijn (minimaal een factor 4 groter), daar zal ik eerlijk in zijn

EfBe schreef op 09 april 2004 @ 17:08:
[...]


Luistert. Ik heb in mijn leven al zoveel verschrikkelijke systemen mogen aanschouwen en helaas ermee moeten werken/uitbreiden, dat ik je best geloven wil dat je zo'n systeem hebt gebouwd. Dat het een super-systeem is... daar geloof ik helemaal niks van. Al jaren komt de ene na de andere grapjas naar boven drijven die het ei van columbus gevonden heeft en de meest fantastische db structuur heeft bedacht. In de research die wordt gedaan (al 25+ jaar) naar databases zal best enige progressie in zitten, maar zolang jouw systeem niet echt voorkomt in een boek van Celko (lees eens SQL for Smarties) geloof ik niet dat je iets revolutionairs op het spoor bent, immers Celko e.a. zijn al jaren full time aan het zoeken naar de meest optimale setup voor bepaalde situaties.

Ik heb ook mijn hele leven al met verschrikkelijk systemen mogen werken, dat is bij mij juist de reden om te denken dat dat beter zou moeten kunnen. Ik heb het alleen niet over systemen voor eind-gebruikers maar de ontwikkel-tools en omgevingen voor software ontwikkelaars. Daarnaast als ik nu iets zou bedenken wat al in boeken staat dan hoef ik het niet meer te bedenken toch?

Ik wil hier niet bewijzen dat wat ik bedacht een super-oplossing is, want dat is het simpelweg nog niet. Ik wil laten zien dat je een heel systeem kan bouwen met maar één tabel. Ik verbaas me dat er nog steeds mensen zijn die denken dat dat niet kan. Ik zou jullie allemaal dom kunnen noemen maar daar hebben we niks aan, het zal vast aan mijn uitleg-kwaliteiten liggen. Ik zal m.b.v. met jouw voorbeeld uitleggen hoe ik een hele classen-definitie plus data in één tabel poep. Ff geduld....


Hèhè, ik heb het screen-shot klaar (klik voor groter formaat):

[Creepy]

seweso schreef op 09 april 2004 @ 18:52:
[...]
Ik wil hier niet bewijzen dat wat ik bedacht een super-oplossing is, want dat is het simpelweg nog niet. Ik wil laten zien dat je een heel systeem kan bouwen met maar één tabel. Ik verbaas me dat er nog steeds mensen zijn die denken dat dat niet kan. Ik zou jullie allemaal dom kunnen noemen maar daar hebben we niks aan, het zal vast aan mijn uitleg-kwaliteiten liggen.

Eeeeh, het commentaar is niet dat het niet kan, tuurlijk kan het, daar is iedereen wel van overtuigd. Of het slim is om te doen, en of het goed is voor de kwaliteit en snelheid van je DB en applicatie, daar wordt nogal aan getwijfeld

Edit: ik hoop dat de persoonsinfo in je screenshot verzonnen is. Anders is het verstandig dat even te verbergen.

[ Voor 8% gewijzigd door Creepy op 09-04-2004 19:02 ]

[seweso]

Creepy schreef op 09 april 2004 @ 19:01:
[...]

Eeeeh, het commentaar is niet dat het niet kan, tuurlijk kan het, daar is iedereen wel van overtuigd. Of het slim is om te doen, en of het goed is voor de kwaliteit en snelheid van je DB en applicatie, daar wordt nogal aan getwijfeld

Edit: ik hoop dat de persoonsinfo in je screenshot verzonnen is. Anders is het verstandig dat even te verbergen.

Fijn dat jij het snapt, maar er zijn nog steeds van die mensen... En denk je dat PHP meteen zo snel was als nu? Dat was in het begin gewoon een idee, en daarna een makkelijke manier om websites in elkaar te flansen.... en toen kwam Zend. Zoiets als Zend is way-out-of-my-leage, maar iets versimpelen zou theoretisch moeten lukken. Ooh en als iedereen het snapt... dan zou de discussie toch moet ophouden? Of zeggen we stiekum telkens hetzelfde?

offtopic:
Ik heb nooit zo begrepen waarom iedereen die persoonlijke gegevens telkens weghaalt, doe een whois op seweso.com en je hebt de gegevens ook ... Ik zie het nu niet van het verbergen in.

[whoami]

seweso schreef op 09 april 2004 @ 18:52:
[...]


Persoonlijk denk ik dat wat ik voorstel in elke situatie langzamer is. Het gaat om gebruikers-gemak bij de ontwikkelaar. Neem bijvoorbeeld visual-basic: je weet dat als je daarmee een programma maakt dat het programma groter en slower zal zijn. Maar dat kan jou geen worst schelen want je hebt het programma binnen no-time in elkaar gezet. Je moet alleen niet denken dat je met VB een heel office-pakket in elkaar kan zetten, of een programma als 3dsmax. Of wat ik hier bedenk ooit echte (in tegenstelling tot theoretische) genoeg voordelen heeft die opwegen tegen de nadelen is iets wat ik graag te weten kom.

Slechte vergelijking.
Met jouw systeem heb je gewoon een relationeel model dat perfect zou zijn voor een bepaalde situatie vernaggeld.
Jij vind het misschien makkelijk om te ontwikkelen, maar iemand anders die het moet onderhouden (of jij die er na 2 jaar een aanpassing moet aandoen) zal jou (of jij jezelf) vervloeken.
Mocht ik ooit zo iets tegen komen, dan begin ik gewoon opnieuw.
Ik mag blij zijn dat ik zo geen mensen in m'n team heb.

(Trouwens, gebruikersgemak voor een ontwikkelaar bestaat niet. Een ontwikkelaar moet een goede applicatie afleveren, eentje die ten alle tijde betrouwbaar, performant en stabiel is. Iets wat je met dit systeem niet kunt garanderen.

Het systeem zal qua grootte ook alles behalve efficient zijn (minimaal een factor 4 groter), daar zal ik eerlijk in zijn

Wat zijn de voordelen dan wel?
Ik bedoel, waar springt dat systeem dan wel in uit?

Ik heb ook mijn hele leven al met verschrikkelijk systemen mogen werken, dat is bij mij juist de reden om te denken dat dat beter zou moeten kunnen. Ik heb het alleen niet over systemen voor eind-gebruikers maar de ontwikkel-tools en omgevingen voor software ontwikkelaars. Daarnaast als ik nu iets zou bedenken wat al in boeken staat dan hoef ik het niet meer te bedenken toch?

Vraag eens aan 1000 doorwinterde ontwikkelaars welk systeem ze makkelijker, begrijpbaarder, onderhoudbaarder, etc.... vinden...

Ik wil laten zien dat je een heel systeem kan bouwen met maar één tabel.
Ik verbaas me dat er nog steeds mensen zijn die denken dat dat niet kan.

Mjah, je kan ook met je fiets via Berlijn naar Barcelona rijden.

Ik zou jullie allemaal dom kunnen noemen maar daar hebben we niks aan, het zal vast aan mijn uitleg-kwaliteiten liggen.

Ik denk dat er hier een pak mensen zitten met veel meer ervaring dan jij, die al serieuze systemen gebouwd hebben, en al veel slechte ideeën gezien hebben.
Ik zal eerlijk zijn: zo'n absurd idee als dit (een relationeel model in 1 tabel gieten) heb ik nog nooit gezien, en ik hoop dat ik het ook nooit zal zien.

[GrimaceODespair]

whoami schreef op 10 april 2004 @ 00:43:
Ik denk dat er hier een pak mensen zitten met veel meer ervaring dan jij, die al serieuze systemen gebouwd hebben, en al veel slechte ideeën gezien hebben.
Ik zal eerlijk zijn: zo'n absurd idee als dit (een relationeel model in 1 tabel gieten) heb ik nog nooit gezien, en ik hoop dat ik het ook nooit zal zien.

offtopic:
Ervaring hoeft niet per se een referentie te zijn. Het kan ook een weigering betekenen om andere theoriën te aanvaarden. Darwin werd ook keihard uitgelachen en na zijn dood algemeen aanvaard (en nu weer in twijfel getrokken). Waarom zou overigens de aarde rond de zon draaien als in de bijbel anders staat?

Een bevriend programmeur heeft ook een dergelijk datamodel opgezet. Ik liet hem deze thread lezen. Dit is een quote uit zijn reactie:

En over die performance twijfel ik ten zeerste. Ik heb [...] een generiek datamodel dat bestaat uit 1 Records table en 6 RecordFields tabellen (voor respectievelijk Integer, Float, String, Boolean, DateTime en Text). Ik heb in de Records tabel 1.577.347 records en in de RecordIntegerFields 8.826.183 records. Om een tabel te produceren (dit komt op hetzelfde neer als hoe die gast 'objecten' terug uit zijn 'éné tabel' produceert) met een groepering op 2 velden met 1 dataveld dat gegroepeerd wordt, kost 3.06 minuten.

Hier moet je dus in meenemen dat ik dus wel verschillende type tabellen voor verschillende datatypes gebruik. Voor mij is verder de snelheid voldoende omdat de flexibiliteit [...] veel belangrijker is.

[mOrPhie]

Overigens is het idee van "vertical records" (zoals dit sinds 1960 geloof ik al heette) eeuwenoud dus. Het is echter bij de vele pogingen in het verleden gebleken dat het enige voordeel dat je hebt is dat je geen null-values in je database hebt staan. Nou nou, wij blij.

Flexibiliteit is op heel veel andere manieren beter op te lossen. Performance win je er NIET mee, je kunt er hooguit op verliezen; je hebt dus geen gewin. Zoeken kan nooit meer goed gericht, omdat je verschillende objecten bij elkaar in 1 tabel hebt staan.

Laat ik wel duidelijk zijn. Het is zeker geen gek idee, en zeker niet stom of absurd, maar bedenk wel dat je niet de eerste bent, die mensen probeert te overtuigen van dit systeem, terwijl het voornamelijk ellende opleverde. Wat je namelijk doet is een relationeel meta-model boven op een meta-model van de rdbms plaatsen. Zie je hoe krom het is?

Affin, ik kan hier nog veel meer over zeggen dat eigenlijk allang gezegd is in dit topic, laat ik het erbij houden dat ik zelf ervaring hebt gehad met dit principe en er niet blij mee was.

Overigens is mijn verhaaltje van hierboven wel gebaseerd op meer dan 1 tabel... Dus niet alles in 1 tabel proppen. Verder is het projectje wellicht wel heel erg ontzettend leerzaam en leuk , maar nuttig en bruikbaar, da's een ander verhaal.

[EfBe]

Laat ik wel duidelijk zijn. Het is zeker geen gek idee, en zeker niet stom of absurd, maar bedenk wel dat je niet de eerste bent, die mensen probeert te overtuigen van dit systeem, terwijl het voornamelijk ellende opleverde.

Als je niets leert van het verleden en van fouten van anderen, ben je gedoemd die fouten te herhalen. Het is dus wel degelijk dom om zonder research te gaan proberen dit als goed erdoor de drukken.

Ervaring hoeft niet per se een referentie te zijn. Het kan ook een weigering betekenen om andere theoriën te aanvaarden.

Ervaring zegt wel dat je gewerkt hebt met de materie en ervaringsdeskundige bent. Of het een weigering om andere theorieen te aanvaarden is iets heel anders. Je kunt 100 theorieen aanvaarden en maar tijd hebben voor 1, waar je dus ervaring in hebt.

[Verwijderd]

Was ADABAS toen niet zo'n vertikale database? Data wordt fysiek vertikaal opgeslagen en een meta laag geeft er een relationeel tintje aan. Voordeel was snelle retrieval. Elk veld werd dus direct al in een index opgeslagen!

[mOrPhie]

Verwijderd schreef op 10 april 2004 @ 11:26:
Was ADABAS toen niet zo'n vertikale database? Data wordt fysiek vertikaal opgeslagen en een meta laag geeft er een relationeel tintje aan. Voordeel was snelle retrieval. Elk veld werd dus direct al in een index opgeslagen!

Bij ADABAS gaat het semantisch om de achtergrond/werking van de database zelf. Niet vertical records als data-model. Dat is een wezenlijk verschil met hetgene hier wordt geopperd.

[alienfruit]

Waarom zou je geen OO DB gebruiken? Als je toch objecten wilt opslaan, lijkt me dat toch handiger? Ik heb niet het hele topic gelezen hoor, maar ik heb een tijdjr gewerkt met. Enige probleem wat je met OO DB weer kan krijgen is dat als opslaan/serializen van zo'n object fout gaat, dat vaak heel je OODB verziekt wordt. In principe is zo'n OO DB toch te vergelijken met een XML DB daarbij wil je ook data dat vaak niet een vast stramien heeft opslaan. Iedereen vrolijk pasen toegewenst, de database kenner heeft weer gesproken.

[Grijze Vos]

Uiteindelijk slaat elke DBMS de data verticaal op. De cirkels op een disk zijn nog altijd een grote string aan enen en nullen.

[seweso]

Het heeft even geduurd maar ik heb dan nu echt een werkende versie. Ik heb woovi v0.2 af. Voor het geval dat ik het nog niet gezegd heb: woovi is een object georienteerde database die alle gegevens opslaat in één tabel. Deze versie is nog lang niet klaar maar bewijst wel dat het concept levensvatbaar is. Het is trouwens de bedoeling dat versie 1.0 een vervanger van Microsoft Access word.

Als je het programma wil testen dan moet je:

1. Foxpro 7 runtime library installeren
2. Het volgende zip-file ergens uitpakken Woovi v0.2.zip
3. Woovi.exe in de bin directory opstarten

De rest wijst (hopelijk) zichzelf.

[gorgi_19]

seweso:

Hoewel je laatste post een uitwerking van je eerdere probleem is, is het niet de bedoeling om de complete tools te plaatsen, met verwijzing naar je eigen site.
Wil je wel je tool laten zien, dan is [rml][ Alg] Welke tools heb jij voor jezelf gemaakt?[/rml] daar geschikt voor.

[ Voor 15% gewijzigd door gorgi_19 op 16-07-2004 16:29 ]