[Database] Brede tabel of lange tabel?

[Hobbles]

Ik zit met een probleem waar ik niet uitraak. Ik moet voor mijn stageopdracht een onderdeel maken waarbij er erg veel attributen bij een artikel kunnen horen. Om deze database op te bouwen had ik zelf 2 methodes bedacht: Ofwel

1. Een tabel met alle benodigde artikelgegevens in kolommen, weliswaar minder uitbreidbaar zonder database aanpassing. Hierbij kan ik wel gebruik maken van een versiebeheer plugin die in de programmeertaal zit.
2. Een tabel met alle mogelijke veldnamen die in het formulier kunnen zitten en een tabel met veld_id, artikel_id en waarde. Dit brengt me weliswaar een hoop rijen (+- 80) op per artikel, maar is uitbreidbaarder door de opdrachtgever zonder programmatische tussenkomst.

Mijn vraag is wat voor de database nu eigenlijk het meest efficiente is? Qua voor- en nadelen op andere vlakken is het gelijk voor mij.

[BtM909]

Kijk eens naar normalisatie mogelijkheden voor je datastructuur

[Janoz]

1 is ranzig, 2 is standaard en 80 rijen is peanuts. Een Artikel heeft meerdere atributen, dat lijkt mij een duidelijk voorbeeld van een 1:N relatie (afgaande op de door jou gegeven informatie).

[ Voor 13% gewijzigd door Janoz op 25-04-2007 11:08 ]

[Hobbles]

Qua normalisatie denk ik dat optie 2 het beste is. Maar denkt de database er ook zo over? Optie 1 is echter ook genormaliseerd, omdat ik de data eigenlijk niet kan opsplitsen.

[BasieP]

lengte vs diepte verhaal.

Op internet is daar heel veel over te vinden.
Voordeel van lengte is dat het sneller is, nadeel is dat je er bij. geen historie aan kan hangen
Voordeel van diepte is dat het dynamischer is, nadeel is dat het langzamer is

edit:
optie 2 is het netst, het meest dynamisch, en het flexibelst, echter iets langzamer, en je krijgt super veel records.

Verder is het iets meer werk

[ Voor 78% gewijzigd door BasieP op 25-04-2007 11:14 ]

[RobIII]

Methode 2 is lastiger te doorzoeken op de attributen, zeker als je dingen wil gaan gebruiken als datum-ranges (bijv. "geproduceerd tussen x en y") want je waarde-kolom zal nogal gauw richting varchar achtige toestanden gaan.

Voor beide methodes is iets te zeggen, de kunst is om de balans er tussen te vinden

BasieP schreef op woensdag 25 april 2007 @ 11:11:
Voordeel van lengte is dat het sneller is, nadeel is dat je er bij. geen historie aan kan hangen

Met een FK hang ik zo een history aan een record hoor

BasieP schreef op woensdag 25 april 2007 @ 11:11:
Voordeel van diepte is dat het dynamischer is, nadeel is dat het langzamer is

Zoals ik hierboven al zei: het is niet alleen langzamer, je kunt ook nog eens geen gebruik maken van de ingebouwde functies van SQL om je attributen te doorzoeken.

BasieP schreef op woensdag 25 april 2007 @ 11:11:
edit:
optie 2 is het netst, het meest dynamisch, en het flexibelst

En levert je de meeste sores als je dus de attributen wil doorzoeken etc.

BasieP schreef op woensdag 25 april 2007 @ 11:11:

echter iets langzamer, en je krijgt super veel records.

"Iets" langzamer is natuurlijk ook maar uit de duim gezogen; in sommige gevallen is het "iets" en in andere gevallen is het een big hit op je performance. Veel records stelt voor een beetje DB niets voor, zeker niet met de juiste indexen (op attribute_type dan bijv. om zo snel 1 bepaald attribuut te doorzoeken)

BasieP schreef op woensdag 25 april 2007 @ 11:11:
Verder is het iets meer werk

Ook hier kun je geen uitspraken over doen zonder meer te weten van het project. Voor hetzelfde geld is het 500% meer werk hoor

Optie 2 is nogal gevaarlijk dus, voor je het weet zit je een database-in-een-database te bouwen

[ Voor 93% gewijzigd door RobIII op 25-04-2007 11:18 ]

[Hobbles]

Het doorzoeken van de database is geen vereiste, die attributen waar echt op gezocht moet kunnen worden kan ik ook aan de algemene artikel tabel koppelen, bvb artikelnaam; omdat deze altijd terugkomt? En de rest volgens optie 2...

[BasieP]

RobIII schreef op woensdag 25 april 2007 @ 11:12:
Voor beide methodes is iets te zeggen, de kunst is om de balans er tussen te vinden


[...]

Met een FK hang ik zo een history aan een record hoor
[...]

ja je kan op die manier overal history aan hangen, maar het staat dan dus in een extra tabel.

bij de tweede methode kan je veel flexibeler data beheren. Denk bijvoorbeeld aan deze velden:

Name
DataType
Value
MaxValue
MinValue
InsertDate
InsertedBy
NullAble
OriginalRecordId

etc.
zo kan je dus veel meer data kwijt. Je kunt een deel van je error checking waardes in je DB opslaan, en bijhouden wie wanneer welke waarde gewijzigd heeft.

Dit laatste kan idd ook met een extra tabel, dit is een keuze. Voordeel van extra tabel is dat je geen history data in je data tabel hebt, zodat je data tabel sneller is

[RobIII]

Hobbles schreef op woensdag 25 april 2007 @ 11:18:
Het doorzoeken van de database is geen vereiste, die attributen waar echt op gezocht moet kunnen worden kan ik ook aan de algemene artikel tabel koppelen, bvb artikelnaam; omdat deze altijd terugkomt? En de rest volgens optie 2...

En dat is wat ik bedoelde met de juiste balans vinden

BasieP schreef op woensdag 25 april 2007 @ 11:18:
ja je kan op die manier overal history aan hangen, maar het staat dan dus in een extra tabel.

bij de tweede methode kan je veel flexibeler data beheren. Denk bijvoorbeeld aan deze velden:

Name
DataType
Value
MaxValue
MinValue
InsertDate
InsertedBy
NullAble
OriginalRecordId

etc.
zo kan je dus veel meer data kwijt. Je kunt een deel van je error checking waardes in je DB opslaan, en bijhouden wie wanneer welke waarde gewijzigd heeft.

Klassiek gevalletje van database-in-een-database willen bouwen dus Om er maar eens 1 voorbeeld uit te grijpen: Nullable.. Goh, laat mijn database dat nou prima (en beter dan ik!) zélf af kunnen handelen.

