Programma structuur vraag

[4Real]

Ik zit momenteel te werken aan een bos beheer programma. De opzet van het programma is zo dat de objecten er in zelf aangemaakt kunnen worden en later kunnen aan die objecten weer velden (properties) aan toegevoegd worden.

Mijn baas heeft het ontwerp gemaakt, maar elke dag dat ik er aan werk irriteer ik me aan het gehele ontwerp en nu vroeg ik me af om het slim is om nog een keer over het ontwerp heen te kijken of dat dit ontwerp goed zat is en dat het gewoon aan mij ligt.


Het is nu zo dat wij een tabel OBJECT hebben waar alle objecten in komen te staatn, bijvoorbeeld bossen, bomen, stammen en deelstammen. Elk object heeft ook velden waarin de gegevens in komen te staan. Elk object wat aangemaakt wordt krijgt een eigen sql tabel waar alle informatie over het object in komt te staan. Dan is er daarnaast ook nog een objecttree tabel waar de gehele boomstructuur van alle aangemaakte objecten in staat.

Het gehele programma is zo gemaakt dat het zo dynamisch mogelijk is en dat je er een objecten hiërarchie mogelijk is.

Voorbeeld van de database:

code:

OBJECT TABLE
ID, Naam, tabel naam

PARENTCHILD TABLE
ID, ParentID, ChildID

FIELDS TABLE
ID, Object, Type, DbField, FieldAlias, Fieldgroup (en nog wat velden)

OBJECTTREE TABLE
ParentName, ParentID, ChildName, ChildID

# en dan voor de objecten en aparte tabel waar de gegevens voor het object in komen te staan, bijvoorbeeld bij een TREE object is het het volgende

TREE TABLE
ID, Parenttype, parentid, name (en nog wat velden)

Ik heb alleen het idee dat er zo overbodig veel tabellen en dubbele column zijn, mijn baas zegt de heletijd dat het makkelijk is met query's maken, maar hoe kan ik hem nou overtuigen dat er mogelijk andere ontwerpen zijn die gewoon beter werken.

Mijn idee is dit ongeveer

code:

# Een object type tabel om de object soorten te bepalen (bos, boom, stam, etc)
OBJECTTYPE TABLE
ID, Name, Parent

# Hierin komt alle standaard informatie van de objecten in te staan (alles wat hier in komt moet voor elk object ook ingevuld zijn.
OBJECT TABLE
ID, Object, Title, 

# Velden tabel, om de properties van elke object te bepalen
FIELD TABLE
ID, Object, Fieldtype, FieldName, FieldGroup, etc

# En dan een result tabel om de custom properties (velden tabel dus) op teslaan
RESULT TABLE
ID, FieldID, FieldResult

Mijn baas zegt dat mijn ontwerp veel zwaarder en langzamer is omdat alle informatie in één tabel komt te staan, maar als je de index goed zet en goede queries uitvoert moet dit volgens mij verwaardeloos baar zijn. En de structuur hoe ik het ongeveer in gedachten heb is makkelijker te programmeren dan overal en ergens weer spul op te slaan en overal dubbelen gegevens op te slaan.

Ik hoop dat het een beetje duidelijk is anders vraag maar als er iets onduidelijk is.


_{Waarom zijn die code blokken ineens zo uit verband getrokken}

[Creepy]

Ik ben op de één of andere manier altijd allergisch voor meta databases (want dat is het) tenzij er echt een enorm goede reden voor is (en die is er vaak niet)

Als je al weet welke zaken je op wilt slaan, maak daar dan ook de juiste tabellen voor aan. Ik kan me eigenlijk ook niet voorstellen dat je voor een bos beheer programma een willekeurig aantal verschillende zaken wilt opslaan dat je zo'n dynamisch geheel nodig hebt. Uitbreidbaarheid is goed, maar je kan ook overdrijven.

Over het ontwerp van je baas: ik denk dat je baas zich moet gaan afvragen of je voor elk objecttype weer een aparte DB wilt aanmaken en hier zaken dubbel op wilt slaan. Je weet nu nooit van te voren welke tabellen er gaan komen en wat de inhoud hiervan gaat zijn. Daarnaast zie ik verschillende dingen meerdere keren terugkomen (ParentId bijv.) wat de onderhoudbaarheid en de foutgevoeligheid niet ten goede komt. Wat dat betreft zou ik eerder kiezen voor jouw ontwerp (even afgezien van mijn eerste opmerking ).

[4Real]

Creepy schreef op dinsdag 06 februari 2007 @ 10:29:
Ik ben op de één of andere manier altijd allergisch voor meta databases (want dat is het) tenzij er echt een enorm goede reden voor is (en die is er vaak niet)

Als je al weet welke zaken je op wilt slaan, maak daar dan ook de juiste tabellen voor aan. Ik kan me eigenlijk ook niet voorstellen dat je voor een bos beheer programma een willekeurig aantal verschillende zaken wilt opslaan dat je zo'n dynamisch geheel nodig hebt. Uitbreidbaarheid is goed, maar je kan ook overdrijven.

Over het ontwerp van je baas: ik denk dat je baas zich moet gaan afvragen of je voor elk objecttype weer een aparte DB wilt aanmaken en hier zaken dubbel op wilt slaan. Je weet nu nooit van te voren welke tabellen er gaan komen en wat de inhoud hiervan gaat zijn. Daarnaast zie ik verschillende dingen meerdere keren terugkomen (ParentId bijv.) wat de onderhoudbaarheid en de foutgevoeligheid niet ten goede komt. Wat dat betreft zou ik eerder kiezen voor jouw ontwerp (even afgezien van mijn eerste opmerking ).

Hij wil juist een heel dynamisch programma, maar het wordt alleen gebouwt voor bos beheer dus eigenlijk kun je statische objecten aanmaken ben ik het met je eens, maar ik kan hem niet overtuigen dat dat beter is, maar aan de andere kant is het wel beter om het meteen goed dynamisch opzet, want dan kun je zelf de objecten kiezen.

Opzich is het wel een leuk idee om voor elk object een eigen tabel aan te maken want zo doende heb je alle informatie van een object ook goed in een eigen tabel, maar echt of het ook echt nut heeft voor snelheid vraag ik mij af. Er komen wel veel items in de bomen tabel te staan laten we zeggen 10000 bomen. Keer 30 properties is 300.000 waardes die opgeslagen moeten worden, of je nou een tabel van 10000 rows met 30 (+ 3 standaard) kolommen hebt of 1 met 300.000 rows en 3 kolommen hebt maakt volgens mij bar weinig uit.

En hij zei dat sommige waardes opgeslagen moeten worden (bv: parenttype naast parentid). Zijn reden is dat de queries er makkelijker op worden. Volgens mij is het gewoon luiheid om goede queries te schrijven en er komt ook nog een bij dat data veel eerder corrupt kan zijn als het in 1 tabel net iets anders opgeslagen wordt.

edit:
Wat nu ook nog het geval is wanneer ik de hele boomstructuur op haal dan ik niet meteen de naam van het object kan ophalen omdat deze weer weggestopt zitten in andere tabellen. Dus voor elk record moet ik weer een aparte query uitvoeren om de naam op te halen. Volgens mij zit de fout ook in het ontwerp op de plek van de objecten want hij gebruikt objecten nu als objecttype en het object zelf alleen de koppeling er tussen is helemaal verkeerd.

[ Voor 9% gewijzigd door 4Real op 06-02-2007 10:59 ]

[EfBe]

4Real schreef op dinsdag 06 februari 2007 @ 10:53:
[...]
Hij wil juist een heel dynamisch programma, maar het wordt alleen gebouwt voor bos beheer dus eigenlijk kun je statische objecten aanmaken ben ik het met je eens, maar ik kan hem niet overtuigen dat dat beter is, maar aan de andere kant is het wel beter om het meteen goed dynamisch opzet, want dan kun je zelf de objecten kiezen.

Drogreden. Een dynamische database bestaat niet. Er is altijd een consensus over wat er in de database staat. Die WIJZIGT wellicht in de loop der tijd, maar een pure dyn. database maken is zinloos want al wat je doet is het meta-model van je gebruikte RDBMS nog eens dunnetjes opnieuw doen.