[ Voor 49% gewijzigd door RobIII op 25-04-2007 11:24 ]

[Hobbles]

RobIII schreef op woensdag 25 april 2007 @ 11:19:
[...]

En dat is wat ik bedoelde met de juiste balans vinden

[...]

Klassiek gevalletje van database-in-een-database willen bouwen dus Om er maar eens 1 voorbeeld uit te grijpen: Nullable.. Goh, laat mijn database dat nou prima (en beter dan ik!) zélf af kunnen handelen.

Bedankt voor de hulp tot nog toe Dat van database in database bouwen snap ik niet goed, maar is misschien ook niet wat ik nodig heb?

Ik heb tot nog toe dit schema:

code:

Table: Article
         id                     
         article_code           
         article_name
         format_width           
         format_height          
         colorbase              
         serie_id               
         type_id                

Table: ExtraAttribute (Om een formulier op te bouwen)
         id                     
         label                  
         field                  
         display                
         required               
         required_msg           
         validator              
         min
         min_error
         max
         max_error

Table: ExtraAttributeValue
         article_id                
         extra_attribute_id
         value

Edit: value heb ik als varchar gekozen, dat leek me het meest zinnige omdat je hier bijna alle datatypes in kwijt kan

[ Voor 4% gewijzigd door Hobbles op 25-04-2007 11:30 ]

[BasieP]

RobIII schreef op woensdag 25 april 2007 @ 11:19:

Klassiek gevalletje van database-in-een-database willen bouwen dus Om er maar eens 1 voorbeeld uit te grijpen: Nullable.. Goh, laat mijn database dat nou prima (en beter dan ik!) zélf af kunnen handelen.

ja laten we van al de goed bedoelde voorbeelden die ik post even eentje nemen waar je me op kan pakken..

probeer eens te begrijpen wat ik bedoel ipv iets af te kraken.

In somige gevallen wil je echt zelf zulke velden beheren, en in somige gevallen wil je echt zelf een database in een database bouwen.
Je hoeft het niet met me eens te zijn, maar er zijn zat grote bedrijven die nog veel ranzigere (zoals jij het waarschijnlijk ziet) constructies bedenken om hun data in op te slaan.

even voor de duidelijkheid. Een database is een methode om functioneel bij je data te kunnen (ow wacht nu ga je me pakken op dat ik de DB definitie niet compleet volgens het boekje zeg )

anyway, het is een tool, de tool moet functioneel zijn. Wanneer hij dit niet is voor jouw situatie en je kan het zelf beter.. waarom zou je het niet doen?

[ Voor 19% gewijzigd door BasieP op 25-04-2007 11:41 ]

[RobIII]

BasieP schreef op woensdag 25 april 2007 @ 11:40:
ja laten we van al de goed bedoelde voorbeelden die ik post even eentje nemen waar je me op kan pakken..

probeer eens te begrijpen wat ik bedoel ipv iets af te kraken.

Ho ho ho...huuuuu!
Ik kraak niets af, ik ben met je in discussie en neem gewoon niet 'blind' aan wat je zegt en heb er wat kritiek/aanvullingen op. Dat ik die Nullable pakte was puur omdat die (voor de beginnende DB-ers) het herkenbaarst is en het snelst mijn punt duidelijk maakte.

BasieP schreef op woensdag 25 april 2007 @ 11:40:
In somige gevallen wil je echt zelf zulke velden beheren, en in somige gevallen wil je echt zelf een database in een database bouwen.

Dat heb ik ook nergens ontkend; ik gaf enkel aan dat er een balans gezocht moet worden tussen "optie 1" en "optie 2".

BasieP schreef op woensdag 25 april 2007 @ 11:40:
Je hoeft het niet met me eens te zijn, maar er zijn zat grote bedrijven die nog veel ranzigere (zoals jij het waarschijnlijk ziet) constructies bedenken om hun data in op te slaan.

Als grote bedrijven het doen is dat voor mij nog geen reden om dat ook te doen. Moeder zei altijd: Als anderen in de Maas springen, doe jij het dan ook? Ook bij grote bedrijven werken incompetente figuren die hun bagger tot productiecode weten te verheffen. Dat wil nog niet zeggen dat het goed zou zijn.
(En let wel: ik praat nu algemeen en beweer hier dus niet dat "optie 2" ranzig en/of bagger zou zijn.)

BasieP schreef op woensdag 25 april 2007 @ 11:40:
even voor de duidelijkheid. Een database is een methode om functioneel bij je data te kunnen (ow wacht nu ga je me pakken op dat ik de DB definitie niet compleet volgens het boekje zeg )

Alsof ik ooit volgens het boekje ga...

BasieP schreef op woensdag 25 april 2007 @ 11:40:anyway, het is een tool, de tool moet functioneel zijn. Wanneer hij dit niet is voor jouw situatie en je kan het zelf beter.. waarom zou je het niet doen?

En daar probeer ik TS dus (een beetje, niet volledig) voor te behoeden; vaak denk je dat je het beter kunt terwijl dat niet zo is of hoeft te zijn. Again; er is genoeg te zeggen voor "optie 2" maar ik geef enkel aan dat er een balans gezocht moet worden.

Ik vind het dan ook jammer dat je zo'n aanstoot neemt aan mijn (goedbedoelde) posts. In essentie ben ik het (best een beetje) met je eens, ik nuanceer het dus alleen. Althans, dat was de bedoeling.

Hobbles schreef op woensdag 25 april 2007 @ 11:28:
Edit: value heb ik als varchar gekozen, dat leek me het meest zinnige omdat je hier bijna alle datatypes in kwijt kan

En daar heb je de root van het probleem. Je kunt dus geen date/time functies, aggregates, betweens of uberhaupt een 'numerieke sortering' etc. loslaten op die velden. Zolang je daar geen behoefte aan hebt kun je deze oplossing ("optie 2") prima gebruiken. Er komt echter een dag dat je opdrachtgever zegt: Ik wil alle producten die voldoen aan voorwaardes x, y en z hebben gesorteerd op p, q, r. En dan ben je de klos als een of meer van de attributen p, q, r, x, y en z in je "dynamische velden tabel" zitten.

Hobbles schreef op woensdag 25 april 2007 @ 11:52:
Roblll's voorbeeld ivm Nullable was me wel direct duidelijk, dus daar had hij wel gelijk.

Het gaat/ging me niet zozeer om "gelijk"; ik probeerde een punt duidelijk te maken (zonder 2 pagina's aan uitleg te hoeven typen) en dat is (gelukkig/klaarblijkelijk) dus doorgekomen

[ Voor 17% gewijzigd door RobIII op 25-04-2007 11:55 ]

[Hobbles]

Ik denk dat ik voor optie 2 ga met een klein beetje optie 1 , zoals ik in mijn vorige post in het schema al aangaf.

Bedankt voor de reactie's! Ik kan weer verder

PS:
Roblll's voorbeeld ivm Nullable was me wel direct duidelijk, dus daar had hij wel gelijk.

Edit: De opdrachtgever gebruikt deze toepassing enkel als tijdelijke opslagplaats om daarna in het echte systeem in te voeren. Omdat ze met hun echte systeem geen workflow kunnen toepassen om gebruikers aan te sporen om hun data bij te werken. Dus het lijkt me onwaarschijnlijk dat hij gaat vragen om te sorteren op bepaalde velden (Ja ik weet het, gebruikerseisen kan je niet vertrouwen )

[ Voor 42% gewijzigd door Hobbles op 25-04-2007 12:00 ]

[RobIII]

Bedenk me zojuist een leuk (praktijk) voorbeeld. Het is wel een 'heel verhaal' dus bare with me effe.

Rond 2000/2001 heb ik bij een niet nader te noemen werkgever gewerkt welke een commercieel (duur!) CMS op de markt ging zetten. Toen ik er terecht kwam was het project (helaas) al halverwege en kon er dus niets meer 'ongedaan' gemaakt worden aan de basis. Dit was trouwens een 'groot bedrijf' (3000+ man worldwide).

Het CMS was zo opgezet dat de gebruiker een "item" bij elkaar kon klikken. Een "item" was bijvoorbeeld een "nieuwsbericht". _{Clickety Clickety} Titel - Type tekst _{Clickety Clickety} Datum - Type date _{Clickety Clickety} Body - Type tekst _{Clickety Clickety} Online - Type Boolean. Voila. De gebruiker heeft zelf mooi gedefinieerd hoe een nieuwsbericht in elkaar zit.

In essentie (versimpeld) kreeg je dus de volgende structuur



ItemTypes

ID	type
1	Nieuwsbericht
2	Product
...	...

ItemFields

ID	ItemType	Attribute	type
1	1	Titel	text
2	1	Datum	date
3	1	Body	text
4	1	Online	bool
5	2	Productcode	text
6	2	foo	bar
7	2	...	...

Items

ID	ItemType	CreatedBy	Foo	Bar
1	1	RobIII	<<nieuwsbericht1	...
2	1	RobIII	<<nieuwsbericht2	...
3	2	SomeOne	<<eenproduct	...
4	1	...	<<eennieuwsbericht	...

ItemData

ItemID	ItemField	Value
1	1	Nieuwsbericht 1
1	2	25-04-2007 12:10
1	3	Bericht blablablablabla...
1	4	True
1	5	...
2	1	Nieuwsbericht 2
2	2	21-03-2006 11:54
2	3	Bericht blablablablabla...
2	4	False
2	5	...

_{Effe uit de losse pols, zoiets was het dus...}

Dit werkt fantastisch totdat je een filter wil doen op alle berichten die online getoond moeten worden en niet ouder zijn dan 3 weken. En als je dan ook nog wil sorteren op datum dan ben je best aardig de pineut. En dan heb ik het nog niet eens gehad over referentiële integriteit afdwingen etc.

Het idee lijkt, op het eerste gezicht, geweldig. Maar in essentie ben je een db-in-een-db aan het bouwen en werk je je alleen maar in de nesten.

Ik zeg nadrukkelijk NIET dat "optie 2" bagger is of slecht, maar je moet er ontzettend mee oppassen en een juiste balans vinden tussen 1 en 2.

Edit: Oh, mocht je nog nieuwsgierig zijn naar hoe het is afgelopen met dat CMS: het is 2 of 3 keer verkocht aan een 'grote' klant (en heeft goddank voor 'ons') zijn geld (investering) nét opgeleverd daardoor. Maar wat ben ik blij dat ik dat ding niet meer hoef te onderhouden (laat staan ondersteunen). Dat was écht geen pretje kan ik je zeggen Uiteindeljik is het "overal voor te gebruiken CMS" dus ontzettend geflopt en nergens langer dan (zeg) een jaar in gebruik geweest. De 'senior' die indertijd dit 'briljante' idee kreeg heb ik (ook tijdens het ontwikkelproces) meermalen op de fout in zijn 'ontwerp' gewezen maar uiteraard wist hij het vele malen beter

[ Voor 17% gewijzigd door RobIII op 25-04-2007 12:50 ]

[Verwijderd]

RobIII schreef op woensdag 25 april 2007 @ 12:13:
Bedenk me zojuist een leuk (praktijk) voorbeeld. Het is wel een 'heel verhaal' dus bare with me effe.

Nu heb ik een project gedaan met een CMS wat op een dergelijke manier was opgezet (we zouden het dus heeeel goed over hetzelfde CMS kunnen hebben). En ja het model functioneert aardig bij een item aantal van 10.000 stuks. Helaas hadden we er iets meer, ongeveer 2 miljoen, wat in een andere tabel (veldwaardes) voor zo'n 40 miljoen records zorgde. Logischerwijs ontplofde werkelijkwaar elke query die je er maar naartoe schoot (iets met joins op die tabbellen).

Ik ben dus zelf groot voorstander van zaken (tot op zekere hoogte) te normaliseren.

[RobIII]

Verwijderd schreef op woensdag 25 april 2007 @ 12:25:
[...]

Nu heb ik een project gedaan met een CMS wat op een dergelijke manier was opgezet (we zouden het dus heeeel goed over hetzelfde CMS kunnen hebben). En ja het model functioneert aardig bij een item aantal van 10.000 stuks. Helaas hadden we er iets meer, ongeveer 2 miljoen, wat in een andere tabel (veldwaardes) voor zo'n 40 miljoen records zorgde. Logischerwijs ontplofde werkelijkwaar elke query die je er maar naartoe schoot (iets met joins op die tabbellen).

Dat is dus mijn punt.

Verwijderd schreef op woensdag 25 april 2007 @ 12:25:
Ik ben dus zelf groot voorstander van zaken (tot op zekere hoogte) te normaliseren.

En we zeggen dus hetzelfde; het is een kwestie van balans zoeken.

* RobIII zich onbegrepen voelt vandaag

[Verwijderd]

RobIII schreef op woensdag 25 april 2007 @ 12:31:
[...]
* RobIII zich onbegrepen voelt vandaag

Misschien omdat je alleen een methode 'afkraakt'/bekritiseerd maar geen oplossing geeft
(je hebt trouwens geen ongelijk met je kritiek )

Het is idd af en toe een probleem om dit soort zaken normaal voorelkaar te krijgen,
ben zelf bezig met een project waar 'gebruikers' (lees appl.beheerder) zelf zaken kan definieeren,
dit gaat dan meer om soorten documenten. Eerst had ik ook een oplossing met een db in een db,
vanuitgaande dat het aantal documenten wel mee zou vallen. Maar je raadt het al, eerste de beste
klant stopt die db zo vol, dat de performance dropte als een baksteen.

Omdat het in mijn situatie ging om vooraf te definieren eigenschappen die voor ieder document van een documenttype voorkomen, ben ik overgegaan om dynamisch tabellen te genereren/onderhouden voor ieder documentype. Dit is dan ook wel met de beperking dat bevragingen etc. per documenttype gaan (was/is in dit geval geen probleem).

Maar een goede snelle & universele oplossing voor het probleem van variabele eigenschappen/properties zou ik wel eens willen weten.

[RobIII]

Verwijderd schreef op woensdag 25 april 2007 @ 12:52:
Misschien omdat je alleen een methode 'afkraakt'/bekritiseerd maar geen oplossing geeft

Lees nou eens mensen! De "oplossing" is dat je een balans moet zoeken tussen "optie 1" en "optie 2" die TS aandraagt. Dat heb ik inmiddels al 40x gezegd...

Verwijderd schreef op woensdag 25 april 2007 @ 12:52:
Maar een goede snelle & universele oplossing voor het probleem van variabele eigenschappen/properties zou ik wel eens willen weten.

Die is er niet; in ieder geval niet in een RDBMS
Tenzij.... (En don't make me go there! )

[ Voor 9% gewijzigd door RobIII op 25-04-2007 12:56 ]

[Verwijderd]

RobIII schreef op woensdag 25 april 2007 @ 12:53:
[...]
Lees nou eens mensen! De "oplossing" is dat je een balans moet zoeken tussen "optie 1" en "optie 2" die TS aandraagt. Dat heb ik inmiddels al 40x gezegd...

Je voelt je echt onbegrepen geloof ik he

[Hobbles]

Verwijderd schreef op woensdag 25 april 2007 @ 12:57:
[...]

Je voelt je echt onbegrepen geloof ik he

Ik begrijp hem! Als er misschien toch nog iemand een revolutionair voorstel heeft om hier een betere oplossing voor te vinden hoor ik het graag, en anders houd ik het bij mijn huidige gedacht.

[Verwijderd]

RobIII schreef op woensdag 25 april 2007 @ 12:31:
Dat is dus mijn punt. En we zeggen dus hetzelfde; het is een kwestie van balans zoeken.

* RobIII zich onbegrepen voelt vandaag

Het was gewoon een beamende post Dus ja ik was/ben het volledig met je eens.

_{..eerst perl en toen java?}

[ Voor 104% gewijzigd door een moderator op 25-04-2007 13:13 . Reden: Whoops... edit i.p.v. quote :+ ]

[RobIII]

Verwijderd schreef op woensdag 25 april 2007 @ 13:10:
_{..eerst perl en toen java?}

offtopic:
(Classic) ASP / MSSQL combi all the way

[Hobbles]

offtopic:
Met welk programma maak je schema's als http://tweakers.net/ext/f...9cfcd3ea98039522/full.gif? Ziet er namelijk wat beter uit dan met Access

[ Voor 16% gewijzigd door een moderator op 25-04-2007 13:25 . Reden: DUDE ik heb mijn dag vandaag niet :X Edit i.p.v. Quote. ]

[RobIII]

Hobbles schreef op woensdag 25 april 2007 @ 13:23:

offtopic:
Met welk programma maak je schema's als http://tweakers.net/ext/f...9cfcd3ea98039522/full.gif? Ziet er namelijk wat beter uit dan met Access

Enterprise manager van MSSQL

[EfBe]

Wat is in vredesnaam een 'lange' tabel ?
Tabellen modelleren is niet iets wat je doet met een natte vinger. Je gebruikt dan veelal een modelleringstechniek zoals bv NIAM/ORM. (http://www.orm.net). Of je 1 of meerdere tables moet maken is alleen een discussie wanneer performance in het geding is en denormalisatie plaats moet vinden. In alle andere gevallen is er geen discussie.

Omdat dit voor je stage is, is het zaak dat je er wat van leert. Het boeit dus geen ruk of je er 3 weken op zit te broeden en dan een foutief model oplevert waar je WEL over hebt nagedacht en waarvan je kunt beargumenteren waarom je het zo gedaan hebt. Het hier vragen levert niets op voor je.

[Verwijderd]

EfBe schreef op donderdag 26 april 2007 @ 08:53:
Wat is in vredesnaam een 'lange' tabel ?

Wat daarmee bedoeld wordt begrijpt de rest van de mensen hier wel. Begrijp jij het als enige niet of zit er nog diepgang achter de vraag die ik dan op mijn beurt weer niet begrijp?

[Verwijderd]

Hobbles schreef op woensdag 25 april 2007 @ 13:23:

offtopic:
Met welk programma maak je schema's als http://tweakers.net/ext/f...9cfcd3ea98039522/full.gif? Ziet er namelijk wat beter uit dan met Access

Of als je iets gratis zoekt: fabForce DBDesigner

[EfBe]

Verwijderd schreef op donderdag 26 april 2007 @ 09:35:
[...]
Wat daarmee bedoeld wordt begrijpt de rest van de mensen hier wel. Begrijp jij het als enige niet of zit er nog diepgang achter de vraag die ik dan op mijn beurt weer niet begrijp?

De term 'lange tabel' hoor ik hier voor het eerst. En het is niet alsof ik nooit met databases werk

De hele discussie is overigens onzinnig: je hebt een goed datamodel of niet, en je kunt de-normaliseren voor performance maar dat is het dan wel. Op zn JBF's wat tabellen in elkaar krassen daar heb je geen reet aan. Ten eerste leert de topicstarter daar niets van en ten tweede is de tabellenstructuur dan dus nergens op gebaseerd en zijn wijzigen in een later stadium dan ook zelden mogelijk zonder ellende te creeeren.

[EfBe]

BasieP schreef op woensdag 25 april 2007 @ 11:11:
lengte vs diepte verhaal.

Op internet is daar heel veel over te vinden.

Lijkt me HEEL sterk. In relationele modellen heb je het niet over lengte vs. diepte (? Was het niet breedte?), want die discussie bestaat nl. niet. Wat hier met 'lange tabel' bedoeld wordt is niet iets wat in een relationeel model bestaat, immers de DATA bepaalt het relationele model in die situatie en dat is iets wat je nooit moet willen, tenzij je het leuk vindt om wat in een RDBMS zit nog eens dunnetjes over te doen.

Hieronder ga ik er even van uit dat 'lengte' bij jou dus attributes in rows inhoudt en diepte / breedte attributes als columns

Voordeel van lengte is dat het sneller is, nadeel is dat je er bij. geen historie aan kan hangen

Die tabel opzet HEEFT geen voordeel. Ten eerste is het niet sneller (het is trager want je kunt geen queries uitschrijven zonder data interpretatie) en ten tweede is het niet onderhoudbaar. Hoe wil jij bv FK's gaan definieren? Veel plezier.

Voordeel van diepte is dat het dynamischer is, nadeel is dat het langzamer is

Attributes krijgen een column, je kunt er verder wel hele bomen over opzetten, maar geen hond die iets van databases snapt zal attributes als rows opnemen in tables, TENZIJ je niet anders kunt (dus in het geval van de onwenselijke situatie dat je dynamisch attributes moet kunnen toevoegen at runtime)

edit:
optie 2 is het netst, het meest dynamisch, en het flexibelst, echter iets langzamer, en je krijgt super veel records.
Verder is het iets meer werk

Jij snapt weinig van waar je over praat volgens mij. Attributes als rows opnemen is de meest beroerde oplossing die je kunt kiezen.
\

Hobbles schreef op woensdag 25 april 2007 @ 11:28:
[...]
Bedankt voor de hulp tot nog toe Dat van database in database bouwen snap ik niet goed, maar is misschien ook niet wat ik nodig heb?

Je snapt toch wel waar je mee bezig bent of is het begrip 'database' nieuw voor je, nee toch hoop ik? Een RDBMS verzorgt een service voor je voor het beheren van een fysiek relationeel model, wat we ook wel datamodel noemen, je tables/views, FK's etc. Een table definitie is dus te gebruiken binnen een RDBMS om het RDBMS allerlei dingen te laten afhandelen, zoals FK constraints, nullability of fields, unique constraints etc. Als je je tabel roteert, dus alle attributes als rows opneemt in een of andere table, gooi je dat overboord en moet je het ZELF programmeren. Dat is behoorlijk dom, want dan bouw je dus in feite een RDBMS in een RDBMS.

Ik heb tot nog toe dit schema:

code:

Table: Article
         id                     
         article_code           
         article_name
         format_width           
         format_height          
         colorbase              
         serie_id               
         type_id                

Table: ExtraAttribute (Om een formulier op te bouwen)
         id                     
         label                  
         field                  
         display                
         required               
         required_msg           
         validator              
         min
         min_error
         max
         max_error

Table: ExtraAttributeValue
         article_id                
         extra_attribute_id
         value

Edit: value heb ik als varchar gekozen, dat leek me het meest zinnige omdat je hier bijna alle datatypes in kwijt kan

Is ExtraAttribute een lookup table voor form elementen of is het een data table voor values op een form? Indien het laatste dan is de 3e table onzinnig.

[ Voor 43% gewijzigd door EfBe op 26-04-2007 14:11 ]

[JJvG]

Om toch ook nog even een korte duit in het zakje te doen (en misschien een techie-vertaling er bij te leveren...). Met een lange tabel wordt eigenlijk een soort code-waarde tabel bedoelt, waarin een soort van meta-data van een object wordt opgeslagen. Ter vergelijking:

Optie1 (brede tabel):
Naam, Adres, Postcode, Woonplaats
JJvG, straat, 1234AB, omgeving Amsterdam

Optie2 (lange tabel):
ID-Type-Code - waarde
1 - Persoon - Naam - JJvG
2 - Persoon - Adres - Straat
3 - Persoon - Postcode - 1234AB
4 - Persoon - Woonplaats - omgeving Amsterdam

Optie 1 is een gewoon genormaliseerd model
Optie 2 is eigenlijk een lange lijst van allemaal losse entiteiten, die m.b.v. aan elkaar worden gekoppeld op basis van verwijzende sleutels.

Voor optie 2 moet in de voorkant (GUI) van een applicatie veel meer logica worden gebouwd, omdat van elk veld (type) moet worden bijgehouden of het nullable is, min-max waardes, types (varchar, numeriek of datum), terwijl dit eigenlijk in een database thuis hoort.

@topicstarter: Zelf zou ik je adviseren om zoveel mogelijk voor optie 1 te gaan en te accepteren dat je gewoon veel kolommen hebt. Desnoods zet je ze in een aparte tabel met een 1-op-1 relatie, zodat je ze alleen bij een detail-pagina hoeft te joinen (scheel iets in performance misschien).

[Hobbles]

@EfBe: Probeer in het vervolg iets minder arrogant over te komen aub. Ik stel mijn vraag hier om er ook iets van te leren, zodat ik mijn keuze in de toekomst kan onderbouwen. Ik kom hier niet iets vragen omdat ik iets niet snap, maar omdat ik de mening wou weten van andere (waarschijnlijk meer ervaren) personen.

Ik zit dus met het probleem dat de attributen kunnen aangepast worden, dus er moeten attributen bijgemaakt of verwijdert kunnen worden. Daardoor is Optie 1 (veel kolommen) dus een iets minder goede oplossing voor mijn probleem naar mijn mening. Optie 1 kan ik alleen gebruiken voor de attributen die NOOIT veranderd kunnen worden.

Dat ik daardoor iets meer werk heb in het programmeren van de GUI neem ik er maar bij. Ook hier kan ik dan weer iets van leren. En bij deze kan ik dus ook besluiten dat Roblll al van in het begin de juiste oplossing voor mijn context heeft aangehaald.

Is ExtraAttribute een lookup table voor form elementen of is het een data table voor values op een form? Indien het laatste dan is de 3e table onzinnig.

Dit is een lookup tabel voor form elementen. Ik flans niet zomaar

Op zn JBF's wat tabellen in elkaar

[jvdmeer]

JJvG schreef op donderdag 26 april 2007 @ 16:27:
Voor optie 2 moet in de voorkant (GUI) van een applicatie veel meer logica worden gebouwd, omdat van elk veld (type) moet worden bijgehouden of het nullable is, min-max waardes, types (varchar, numeriek of datum), terwijl dit eigenlijk in een database thuis hoort.

Daarnaast geldt natuurlijk voor optie 2 dat je heel moeilijk standaard bd-regels kan afdwingen. Bijvoorbeeld:
- Bij een adres moeten straat, huisnummer, pc en woonplaats zijn gevuld.

Probeer zo'n standaard constraint maar vast te leggen in het 2e voorbeeld.

Of probeer deze querie maar te herschrijven:

code:

SELECT * FRON adressen WHERE (adres='straat' and woonplaats='amsterdam') or woonplaats='den haag'

Ik wens je een goede wedstrijd.

[ Voor 13% gewijzigd door jvdmeer op 02-05-2007 11:53 . Reden: 2e voorbeeld toegevoegd ]

[Hobbles]

Het voordeel dat ik heb is dat er slechts 1 of 2 foreign keys gebruikt moeten worden. De rest is allemaal tekst, cijfers of datums... geen persoonsgegevens dus En de velden met foreign keys zet ik als standaard kolom. Nieuwe velden zijn toch alleen maar "tekst" zonder referentie naar iets binnen mijn domein.

Ik heb al even wat lopen maken in het frontend GUI gedeelte, en ik kan mijn formulier al opbouwen en valideren zoals ik wou.

[ Voor 46% gewijzigd door Hobbles op 02-05-2007 13:28 ]

[djluc]

Leuk topic! Wat zou dan de ideale oplossing zijn? Gewoon een standaard database tabel (id-naam-adres) waar je via een programmeertaal velden aan toe voegt? Dus alter tabel acties uitvoeren via een simpele user interface? En dan vervolgens een tooltje maken wat onafhankelijk werkt van de veldnamen, waardoor je ook daadwerkelijk ook alle data kan aanpassen.

[Verwijderd]

Hobbles schreef op woensdag 02 mei 2007 @ 09:26:
@EfBe: Probeer in het vervolg iets minder arrogant over te komen aub.

EfBe heeft 2 hele grote nadelen:
- Hij kan vreselijk arrogant overkomen, en
- Wanneer 't over databases gaat heeft 'ie vrijwel altijd volkomen gelijk. En that sucks!

Ik zit dus met het probleem dat de attributen kunnen aangepast worden, dus er moeten attributen bijgemaakt of verwijdert kunnen worden. Daardoor is Optie 1 (veel kolommen) dus een iets minder goede oplossing voor mijn probleem naar mijn mening. Optie 1 kan ik alleen gebruiken voor de attributen die NOOIT veranderd kunnen worden.

Attributen die dynamisch kunnen wijzigen (dus niet de values, maar de attributen zelf) zijn een drama in elk goed database ontwerp en voor elke database. De DB krijgt nooit de kans om optimaal te performen, want goede indexen etc. zijn nauwelijks mogelijk.

En bij deze kan ik dus ook besluiten dat Roblll al van in het begin de juiste oplossing voor mijn context heeft aangehaald.

Klopt, maar had je ook door wat RobIII bedoelde? Een brede tabel voor de velden die vastliggen, en een gekoppelde tabel voor de attributen die per dag/week/whatever kunnen wijzigen. En uiteindelijk mag je dan hopen dat je zo min mogelijk op die 2e tabel hoeft te filteren/sorteren, etc. want daarmee help je je performance serieus om zeep.
Bovendien heeft die 2e tabel 't nadeel dat je ieder datatype in 1 'generiek' datatype op moet slaan (varchar waarschijnlijk). Hoe goed gaan jouw datetime bewerkingen op een varchar t.o.v. de ingebouwde functies die je database zelf heeft voor datetime velden?

[BasieP]

EfBe schreef op donderdag 26 april 2007 @ 13:55:
[...]
Hieronder ga ik er even van uit dat 'lengte' bij jou dus attributes in rows inhoudt en diepte / breedte attributes als columns

een tabel diepte is een tabel waarbij elke variable 1 record is. dus 1 record heeft dus de variable naam (als kolom) de waarde (als kolom) etc.

breedte is een doodnormale tabel zoals je die normaal maakt.

Die tabel opzet [breedte] HEEFT geen voordeel. Ten eerste is het niet sneller (het is trager want je kunt geen queries uitschrijven zonder data interpretatie) en ten tweede is het niet onderhoudbaar. Hoe wil jij bv FK's gaan definieren? Veel plezier.

daar sla je de plank dus voledig mis. je hebt het hier over een doodnormale tabel. Die is ZEKER sneller dan een diepte tabel, en daar kan je prima FK's in defineren.

op de rest van je verhaal ga ik neit eens reageren, aangezien je mijn post gewoon niet snapt

[justmental]

Volgens mij quote hij daar een stukje over 'lengte', dat lijkt me ook logischer.

Ik heb een keer aan een systeem gewerkt met een dergelijk dynamisch datamodel en dat is voldoende om nooit meer in die val te trappen.
De 'nadelen' van de reguliere oplossing zijn vooral esthetisch, 80 kolommen in een tabel ziet er wat onoverzichtelijk uit. Dit staat echter niet in verhouding tot de praktische en performance nadelen van zo'n dynamische attributen oplossing.

[Hobbles]

djluc schreef op woensdag 02 mei 2007 @ 14:26:
Leuk topic! Wat zou dan de ideale oplossing zijn? Gewoon een standaard database tabel (id-naam-adres) waar je via een programmeertaal velden aan toe voegt? Dus alter tabel acties uitvoeren via een simpele user interface? En dan vervolgens een tooltje maken wat onafhankelijk werkt van de veldnamen, waardoor je ook daadwerkelijk ook alle data kan aanpassen.

Ik heb zo het gevoel dat dit de ideale oplossing zou kunnen zijn. Maar dit ga ik nooit uitgewerkt krijgen voor het einde van mijn stageperiode. Ik ga dit wel in mijn achterhoofd houden voor in de toekomst.

Ik ga toch bij de gulden middenweg blijven, omdat ik op die manier het makkelijkst aan de requirements kan voldoen, zonder al te veel onnodig performance verlies.

[Verwijderd]

Hobbles schreef op woensdag 02 mei 2007 @ 15:51:
Ik heb zo het gevoel dat dit de ideale oplossing zou kunnen zijn.

Da's een nachtmerrie voor iedere helpdesk! Welke klant heeft welke velden toegevoegd? van welk type? en wat moeten ze doen?

Absoluut niet te supporten.

[RobIII]

Verwijderd schreef op woensdag 02 mei 2007 @ 22:12:
[...]

Da's een nachtmerrie voor iedere helpdesk! Welke klant heeft welke velden toegevoegd? van welk type? en wat moeten ze doen?

Absoluut niet te supporten.

Kortom: Het is hoe dan ook ellende en eigenlijk wil je dat je gebruikers met hun takke van je app blijven en maar gewoon lekker tevreden zijn met wat ze (aan 'attributes') krijgen
Serieus: Er zijn verschillende soorten oplossingen (en ze zijn volgens mij allemaal min of meer genoemd in dit topic); maar bij mijn weten is er geen "dé" oplossing voor dit soort zaken.

[Hobbles]

Ware het niet dat er slechts 1 gebruiker bevoegd is om velden bij te maken... Voor de rest heb je natuurlijk gelijk...

Dit topic kan misschien best gesloten worden, er gaan toch commentaren blijven komen die niet veel extra meer bieden.

[ Voor 33% gewijzigd door Hobbles op 02-05-2007 22:26 ]

[BasieP]

oe ik bedenk me net een alternatief.

ooit eens gezien bij een app uit 1985 ongeveer en toegepast in een access-achtige omgeving (omnis) om wat meer vrijheid te geven.

het is een normale tabel met aan het eind een aantal kolommen die 'attribuut1', 'attribuut2' etc. heten. Deze kunnen naar eigen inzicht gevult worden door de gebruiker

offtopic:
(en ja ik ben sarcastisch)

[EfBe]

BasieP schreef op woensdag 02 mei 2007 @ 15:05:
een tabel diepte is een tabel waarbij elke variable 1 record is. dus 1 record heeft dus de variable naam (als kolom) de waarde (als kolom) etc.

breedte is een doodnormale tabel zoals je die normaal maakt.

Precies, dat zei ik ook in mijn opmerking:

Hieronder ga ik er even van uit dat 'lengte' bij jou dus attributes in rows inhoudt en diepte / breedte attributes als columns

EfBe: Die tabel opzet [breedte] HEEFT geen voordeel. Ten eerste is het niet sneller (het is trager want je kunt geen queries uitschrijven zonder data interpretatie) en ten tweede is het niet onderhoudbaar. Hoe wil jij bv FK's gaan definieren? Veel plezier.

Daar prak je 'breedte' tussen in een quote van mij, terwijl ik dat dus NIET bedoel. Dat is de LENGTE quote. Als je me dingen gaat nadragen die ik niet beweerd heb dan houdt het op natuurlijk.

daar sla je de plank dus voledig mis. je hebt het hier over een doodnormale tabel. Die is ZEKER sneller dan een diepte tabel, en daar kan je prima FK's in defineren.

Beter lezen. En beter quoten!

op de rest van je verhaal ga ik neit eens reageren, aangezien je mijn post gewoon niet snapt

Tja, wie snapt wie nou niet? Ik had die opmerking wat ik onder breedte/diepte in jouw post verstond er niet voor niks boven gezet.

Hobbles schreef op woensdag 02 mei 2007 @ 09:26:
@EfBe: Probeer in het vervolg iets minder arrogant over te komen aub. Ik stel mijn vraag hier om er ook iets van te leren, zodat ik mijn keuze in de toekomst kan onderbouwen. Ik kom hier niet iets vragen omdat ik iets niet snap, maar omdat ik de mening wou weten van andere (waarschijnlijk meer ervaren) personen.

Wellicht komt dit ook weer arrogant over, maar dat is dan maar zo: jij stelt hier een vraag. Mensen het onderwerp waarover ze een vraag stellen volledig begrijpen hoeven geen vragen te stellen, dus begrijp je iets niet. Dat is prima, maar maak jezelf wel een voorstelling in welke situatie jij zit: je bent op stage. Dat houdt dus in dat je per definitie niet alles weet en dus leert. Maar je hebt ook al een aantal jaren studie achter de rug. Dan met termen aankomen als lange/brede tabel en tabellen willen formuleren zonder theoretische basis... dan snap IK iets niet: wat heb je dan geleerd in de jaren voordat je op stage ging? (voordat je uit je vel springt: in erg veel gevallen kan de student hier geen reet aan doen, de opleiding is gewoon brak). Ik neem toch aan dat daar normale informatieanalyse aan bod is gekomen en normale vaktermen besproken zijn.

Oh, en als iemand het wel weet en jij niet betekent niet dat die persoon die het wel weet arrogant is. Iemand die arrogant is geeft nl. geen antwoord maar lacht je uit omdat je kennelijk iets niet snapt. Ik heb dacht ik wel degelijk antwoord gegeven. Het NARE is alleen dat dat niet het antwoord was wat je wilde horen, maar DAAR kan ik geen moer aan veranderen.

Trouwens, wat zegt jouw stagebegeleider hiervan? Of heeft die ook geen mening?

Ik zit dus met het probleem dat de attributen kunnen aangepast worden, dus er moeten attributen bijgemaakt of verwijdert kunnen worden. Daardoor is Optie 1 (veel kolommen) dus een iets minder goede oplossing voor mijn probleem naar mijn mening. Optie 1 kan ik alleen gebruiken voor de attributen die NOOIT veranderd kunnen worden.

Wat is de reden dat er attributen bijgemaakt moeten worden? Ik vraag dit omdat veel beginners nogal eens de fout maken dat ze data verwarren met table-layout.

Dat ik daardoor iets meer werk heb in het programmeren van de GUI neem ik er maar bij. Ook hier kan ik dan weer iets van leren. En bij deze kan ik dus ook besluiten dat Roblll al van in het begin de juiste oplossing voor mijn context heeft aangehaald.

[...]
Dit is een lookup tabel voor form elementen. Ik flans niet zomaar
[...]

Ah een lookup table. Dus je hebt voorgedefinieerde form elements en je hebt een tabel met instances van die elements? Waar heb je dan de nieuwe attributes nodig? De voorgedefinieerde form attributes zijn fixed, want ze representeren objects in code. De instances zijn gewoon rows in een table, dus ik zie het niet echt waar je speciale zaken nodig hebt, omdat dit gewoon een basic tabel opzet is.

[EfBe]

Verwijderd schreef op woensdag 02 mei 2007 @ 14:56:
EfBe heeft 2 hele grote nadelen:
- Hij kan vreselijk arrogant overkomen, en

Offtopic, maar: wat versta jij dan onder 'arrogant' ?

[Grijze Vos]

BasieP schreef op woensdag 02 mei 2007 @ 23:00:
het is een normale tabel met aan het eind een aantal kolommen die 'attribuut1', 'attribuut2' etc. heten. Deze kunnen naar eigen inzicht gevult worden door de gebruiker

offtopic:
(en ja ik ben sarcastisch)

Een jaartje of twee geleden heb ik een college gevolgd waarin allemaal grote spelers op de markt hun pakketten lieten zien. Daar was dat een redelijke common practice. Meen dat het JDEdwards was, waarbij ze dit echt letterlijk als pluspunt aandroegen. Nadat ik dit zag verbaasde het me niet dat er zoveel geld rondgaat in zaken als SAP consultancy (en soortgelijke software).

[Verwijderd]

EfBe schreef op donderdag 03 mei 2007 @ 12:00:
[...]

Offtopic, maar: wat versta jij dan onder 'arrogant' ?

Je vergeet de volgende regel uit m'n bericht te quoten:

- Wanneer 't over databases gaat heeft 'ie vrijwel altijd volkomen gelijk.

Dat straal je ook uit, en dat kan best wel 's arrogant overkomen. Niks mis mee, en IRL zal 't ook best meevallen, maar soms poneer je dingen op zo'n manier dat de gesprekspartner zich automatisch in de verdediging gedrukt voelt.

Voorbeeld? Lees dit topic nog maar 's...

[Hobbles]

EfBe schreef op donderdag 03 mei 2007 @ 11:56:
Wellicht komt dit ook weer arrogant over, maar dat is dan maar zo: jij stelt hier een vraag. Mensen het onderwerp waarover ze een vraag stellen volledig begrijpen hoeven geen vragen te stellen, dus begrijp je iets niet. Dat is prima, maar maak jezelf wel een voorstelling in welke situatie jij zit: je bent op stage. Dat houdt dus in dat je per definitie niet alles weet en dus leert. Maar je hebt ook al een aantal jaren studie achter de rug. Dan met termen aankomen als lange/brede tabel en tabellen willen formuleren zonder theoretische basis... dan snap IK iets niet: wat heb je dan geleerd in de jaren voordat je op stage ging? (voordat je uit je vel springt: in erg veel gevallen kan de student hier geen reet aan doen, de opleiding is gewoon brak). Ik neem toch aan dat daar normale informatieanalyse aan bod is gekomen en normale vaktermen besproken zijn.

Oh, en als iemand het wel weet en jij niet betekent niet dat die persoon die het wel weet arrogant is. Iemand die arrogant is geeft nl. geen antwoord maar lacht je uit omdat je kennelijk iets niet snapt. Ik heb dacht ik wel degelijk antwoord gegeven. Het NARE is alleen dat dat niet het antwoord was wat je wilde horen, maar DAAR kan ik geen moer aan veranderen.

Trouwens, wat zegt jouw stagebegeleider hiervan? Of heeft die ook geen mening?


[...]

Wat is de reden dat er attributen bijgemaakt moeten worden? Ik vraag dit omdat veel beginners nogal eens de fout maken dat ze data verwarren met table-layout.

Vanuit mijn opleiding hebben we FCO-IM methode gezien, en de tool dat we hiervoor gebruikte stelt de school niet meer beschikbaar (ze weigeren de licentie te verlengen). Hierdoor ben ik dus aangewezen op een andere methode die ik minder goed onder de knie heb.

In verband met de "lange" en "brede" termen; hoe anders kan ik mijn probleem beter uitleggen?

Mijn stagebegeleider heeft nooit gewerkt met relationele databases, en kan me hierbij dus ook niet helpen (buiten logisch redeneren).

offtopic:
Cobol en dergelijke met files als database kent hij wel.

Het is niet omdat je niet zei wat ik wilde horen (wat niet zo is ) dat ik je reply arrogant vond, hij kwam gewoon zo over, ondanks dat je je punt duidelijk maakt.

De reden waarom ik extra velden wil is omdat er vanuit de informatiebehoefte dingen kunnen veranderen. De data die ik moet opslaan gaat over het productieproces van een bepaald item. Hierbij moeten er dus af en toe velden bijgemaakt worden om aan de ISO-normen (ivm productie gegevens) te voldoen. Dit is wat mijn opdrachtgever me verteld heeft, of het waar is maakt me vrij weinig uit, want dat is namelijk niet mijn taak om uit te zoeken. Zij weten beter wat ze willen en nodig hebben.

Een enkele rij was totaal niet voldoende om in de toekomst aan die informatiebehoefte te voldoen.

Nogmaals, mijn vraag was bedoelt om de mening van anderen te weten te komen. Het gaat me dus in dit topic niet over het "waarom", of hoe slecht mijn opleiding wel schijnt te zijn (je weet uiteindelijk niet precies wat de behoefte net is, en dat hoeft ook niet in de context van mijn topicstart).

[D4Skunk]

Misschien is het heel eenvoudig om een flamewar te voorkomen :
@ TS : wat is de bedoeling van de extra attributen : hierbij de twee extremen :

• Extra attributen enkel op het scherm tonen indien je een detail opvraagt : optie 2
• De extra attributen moeten binnen elke query beschikbaar zijn : optie 1

Daarnaast is reeds vermeld : optie 3 : extra velden toevoegen per record onder de naam attribute1,attribute2,...
Voor zover ik het me kan herinneren werkten de interne oracle-tabellen (CI_XXXX) vroeger met optie 3; je gaf de gebruiker de mogelijkheid om op 1 of andere manier toch extra info in de tabellen op te nemen, met een evenwicht tussen de eerste 2 opties hierboven genoemd.

Als het enigzins mogelijk is zou ik echter kiezen voor optie 4 : DDL, en de tabellen dynamisch wijzigen, bv enkel door een 'beheerder'; want als je 'iedereen' toelaat om velden te definiëren, zal er op termijn toch geen consistentie meer inzitten, en kan je het systeem op termijn toch niet meer gaan query-en..

[RobIII]

Waarom vis je daar nou een topic van anderhalve maand oud voor op
Die flamewar was al lang bedaard...

[ Voor 25% gewijzigd door RobIII op 18-07-2007 09:42 ]

[_Apache_]

Probeer zo ie zo te normaliseren.. Dit maakt je applicatie niet alleen een stuk efficienter maar ook het onderhoud hieraan

Probeer voorbij de 2e normalisatievorm te komen.. Denk dat je dan al aardig op weg bent..

Als je realiseerd dat er databases zijn met 10.000.000+ records, maken die paar extra records ook niet meer uit , maar zorg wel dat het te onderhouden valt, dus normaliseren.

[RobIII]

_Apache_ schreef op woensdag 18 juli 2007 @ 09:44:
Probeer zo ie zo te normaliseren.. Dit maakt je applicatie niet alleen een stuk efficienter maar ook het onderhoud hieraan

Gaan we nu naast oude topics omhoog kicken ook nog oude antwoorden gewoon herhalen?

[ Voor 67% gewijzigd door RobIII op 18-07-2007 09:48 ]