Die tabelstructuren die gegeven worden in de startpost zijn tenenkrommend. Als je trees van nodes wilt opslaan in een relationele database, dan moet je hoe dan ook vermijden dat je 'parent' en 'child' en dat soort dingen opslaat, want zodra je dat doet zit je aan 1 query per node vast.

Je moet juist iets gaan implementeren als wat CELKO uitlegt hier:
http://groups-beta.google...6/d94afd1d56858df4?q=tree
je kunt cheaten zoals ik uitleg hier:
http://www.llblgen.com/ti...ageID=17746&ThreadID=3208
maar het is behelpen.

Opzich is het wel een leuk idee om voor elk object een eigen tabel aan te maken want zo doende heb je alle informatie van een object ook goed in een eigen tabel, maar echt of het ook echt nut heeft voor snelheid vraag ik mij af.

Behalve als je een realtime applicatie maakt waarin elke miliseconde telt, is 'snelheid' iets waar je geen compromissen voor maakt, dus je relationele model moet je niet kapot maken omdat je dan 'wellicht' wat meer snelheid haalt: je model moet correct zijn, DAARNA pas naar snelheid kijken want 10 tegen 1 dat je dat niet hoeft te doen.

Overigens is de term 'object' me hier wat onduidelijk. Is 'object' een fysiek iets wat je op wilt slaan in de db, of een OO object ?

Er komen wel veel items in de bomen tabel te staan laten we zeggen 10000 bomen. Keer 30 properties is 300.000 waardes die opgeslagen moeten worden, of je nou een tabel van 10000 rows met 30 (+ 3 standaard) kolommen hebt of 1 met 300.000 rows en 3 kolommen hebt maakt volgens mij bar weinig uit.

Nou, dit meta-model gaat je geen sier helpen, het maakt queries maken alleen maar erg ingewikkelt, want je moet namelijk op basis van VALUES in table rows de queries gaan bouwen wat erg lastig is.

En hij zei dat sommige waardes opgeslagen moeten worden (bv: parenttype naast parentid). Zijn reden is dat de queries er makkelijker op worden. Volgens mij is het gewoon luiheid om goede queries te schrijven en er komt ook nog een bij dat data veel eerder corrupt kan zijn als het in 1 tabel net iets anders opgeslagen wordt.

Omdat hij zo'n complexe manier van het oplossen van een simpel probleem heeft gekozen wordt het nodeloos ingewikkeld en moet je kunstgrepen toepassen zoals denormalisatie stappen die hij voorstelt. NOG een teken aan de wand dat meneer er niet veel van begrijpt, want de onderhoudbaarheid holt achteruit met zo'n 'model'

[4Real]

EfBe schreef op dinsdag 06 februari 2007 @ 11:40:
[...]

Drogreden. Een dynamische database bestaat niet. Er is altijd een consensus over wat er in de database staat. Die WIJZIGT wellicht in de loop der tijd, maar een pure dyn. database maken is zinloos want al wat je doet is het meta-model van je gebruikte RDBMS nog eens dunnetjes opnieuw doen.

Die tabelstructuren die gegeven worden in de startpost zijn tenenkrommend. Als je trees van nodes wilt opslaan in een relationele database, dan moet je hoe dan ook vermijden dat je 'parent' en 'child' en dat soort dingen opslaat, want zodra je dat doet zit je aan 1 query per node vast.

Ik begin ook knetter gek te worden van het hele database design want niet alleen het parent id slaat hij op bij een object maar ook de parent type en childtype en childid

Dit gebeurt allemaal in de objecttree daarin wordt de hele boom structuur opgeslagen zodat later weer in een andere tabel gekeken kan worden naar de gegevens. Ik moet verplicht een extra query uitvoeren voor het vullen van de naam in de boomstructuur. Volgens mij als je dat tegen komt weet je gewoon al dat je iets verkeerd doet.

Je moet juist iets gaan implementeren als wat CELKO uitlegt hier:
http://groups-beta.google...6/d94afd1d56858df4?q=tree
je kunt cheaten zoals ik uitleg hier:
http://www.llblgen.com/ti...ageID=17746&ThreadID=3208
maar het is behelpen.

Ik zal dit vanavond even doornemen.

[...]

Behalve als je een realtime applicatie maakt waarin elke miliseconde telt, is 'snelheid' iets waar je geen compromissen voor maakt, dus je relationele model moet je niet kapot maken omdat je dan 'wellicht' wat meer snelheid haalt: je model moet correct zijn, DAARNA pas naar snelheid kijken want 10 tegen 1 dat je dat niet hoeft te doen.

Overigens is de term 'object' me hier wat onduidelijk. Is 'object' een fysiek iets wat je op wilt slaan in de db, of een OO object ?

Object heeft op moment nog even twee betekenissen het kan bijvoorbeeld een boom zijn. (want die staan in een bos) maar er staan er ook meer dus alle bomen zijn dan ook weer objecten. Eigenlijk had een boom een objecttype moeten zijn en de bomen in het bos de objecten.

[...]

Nou, dit meta-model gaat je geen sier helpen, het maakt queries maken alleen maar erg ingewikkelt, want je moet namelijk op basis van VALUES in table rows de queries gaan bouwen wat erg lastig is.

Hoe bedoel je precies? Doel je op de 30000 rows met 30 kolomen of tegen een key/value opslag methode

[...]

Omdat hij zo'n complexe manier van het oplossen van een simpel probleem heeft gekozen wordt het nodeloos ingewikkeld en moet je kunstgrepen toepassen zoals denormalisatie stappen die hij voorstelt. NOG een teken aan de wand dat meneer er niet veel van begrijpt, want de onderhoudbaarheid holt achteruit met zo'n 'model'

onderhoud ben ik echt bang voor, want hoewel het programma grotedeels dynamisch is zitten er nog steeds keihard statisch dingen in geprogrammeerd waardoor de mogelijkheden ook weer naar beneden gaan.

Ik zal vanavond eens beginnen met een ontwerp en zal hem laten zien.

[Verwijderd]

Key/value opslag om alleen maar aan te geven wat de properties van een bepaald object zijn is niet echt handig in een SQL-based database.
Het value-deel zal altijd van een generiek type moeten zijn (variant, object, of meestal string) waarbij je de database niet de kans geeft om bv. indexen etc. te optimaliseren omdat van tevoren niet bekend is wat 't echte type is (integer, float, datetime, etc.).

Wanneer je al weet wat het objecttype is, verwijs dan ook naar een tabel met een structuur dat specifiek is ingericht op de properties van dat objecttype! Dan kan de database nl. doen waar 'ie goed in is (en waar 'ie voor bedoeld is): efficient omgaan met data.

Wanneer mijn baas (ook ontwikkelaar) met een datamodel als in de TS zou komen, zou ik 'm meteen hebben afgebrand, en daar zou ik ook nog mee wegkomen. Jouw datamodel in de TS is overigens niet veel beter, maar vooral een lapmiddel om de structuur te handhaven.
Die FIELD(S) tabel gaat dodelijk worden voor je performance, omdat je dan volledig voorbij gaat aan de mogelijkheden van het RDBMS dat je gebruikt.

[4Real]

Nou ik geef het op want ik heb het model voorgelegd en hij zag er veel goede dingen aan, maar toch was zijn model beter. Omdat elk object zijn eigen tabel heeft waar alle waardes in komen te staan is het makkelijker om reportages te maken, want je het alle info voor je neus. Dat je extreem veel problemen krijgt met het ophalen van parent gegevens is een ander verhaal, maar dat wou hij ook niet horen. Queries bouwen wil hij het niet over hebben want dat is langzamer en alles wat ik zeg word weer overschaduwt met een oplossing waar ik zwaar twijfels aan heb, maar het zal het is niet mijn programma.

Baal er ontzettend van dat ik niet mocht mee helpen bij het ontwerpen van de database, want hij heeft echt grote fouten gemaakt waar hij met z'n gedachten bij blijft alsof het super gaat werken. Ik ga voor mezelf het model nog wel verder uitwerken, want het is wel een leuk idee om keer mee aan de slag te gaan. Zal dit weekend het model wel even posten zodat jullie mij ook even mogen uitmaken als newbie

[EfBe]

Het is elke keer weer diep schrijnend hoeveel intens domme mensen op vitale posten zitten. Sterkte gewenst, 4real.