[PHP] Drie dimensionale database?

[Josaus]

Hallo mensen,
Voor een website moet ik per dag, voor elke persoon, een bepaald aantal waardes opslaan. Nu loop ik tegen een probleem aan: hoe sla ik dit op in bijvoorbeeld een MySQL database? Een normale tabel heeft kolommen en rijen. (2 dimensies) Bestaan er (makkelijk in PHP implanteerbare) databases waarin je 3 dimensies hebt? Het is op te lossen door voor elke dag, persoon of waarde een tabel aan te maken, maar dit wordt (voor mij) dan weer onoverzichtelijk. Als hier geen (gratis) databaseding voor te vinden is, ben ik bereid er zelf één te bouwen, maar het liefst niet ;3 Meneer Google geeft allemaal rare dingen met charts als ik hier op zoek, dus als iemand misschien een Google-tip heeft waarmee ik het WEL vind, is het ook fijn

Alvast bedankt voor de hulp,
Kees

[Icey]

ID | gebruikerID | datum | field | value

^^ Dan ben jer toch met een normale database?

[NL-RaVeR]

Maak 2 tabellen aan, 1 voor personen en 1 voor de waardes per dag. Vervolgens kun je die waarden via een foreign key (id) linken aan een persoon

[frG]

Kan dit niet als volgt:

Tabellen:
Persons
Data

Dan in de data tabel:
DataID, DateCreated, PersonID, Waarde1, Waarde2, Waarde3

[Sjoerd]

Het beste kun je even: http://nl.wikipedia.org/wiki/Databasenormalisatie doornemen. Tot nu toe heb ik zelf namelijk nog nooit een extra dimensie nodig gehad.

[phex]

person_id + date als primary key gebruiken.

Maar aangezien je zelf de database software wel even gaat bouwen, raad ik die optie aan, en als je toch bezig bent maak er nog even een 4e en 5e dimensie bij! Je weet nooit waarvoor dat handig kan zijn.

[Josaus]

Ja, dat kan natuurlijk ook Voor 300 personen gaat dit een beetje druk worden lijkt me :3 Ik ga dat waarschijnlijk ook wel doen. Ook ga ik Databasenormalisatie even doornemen.

Mijn idee nu is:
Tabel 'users':
ID (primary) | gebruiker | datum | record
Tabel 'data':
ID (primary) | gebruikerID | datum | waarde | waarde2 | etc..

update.php:
Haalt data op, voegt ze in data tabel. Elke dag om 6 uur via cron uitgevoerd.

Hoewel dat wel werkt, is het misschien ook wel leuk om een 3D (of meer) database te maken. Als ik een keer tijd en zin heb, zal ik hier aan beginnen. Waarschijnlijk post ik hem hier voor als iemand anders er wat aan heeft.

Bedankt voor de hulp

[skabouter]

We zijn allemaal heel benieuwd naar je resultaat denk ik

[Loadichus]

Heb je geen FK nodig? ...

[RobIII]

Josaus schreef op woensdag 29 augustus 2012 @ 14:18:
Ja, dat kan natuurlijk ook Voor 300 personen gaat dit een beetje druk worden lijkt me

Een beetje RDBMS kan met vele tientallen miljoenen records en meer omgaan en efficiënt werken mits met wat liefde gekweekt en de juiste indices etc. Voor 300 personen met elk een record per dag = 300 * 365 * 10 = 1.095.000 records per 10 jaar. Daar wordt een RDBMS niet warm of koud van hoor

Josaus schreef op woensdag 29 augustus 2012 @ 14:18:
Hoewel dat wel werkt, is het misschien ook wel leuk om een 3D (of meer) database te maken.

Ik zie nog steeds niet wat "3D" hiermee te maken heeft? Je moet je eerst eens verdiepen in normalisatie en zorgen dat je een "normaal" (of "2D"? ) RDBMS snapt voordat je überhaupt denkt over iets te verbeteren.

[ Voor 10% gewijzigd door RobIII op 29-08-2012 14:26 ]

[phex]

Ik heb gehoord dat een 4d database op dit moment helemaal in is, ik zou mij daar op focussesn. Met een 3d database zit je al vrij snel aan de limitaties van de 3 dimensies...

[glmona]

phex schreef op woensdag 29 augustus 2012 @ 14:21:
Ik heb gehoord dat een 4d database op dit moment helemaal in is, ik zou mij daar op focussesn. Met een 3d database zit je al vrij snel aan de limitaties van de 3 dimensies...

Ik weet dat het niks toevoegd, maar

Trouwens, de oplossing van Icey is m.i. de beste oplossing, anders zou je voor iedere nieuwe waarde een nieuwe kolom moeten toevoegen

[ Voor 22% gewijzigd door glmona op 29-08-2012 14:24 ]

[Icey]

Tabel 'data':
ID (primary) | gebruikerID | datum | waarde | waarde2 | etc..

Waarde, waarde2, waarde3 etc geeft mij al aan dat het niet genormaliseerd is en dus gaat dit vroeg of laat mis. Per waarde krijg je een extra regel in je database, check mijn voorbeeld maar eens.

[Paul]

Josaus schreef op woensdag 29 augustus 2012 @ 14:18:
Tabel 'data':
ID (primary) | gebruikerID | datum | waarde | waarde2 | etc..

Hoe accuraat zijn die namen? Als het bijvoorbeeld telefoonnummers zijn, wat doe je dan als iemand een 3e telefoonnummer krijgt? Is het een lijst met gelijksoortige dingen of moet ik eerder denken aan naam, straat, huisnummer, toevoeging, postcode, land etc?

[sopsop]

Ze verkopen ook al brillen om de 3D tabellen goed te kunnen bekijken:



Maar zonder dollen:

Tabel 'users':
ID (primary) | gebruiker | datum | record
Tabel 'data':
ID (primary) | gebruikerID | datum | waarde | waarde2 | etc..

De tabel users moet alleen bestaan uit userdata en niet uit bezoekdata. Ik weet niet wat je met datum/record bedoelt. Voor het normaliseren stel je eerst vast wat je wilt opslaan, bijvoorbeeld:

Naam, adres, postcode, woonplaats, geboortedatum, pagehit_date, page

Dit kun je vervolgens normaliseren:

tabel user
id (PK)
Naam
adres
postcode
woonplaats
geboortedatum

tabel pagehit
id (PK)
user_id (FK naar user.id)
pagehit_date
page

[ Voor 68% gewijzigd door sopsop op 29-08-2012 14:31 ]

[FastFox91]

Met Mongodb kan je objecten opslaan, misschien te veel van het goede voor je probleem, maar het kan wel.

[Josaus]

RobIII schreef op woensdag 29 augustus 2012 @ 14:21:
Een beetje RDBMS kan met miljoenen records omgaan en efficiënt werken mits met wat liefde gekweekt en de juiste indices etc. 300 personen met elk een record per dag = 300 * 365 * 10 = 1.095.000 records per 10 jaar. Daar wordt een RDBMS niet warm of koud van hoor

Even rekenen: 300 * 365 * 30 = 3.285.000 Dat gaat wel lukken.

RobIII schreef op woensdag 29 augustus 2012 @ 14:21:
Ik zie nog steeds niet wat "3D" hiermee te maken heeft? Je moet je eerst eens verdiepen in normalisatie en zorgen dat je een "normaal" (of "2D"? ) RDBMS snapt voordat je überhaupt denkt over iets te verbeteren.

2D = rij en kolom, 3D is rij, kolom en iets anders xd

Icey schreef op woensdag 29 augustus 2012 @ 14:23:
Tabel 'data':
ID (primary) | gebruikerID | datum | waarde | waarde2 | etc..

Waarde, waarde2, waarde3 etc geeft mij al aan dat het niet genormaliseerd is en dus gaat dit vroeg of laat mis. Per waarde krijg je een extra regel in je database, check mijn voorbeeld maar eens.

Er komt niks bij, het aantal staat vast.

Paul schreef op woensdag 29 augustus 2012 @ 14:24:
[...]
Hoe accuraat zijn die namen? Als het bijvoorbeeld telefoonnummers zijn, wat doe je dan als iemand een 3e telefoonnummer krijgt? Is het een lijst met gelijksoortige dingen of moet ik eerder denken aan naam, straat, huisnummer, toevoeging, postcode, land etc?

Het worden allemaal nummers.

sopsop schreef op woensdag 29 augustus 2012 @ 14:24:
Ze verkopen ook al brillen om de 3D tabellen goed te kunnen bekijken:

[afbeelding]

Moet ik hier uit opmaken dat je vindt dat ik nog even SQL bij moet leren ? Het kan zijn dat dit vanavond allemaal logisch is aangezien ik dan wakkerder ben, maar dat zie ik dan wel ;$

FastFox91 schreef op woensdag 29 augustus 2012 @ 14:25:
Met Mongodb kan je objecten opslaan, misschien te veel van het goede voor je probleem, maar het kan wel.

Objecten is ook een goeie, gewoon class User met alle waardes er in. Ik zal even kijken naar de mogelijkheden van Mongodb

[RobIII]

FastFox91 schreef op woensdag 29 augustus 2012 @ 14:25:
Met Mongodb kan je objecten opslaan

Met 1001 andere DB's (en niet alleen "NoSQL" DB's als MongoDb maar ook RDBMS'en als MySQL, MSSQL, PostgreSql etc.) kan dat ook prima. Als je geen overtuigend argument hebt waarom precies MongoDb te gebruiken zie ik het nut van deze post niet behalve de keuze voor TS nog moeilijker te maken? Bomen en bos enzo. MongoDB is een compleet ander concept met z'n eigen voordelen maar ook nadelen t.o.v. een klassiek RDBMS.

Josaus schreef op woensdag 29 augustus 2012 @ 14:30:
Objecten is ook een goeie, gewoon class User met alle waardes er in. Ik zal even kijken naar de mogelijkheden van Mongodb

Zorg nou eerst maar eens dat je een RDBMS begrijpt en ga dan kijken naar mogelijke NoSQL oplossingen en of die passen bij je probleem. My guess: in dit geval totaal overbodig.

[ Voor 45% gewijzigd door RobIII op 29-08-2012 14:35 ]

[sopsop]

Josaus schreef op woensdag 29 augustus 2012 @ 14:30:
[...]

Moet ik hier uit opmaken dat je vindt dat ik nog even SQL bij moet leren ? Het kan zijn dat dit vanavond allemaal logisch is aangezien ik dan wakkerder ben, maar dat zie ik dan wel ;$

Ik bedoelde het niet zo cru. Maar stel je bent over een jaartje flink bedreven in (my)SQL dan kun je er -als je dit topic terugleest - smakelijk om lachen. Het vergt een bepaalde denkwijze om in tabellen en onderlinge relaties te kunnen denken. Die leer je vanzelf door het veel te gebruiken en er over te lezen, maar ook -zoals je nu al doet- er vragen over te stellen.

[Josaus]

sopsop schreef op woensdag 29 augustus 2012 @ 14:35:
[...]

Ik bedoelde het niet zo cru. Maar stel je bent over een jaartje flink bedreven in (my)SQL dan kun je er -als je dit topic terugleest - smakelijk om lachen. Het vergt een bepaalde denkwijze om in tabellen en onderlinge relaties te kunnen denken. Die leer je vanzelf door het veel te gebruiken en er over te lezen, maar ook -zoals je nu al doet- er vragen over te stellen.

Ik snap wat je bedoelt, als ik mijn topics terug lees voel ik me echt heel slecht -_-

[Paul]

Josaus schreef op woensdag 29 augustus 2012 @ 14:30:
[...]
Er komt niks bij, het aantal staat vast.

[...]
Het worden allemaal nummers.

Ok. En wat doe je als er alsnog iets bij komt?

Als de volgorde van die nummers niet uitmaakt kun je 1 waarde per rij opslaan en alle rijen van (datum+persoon) opvragen, en anders (met een (waarschijnlijk clustered) index) sorteren op een IDENTITY-kolom

[Josaus]

RobIII schreef op woensdag 29 augustus 2012 @ 14:31:
Zorg nou eerst maar eens dat je een RDBMS begrijpt en ga dan kijken naar mogelijke NoSQL oplossingen en of die passen bij je probleem. My guess: in dit geval totaal overbodig.

Als ik het goed begrijp: je linkt data uit de ene tabel (bv via ID's) aan andere data in een tabel.

[Loadichus]

Het voorbeeld van Icey gewoon aanhouden

ID | gebruikerID | datum | field | value

Wat mij voorheen hielp was het gewoon uitschrijven van velden met echte waardes. Hou de bovenstaande structuur maar aan en vul gewoon alle gegevens in.

Probeer vervolgens maar eens select query te maken met je gewenste resultaten en dan zul je zien dat je alles er uit kan halen.

[Josaus]

Tabel users:
(ja ik wil ook mensen op nonactief (record = false) kunnen zetten om te zorgen dat database niet vol raakt met onnodige velden)
ID | user | datum | record
1 | Kees | 29-08-2012 | true
2 | Sjaak | 30-08-2011 | true

Tabel data:
ID | UID | datum | leeftijd | gewicht | lengte
1 | 1 | 30-09-2012 | 15 | 60 | 180
2 | 2 | 30-09-2012 | 31 | 138 | 150
3 | 1 | 31-09-2012 | 15 | 61 | 187
4 | 2 | 31-09-2012 | 32 | 145 | 148

update.php:
Haal users uit database, dan voor elke user:
zoek data, maak nieuwe rij in database met ID ALS data veranderd is, UID, datum en waardes.

Is het nu duidelijk? xd

[ Voor 10% gewijzigd door Josaus op 29-08-2012 14:51 ]

[Icey]

Users:
userID | name | date | active

Values:
valueID | name

Data:
dataID | userID | valueID | date | value

[Josaus]

Icey schreef op woensdag 29 augustus 2012 @ 14:52:
Users:
userID | name | date | active

Values:
valueID | name

Data:
dataID | userID | valueID | date | value

Via jouw constructie kan je makkelijk waarden toevoegen, alleen dat is bij mij niet nodig en zorgt alleen voor een onnodig aantal rijen xd

[phex]

als alle values een moment opname zijn van 1 specifiek moment, is het handiger om alle values gewoon in de data tabel te laten zoals Josaus voorstelde.

Als je ook nog eens alle value types los gaat koppelen maak je een overbodige relatie.

Wikipedia: Inner-platform effect

In the database world, developers are sometimes tempted to bypass the RDBMS, for example by storing everything in one big table with three columns labelled entity ID, key, and value. While this entity-attribute-value model allows the developer to break out from the structure imposed by an SQL database, it loses out on all the benefits, since all of the work that could be done efficiently by the RDBMS is forced onto the application instead. Queries become much more convoluted, the indexes and query optimizer can no longer work effectively, and data validity constraints are not enforced. Performance and maintainability can be extremely poor.

[ Voor 66% gewijzigd door phex op 29-08-2012 14:59 ]

[Patriot]

Josaus schreef op woensdag 29 augustus 2012 @ 14:49:
Tabel users:
(ja ik wil ook mensen op nonactief (record = false) kunnen zetten om te zorgen dat database niet vol raakt met onnodige velden)
ID | user | datum | record
1 | Kees | 29-08-2012 | true
2 | Sjaak | 30-08-2011 | true

Tabel data:
ID | UID | datum | leeftijd | gewicht | lengte
1 | 1 | 30-09-2012 | 15 | 60 | 180
2 | 2 | 30-09-2012 | 31 | 138 | 150
3 | 1 | 31-09-2012 | 15 | 61 | 187
4 | 2 | 31-09-2012 | 32 | 145 | 148

Waarom is Kees gekrompen?

[Icey]

Nee, jouw oplossing zorgt voor een veelvoud aan onnodige rijen. Mijn oplossing beperkt dat juist!

Iedere keer als één van jouw waardes wijzigd (leeftijd, gewicht, lengte) voeg je een extra rij toe met gegevens die helemaal niet gewijzigd zijn (onnodige data!) en dat iedere dag weer.

Daarnaast, waarom zou je in hemelsnaam de leeftijd op willen slaan? Voeg de geboortedatum toe aan de tabel Users en je bent klaar.

Sla alleen gegevens op als iets wijzigd (ipv iedere dag) dan haal je gewoon de laatst bekende gegevens op...

Stom voorbeeld; je leeftijd wijzigd 1x per jaar en toch wil je het voor iedereen iedere dag op gaan slaan.

[ Voor 9% gewijzigd door Icey op 29-08-2012 14:58 ]

[phex]

Over de leeftijd heb je helemaal gelijk. Maar gewicht en lengte worden op een bepaalde datum vast gesteld. Dus samen zijn ze de values van een person+date combinatie.

Ik maak niet onnodig veel rijen, maar ik voeg extra kolommen voor. Zolang deze samen een moment zijn is dit perfect normalisatie. Bij jouw oplossing is elke waarde een nieuwe rij...

Ik weet niet precies wat voor applicatie de OT in gedachten heeft. Maar gewicht, lengte op een bepaalde datum lijkt me info die je altijd wil opslaan op het moment dat je deze checkt. Als het gewicht niet gewijzigd is, betekent dat niet dat die data niet relevant is, integendeel!

Lees mijn post over anti-patterns ook even hierboven waarom jouw oplossing meestal geen goede keuze is.

[ Voor 72% gewijzigd door phex op 29-08-2012 15:07 ]

[Icey]

phex schreef op woensdag 29 augustus 2012 @ 15:00:
Over de leeftijd heb je helemaal gelijk. Maar gewicht en lengte worden op een bepaalde datum vast gesteld. Dus samen zijn ze de values van een person+date combinatie.

Ik maak niet onnodig veel rijen, maar ik voeg extra kolommen voor. Zolang deze samen een moment zijn is dit perfect normalisatie. Bij jouw oplossing is elke waarde een nieuwe rij...

Lees mijn post over anti-patterns ook even hierboven waarom jouw oplossing meestal geen goede keuze is.

Ik kan mij niet voorstellen dat gewicht & lengte iets is wat dagelijks via een cronjob gemeten kan worden dus ik gok dat het een voorbeeld is en de TS hele andere dingen in zijn database wil opslaan.Daarnaast vind ik het raar om zowel gewicht & lengte op te slaan als maar één van beide gewijzigd word.

[phex]

Omdat het een momentopname is. Hij gebruikt een datum veld dus het is niet direct de waarde van een persoon, maar de combinatie datum persoon. Zoals ik al net zei, als de waardes niet gewijzigd zijn, is het nog steeds nuttige data.

Ik denk namelijk dat hij met een cronjob (3d) grafieken wil maken

[ Voor 20% gewijzigd door phex op 29-08-2012 15:11 ]

[Paul]

Josaus schreef op woensdag 29 augustus 2012 @ 14:49:
Tabel data:
ID | UID | datum | leeftijd | gewicht | lengte

Ah, het zijn wel getallen (het datatype) maar het zijn geen gelijksoortige gegevens, een leeftijd is af te leiden uit de geboortedatum iets heel anders dan een gewicht of een lengte.

In dat geval inderdaad zo de tabel maken. Icey's tabel KAN nuttig zijn, maar dan komt phex' Inner-Platform inderdaad om de hoek kijken, voordat je zoiets maakt moet je goed weten waarom je het zo doet en niet af laat handelen door het product dat er specifiek voor geschreven is (de database)

[phex]

persoon
id | naam | geboortedatum

meetdata
datum | persoon_id | lengte | gewicht

[OkkE]

Ik ben nu wel benieuwd of die "leeftijd", "lengte" en "gewicht" zomaar voorbeeld data is, en er dus beter gesproken kan worden over A, B en C. Of dat het ook echt die data is, want dan zou o.a. geboortedatum een veel betere optie zijn dan leeftijd.

[Caelorum]

Patriot schreef op woensdag 29 augustus 2012 @ 14:57:
[...] Waarom is Kees gekrompen?

Psst.. Sjaak is gekrompen...

[L-VIS]

Caelorum schreef op woensdag 29 augustus 2012 @ 15:47:
[...]

Psst.. Sjaak is gekrompen...

Technisch gezien geen van beiden, want die datum bestaat niet of ze zijn een een ander universum....

[zwippie]

offtopic:
Voor iedereen die in de lach schiet bij multidimensionale databases: OLAP!

Dat is trouwens wel enigszins na te bootsen in een relationele database door voor elke dimensie een tabel te maken, en dan nog een tabel met een kolommen voor elke dimensie en een kolom met een waarde. Maar ik denk niet dat TS daar op zit te wachten.

[Josaus]

Patriot schreef op woensdag 29 augustus 2012 @ 14:57:
Waarom is Kees gekrompen?

Sjaak is juist gekrompen

Icey schreef op woensdag 29 augustus 2012 @ 14:57:
Nee, jouw oplossing zorgt voor een veelvoud aan onnodige rijen. Mijn oplossing beperkt dat juist!

Iedere keer als één van jouw waardes wijzigd (leeftijd, gewicht, lengte) voeg je een extra rij toe met gegevens die helemaal niet gewijzigd zijn (onnodige data!) en dat iedere dag weer.

Daarnaast, waarom zou je in hemelsnaam de leeftijd op willen slaan? Voeg de geboortedatum toe aan de tabel Users en je bent klaar.

Sla alleen gegevens op als iets wijzigd (ipv iedere dag) dan haal je gewoon de laatst bekende gegevens op...

Stom voorbeeld; je leeftijd wijzigd 1x per jaar en toch wil je het voor iedereen iedere dag op gaan slaan.

Ja, nu zie ik wat je bedoelt. Bij mijn ding zet ik het er altijd in, behalve als er niks veranderd is, dan komt er geen rij. Dan neemt hij de waarden van de vorige rij (= dag). Die leeftijd was een voorbeeld xD Ik gebruik de waarde leeftijd niet, en al zou ik dat doen, dan zou ik geboortedatum bij users implanteren en leeftijd berekenen..

phex schreef op woensdag 29 augustus 2012 @ 15:00:
Over de leeftijd heb je helemaal gelijk. Maar gewicht en lengte worden op een bepaalde datum vast gesteld. Dus samen zijn ze de values van een person+date combinatie.

Ik maak niet onnodig veel rijen, maar ik voeg extra kolommen voor. Zolang deze samen een moment zijn is dit perfect normalisatie. Bij jouw oplossing is elke waarde een nieuwe rij...

Ik weet niet precies wat voor applicatie de OT in gedachten heeft. Maar gewicht, lengte op een bepaalde datum lijkt me info die je altijd wil opslaan op het moment dat je deze checkt. Als het gewicht niet gewijzigd is, betekent dat niet dat die data niet relevant is, integendeel!

Lees mijn post over anti-patterns ook even hierboven waarom jouw oplossing meestal geen goede keuze is.

Je hebt compleet gelijk

phex schreef op woensdag 29 augustus 2012 @ 15:09:
Omdat het een momentopname is. Hij gebruikt een datum veld dus het is niet direct de waarde van een persoon, maar de combinatie datum persoon. Zoals ik al net zei, als de waardes niet gewijzigd zijn, is het nog steeds nuttige data.

Ik denk namelijk dat hij met een cronjob (3d) grafieken wil maken

Ja, het gaat me om de vergelijking van:
- is er iets gebeurd;
- is er veel gebeurd.

Bijvoorbeeld als je het voor een spel gebruikt, dan kan je op die manier de inactiviteit van een speler bepalen aan de hand van speeltijd, experience etc.

OkkE schreef op woensdag 29 augustus 2012 @ 15:29:
Ik ben nu wel benieuwd of die "leeftijd", "lengte" en "gewicht" zomaar voorbeeld data is, en er dus beter gesproken kan worden over A, B en C. Of dat het ook echt die data is, want dan zou o.a. geboortedatum een veel betere optie zijn dan leeftijd.

Het is inderdaad voorbeelddata.

VERGEET DE LEEFTIJD, NIET ZEUREN OVER DE LEEFTIJD.

Het gaat wel over momentopnamen, het is data die elke dag kan veranderen, maar het hoeft niet. Het is voor statistieken, grafieken.

L-VIS schreef op woensdag 29 augustus 2012 @ 15:50:
[...]

Technisch gezien geen van beiden, want die datum bestaat niet of ze zijn een een ander universum....

You know too much..


Ik heb even heel leuk een voorbeeldje gemaakt voor het nut van een 4D tabel:
Stel, je wil de prijzen van olieconcerns vergelijken. Dan maak je een simpel tabelletje:

	Diesel	Euro 95	Euro 98
Shell	1,79	1,88	3,73
BP	1,72	1,35	3,58
etc..	1,75	1,80	3,78

waarschuwing: data kan incorrect zijn!
Maar dan! Straks wil je dat elke dag doen, voor meerdere landen. Als je dat nou voor 3 jaar doet, voor 30 landen, dan heb je 3 * 365 * 30 = 32850 tabellen. Dat is een beetje onhandig hè? Die tabel hierboven heeft, zoals ik het noem, 2 dimensies, X en Y, rij en kolom. Om dit dagelijks te doen, voegen we een dimensie toe: datum. Nu heb je nog maar 30 tabellen nodig! (ja, dat is te doen en nog handig ook, maar geniet van het voorbeeld) Om al deze data in één "tabel" te proppen, voegen we nóg een dimensie toe: het land. Nu kan je lekker al je data in de tabel proppen, en er makkelijk door bladeren.
Velen van jullie zullen dit als onnodig beschouwen, maar ik vind het wel wat hebben :3

[ Voor 14% gewijzigd door Josaus op 29-08-2012 19:13 ]

[RobIII]

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Maar dan! Straks wil je dat elke dag doen, voor meerdere landen. Als je dat nou voor 3 jaar doet, voor 30 landen, dan heb je 3 * 365 * 30 = 32850 tabellen.

...en dat wil je niet.

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Dat is een beetje onhandig hè?

Nogal ja.

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Nu heb je nog maar 30 tabellen nodig!

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Nu kan je lekker al je data in de tabel proppen, en er makkelijk door bladeren.

Definieer makkelijk

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Velen van jullie zullen dit als onnodig beschouwen, maar ik vind het wel wat hebben :3

Ik vind 't een stompzinnig (excuse le mot) idee. Je bent met zaken bezig waar je, sorry, geen drol van snapt. Ga nou eens eerst zorgen dat je de basis onder de knie hebt (lees: normaliseren) en probeer het dan nog eens.

Hint: Dit gaat prima met 1 tabel.

[Josaus]

Rustig Rob xD Ik weet ook dat het met één tabel kan, maar vind het gewoon een leuk idee..

[RobIII]

Josaus schreef op woensdag 29 augustus 2012 @ 19:29:
Rustig Rob xD

Ik ben rustig

Josaus schreef op woensdag 29 augustus 2012 @ 19:29:
Ik weet ook dat het met één tabel kan

...ik twijfel ernstig aan deze bewering...

Josaus schreef op woensdag 29 augustus 2012 @ 19:29:
maar vind het gewoon een leuk idee..

Als je een kuil voor jezelf graven leuk vindt
Een RDBMS is er juist om gemaakt om te spitten in een shitload aan data; je maakt 't jezelf niet makkelijker als je die data (onnodig!) gaat verspreiden over een paar duizend/honderd tabellen.

[ Voor 30% gewijzigd door RobIII op 29-08-2012 19:31 ]

[Josaus]

Ik snap wat je bedoeld. Tabellen aan elkaar koppelen doe ik wel vaker. Ik ben ook niet van plan om die data te gaan verspreiden over duizend tabellen Maar volgens mij wil je een punt bewijzen, dat heb je gedaan, dus houdt er a.u.b. over op, ik heb mijn antwoord en snap dat je een fan van normaliseren bent

[RobIII]

Josaus schreef op woensdag 29 augustus 2012 @ 19:39:
en snap dat je een fan van normaliseren bent

Ik ben geen "fan van normaliseren", ik ben hater van anti-patterns

Josaus schreef op woensdag 29 augustus 2012 @ 19:39:
dus houdt er a.u.b. over op

Euh, pardon? Jij komt hier een vraag stellen en krijgt, goed bedoeld might I add, advies van alle kanten dat je knal in de wind slaat...

[ Voor 37% gewijzigd door RobIII op 29-08-2012 20:15 ]

[Josaus]

Ik hou van haters
Ik snap dat het goed bedoeld is, en vind het fijn dat iedereen helpt Ik denk dat ik hateriger word door mensen die altijd negatief reageren tegen newbies like me.. (ja, die mensen zijn er) Het spijt me als ik je gekwetst heb
Maar het belangrijkste:

Bedankt iedereen

[Hydra]

Josaus schreef op woensdag 29 augustus 2012 @ 20:38:
Ik hou van haters
Ik snap dat het goed bedoeld is, en vind het fijn dat iedereen helpt Ik denk dat ik hateriger word door mensen die altijd negatief reageren tegen newbies like me.. (ja, die mensen zijn er) Het spijt me als ik je gekwetst heb
Maar het belangrijkste:

Volgens mij vergeet je hier ff dat hier een boel mensen zitten die dit als werk doen, en daar overdag leuke factuurtjes van 100E per uur of meer voor sturen, en jou dan gratis en voor niets feedback geven. Dat iemand je zegt dat iets een dom idee is, is niet 'haten', dat is in dit geval gewoon terecht. Iedereen is ooit newbie geweest, daar is niks mis mee, maar deze kritiek zorgt er gewoon voor dat je leert van de fouten van anderen in plaats van daar zelf eindeloos tijd mee te verspillen. En jouw zogenaamde '3D' database is echt een enorme tijdsverspilling.

[Gomez12]

Hydra schreef op woensdag 29 augustus 2012 @ 22:46:
[...]
En jouw zogenaamde '3D' database is echt een enorme tijdsverspilling.

Het probleem is veelal dat er binnen zeer specialistische doeleinden best wel een markt voor is en dat het daar best een doorbraak kan zijn.

Alleen dan praat je over big-data opstellingen en dat is waar "newbees" vaak de fout ingaan, die vinden 100 miljoen records al big data terwijl menig rdbms dat een peuleschil vindt.

Kijk, ga je praten over de beurskoersen per seconde van alle beurzen ter wereld en dat over een periode van 30 jaar van alle beursgenoteerden, dan ga je aparte oplossingen nodig hebben.

Maar waar de meeste mensen zich op verkijken is dat menig rdbms zo goed als alles kan afhandelen en dat de alternatieven (bijv nosql) eigenlijk enkel maar sneller zijn voor een subset van de gegevens die een rdbms af kan handelen.

Oftewel het is geen "enorme" tijdsverspilling pur sang, alleen dat bijv een twitter in het nieuws komt met dat ze extreme db-variant x gebruiken betekent niet dat jij het ook moet gebruiken voordat je ergens op het server / db-engines niveau van twitter zit. Een twitter en consorten gebruiken namelijk over het algemeen naast extreme db-variant x nog 10 andere db-engines die wel standaard zijn en die de bulk van de data afhandelen.
Terwijl een newbee dan enkel de extreme db-variant in gaat zetten want hij heeft niet de tijd / geld om meerdere db-engines te onderhouden. En dan kom je over het algemeen toch wel weer het beste uit met een rdbms.

[NMe]

Gomez12 schreef op donderdag 30 augustus 2012 @ 00:00:
[...]

Het probleem is veelal dat er binnen zeer specialistische doeleinden best wel een markt voor is en dat het daar best een doorbraak kan zijn.

Het specifieke probleem in dit topic is, naast dat de topicstarter lichtelijk eigenwijs is (wat niet erg is trouwens, ben ik ook ), dat er redenen bij worden gehaald die een 3D-database goedpraten. Ja, die redenen en situaties zijn er, maar dat betekent nog niet dat het in veruit de meeste gevallen geen goed idee is, en naar alle waarschijnlijkheid in het geval van de topicstarter ook niet. De topicstarter kan in dit geval beter eerst leren kruipen voordat we hem laten rennen.

[Gomez12]

NMe schreef op donderdag 30 augustus 2012 @ 00:44:
[...]
Het specifieke probleem in dit topic is, naast dat de topicstarter lichtelijk eigenwijs is (wat niet erg is trouwens, ben ik ook ), dat er redenen bij worden gehaald die een 3D-database goedpraten. Ja, die redenen en situaties zijn er, maar dat betekent nog niet dat het in veruit de meeste gevallen geen goed idee is, en naar alle waarschijnlijkheid in het geval van de topicstarter ook niet. De topicstarter kan in dit geval beter eerst leren kruipen voordat we hem laten rennen.

Topicstart liet ik al links liggen toen TS begon over het bereid zijn zelf een 3d-database te bouwen. Terwijl hij blijkbaar nog niet eens zijn concurrenten kan googlen...

Mijn reactie ging puur om het gequote stukje

[NMe]

Uiteraard, maar wilde de rest van het topic even in perspectief plaatsen en zorgen dat de topicstarter niet de verkeerde ideeën krijgt, voor zover dat nog niet duidelijk mocht zijn uit bovenstaande discussie.

[Jegorex]

Gomez12 schreef op donderdag 30 augustus 2012 @ 00:00:
[...]

Kijk, ga je praten over de beurskoersen per seconde van alle beurzen ter wereld en dat over een periode van 30 jaar van alle beursgenoteerden, dan ga je aparte oplossingen nodig hebben.

Dan past Josaus zijn database toch gewoon aan om per seconde het gewicht van 1000 mensen vanaf hun geboorte te meten?
Je kunt je ideeën aanpassen, of je past je doel aan

[alienfruit]

Tjonguh, is het huidige uurloon maar 100euro/uur?

[Icey]

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:

Ik heb even heel leuk een voorbeeldje gemaakt voor het nut van een 4D tabel:
Stel, je wil de prijzen van olieconcerns vergelijken. Dan maak je een simpel tabelletje:

	Diesel	Euro 95	Euro 98
Shell	1,79	1,88	3,73
BP	1,72	1,35	3,58
etc..	1,75	1,80	3,78

waarschuwing: data kan incorrect zijn!
Maar dan! Straks wil je dat elke dag doen, voor meerdere landen. Als je dat nou voor 3 jaar doet, voor 30 landen, dan heb je 3 * 365 * 30 = 32850 tabellen. Dat is een beetje onhandig hè? Die tabel hierboven heeft, zoals ik het noem, 2 dimensies, X en Y, rij en kolom. Om dit dagelijks te doen, voegen we een dimensie toe: datum. Nu heb je nog maar 30 tabellen nodig! (ja, dat is te doen en nog handig ook, maar geniet van het voorbeeld) Om al deze data in één "tabel" te proppen, voegen we nóg een dimensie toe: het land. Nu kan je lekker al je data in de tabel proppen, en er makkelijk door bladeren.
Velen van jullie zullen dit als onnodig beschouwen, maar ik vind het wel wat hebben :3

Landen
CountryID
Name

Bedrijven
CompanyID
Name

Brandstoffen
FuelID
Name

Prijzen
PriceID
CountryID
CompanyID
FuelID
Date
Price (in Dollars)

Tadaa, 4 tabellen is genoeg. Maar nu hou ik op, volgens mij ga je het toch op je eigen manier doen.

[Paul]

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
Ik heb even heel leuk een voorbeeldje gemaakt voor het nut van een 4D tabel:

Ik denk dat je heel wat minder weerstand gaat ondervinden hier wanneer je die dingen geen 4D tabel maar een 4D array of zo noemt, en de opslag ervan in een database loskoppelt van de structuur van de array

'Tabel' is namelijk ook de naam van zo'n ding in een database.

[ Voor 7% gewijzigd door Paul op 30-08-2012 09:44 ]

[HuHu]

Je kunt het ook heel handig oplossen met een 2D tabel zoals deze:

ID	Waarde
{shell,diesel,01,01,2012}	<eurocent>179</eurocent>
{BP,diesel,01,01,2012}	<eurocent>172</eurocent>
{shell,euro95,01,01,2012}	<eurocent>188</eurocent>
{BP,euro95,01,01,2012}	<eurocent>135</eurocent>
enz...

Dan kun je heel hip met JSON het ID van de tabel opvragen. Deze truc noemen ze ook wel dimensionality reducion van de feature space, zonder verlies van data zoals met prinicpal component analysis!! Je bent immers van 4D naar 2D gegaan. Het is ook heel uitbreidbaar, omdat je in het JSON-ID zonder problemen, bijvoorbeeld, het land kunt toevoegen.

Door het gebruik van XML in de waarde-kolom kun je ook vrij eenvoudig andere munteenheden toevoegen, zoals: <dollar>1.75</dollar> of <ougiya>1.2</ougiya>.

[Gomez12]

HuHu schreef op donderdag 30 augustus 2012 @ 10:05:
Je kunt het ook heel handig oplossen met een 2D tabel zoals deze:
...
Door het gebruik van XML in de waarde-kolom kun je ook vrij eenvoudig andere munteenheden toevoegen, zoals: <dollar>1.75</dollar> of <ougiya>1.2</ougiya>.

I hope your joking...

Waarom dan niet alles in 1 veld douwen, of heck waarom niet alles gewoon in 1 text-bestand douwen. Ik bedoel de dbase-functionaliteiten gebruik je toch al niet meer als je dit soort constructies gaat verzinnen,

[ValHallASW]

Paul schreef op donderdag 30 augustus 2012 @ 09:43:
[...]
Ik denk dat je heel wat minder weerstand gaat ondervinden hier wanneer je die dingen geen 4D tabel maar een 4D array of zo noemt, en de opslag ervan in een database loskoppelt van de structuur van de array

Inderdaad. Wat de TS lijkt te willen is een 2D/3D/nD cross table / pivottable. Daar heb je in een genormaliseerde database (n+1) tabellen voor nodig: één voor de data in het vlak en één voor elke as om de assen te labelen.

Zie het voorbeeld van Icey: je hebt vier assen (type brandstof, leverancier, land, datum) en voor elke set van vier sla je één datapunt op. In principe heb je daar vijf tabellen voor nodig, maar de 'datum'-kolom hoef je niet af te splitsen omdat het een eenduidige en tijdsinvariante waarde is.

[ Voor 6% gewijzigd door ValHallASW op 30-08-2012 10:14 ]

[HuHu]

Gomez12 schreef op donderdag 30 augustus 2012 @ 10:11:
[...]

I hope your joking...

Hoe kom je daar nu bij?

[Janoz]

Josaus schreef op woensdag 29 augustus 2012 @ 17:55:
......

Ik heb even heel leuk een voorbeeldje gemaakt voor het nut van een 4D tabel:
Stel, je wil de prijzen van olieconcerns vergelijken. Dan maak je een simpel tabelletje:

	Diesel	Euro 95	Euro 98
Shell	1,79	1,88	3,73
BP	1,72	1,35	3,58
etc..	1,75	1,80	3,78

waarschuwing: data kan incorrect zijn!
Maar dan! Straks wil je dat elke dag doen, voor meerdere landen. Als je dat nou voor 3 jaar doet, voor 30 landen, dan heb je 3 * 365 * 30 = 32850 tabellen. Dat is een beetje onhandig hè? Die tabel hierboven heeft, zoals ik het noem, 2 dimensies, X en Y, rij en kolom. Om dit dagelijks te doen, voegen we een dimensie toe: datum. Nu heb je nog maar 30 tabellen nodig! (ja, dat is te doen en nog handig ook, maar geniet van het voorbeeld) Om al deze data in één "tabel" te proppen, voegen we nóg een dimensie toe: het land. Nu kan je lekker al je data in de tabel proppen, en er makkelijk door bladeren.
Velen van jullie zullen dit als onnodig beschouwen, maar ik vind het wel wat hebben :3

De fout die je hier maakt is dat je teveel redeneert vanuit de weergave van de data. Een database bevat tabellen welke records bevatten. Dat is conceptueel weer te geven als een tabel zoals je die ook op een excel sheet hebt, maar dat betekend echter niet automatisch dat je dat ook de andere kant op kunt redeneren.

Vanuit het perspectief van de database bestaat een tabel uit een definitie van kolommen (restricties en relaties (de koppelingen met kolommen in andere tabellen)) en een set records die aan die definitie voldoen. Niets meer en niets minder (muv uiteraard van enkele apart opgeslagen metadata om het zoeken en afdwingen van die restricties te vergemakkelijken uiteraard). Zelfs de volgorde is niet vastgesteld!

De weergavevorm met rijen en cellen komt pas op het moment dat je kiest voor een weergave. Dat kan inderdaad door simpel alle records onder elkaar te zetten, maar ook als een tree, met een grafiek of een '3d'-dataset. Je moet echter het idee loslaten dat de gegevens die je op het scherm ziet ook in die vorm in de database moeten komen. In de tabellen op het scherm staat data die op een bepaalde manier aan elkaar gerelateerd is. Als ontwikkelaar (of ontwerper) is het je taak om die relaties uit te zoeken en dit om te zetten naar een databasemodel. Ja dat model bestaat ook uit tabellen, maar dat zijn 'data' tabellen (goed door de computer te interpreteren), en niet 'weergave' tabellen (goed door mens te interpreteren).

[Hydra]

HuHu schreef op donderdag 30 augustus 2012 @ 10:20:
Hoe kom je daar nu bij?

Ik ga ervanuit dat het een grap is, maar hou even rekening mee dat dergelijke "subtiele humor" voor een beginner als de TS niet te begrijpen is en hem dit op verkeerde ideeen kan brengen.

[FastFox91]

RobIII schreef op woensdag 29 augustus 2012 @ 14:31:
[...]

Met 1001 andere DB's (en niet alleen "NoSQL" DB's als MongoDb maar ook RDBMS'en als MySQL, MSSQL, PostgreSql etc.) kan dat ook prima. Als je geen overtuigend argument hebt waarom precies MongoDb te gebruiken zie ik het nut van deze post niet behalve de keuze voor TS nog moeilijker te maken? Bomen en bos enzo. MongoDB is een compleet ander concept met z'n eigen voordelen maar ook nadelen t.o.v. een klassiek RDBMS.


[...]

Zorg nou eerst maar eens dat je een RDBMS begrijpt en ga dan kijken naar mogelijke NoSQL oplossingen en of die passen bij je probleem. My guess: in dit geval totaal overbodig.

De keuze moeilijker maken was niet mijn bedoeling. Ik wil alleen aangeven dat zoiets bestaat. Daarnaast zie ik bij jou ook geen overtuigend argument om een klassiek RDBMS te gebruiken. Je adviseert de TS om eerst een RDBMS te begrijpen, daar ben ik het niet mee eens. Het kan juist een voordeel zijn om NoSQL te leren, zonder/weinig kennis van SQL.

[RobIII]

FastFox91 schreef op donderdag 30 augustus 2012 @ 17:48:
Daarnaast zie ik bij jou ook geen overtuigend argument om een klassiek RDBMS te gebruiken.

Je geeft zelf al aan: "misschien iets teveel van 't goede". Daarmee zeg je zelf al dat je 't onnodig moeilijk(er) maakt.

FastFox91 schreef op donderdag 30 augustus 2012 @ 17:48:
Je adviseert de TS om eerst een RDBMS te begrijpen, daar ben ik het niet mee eens. Het kan juist een voordeel zijn om NoSQL te leren, zonder/weinig kennis van SQL.

Een RDBMS is, IMHO, nog altijd simpeler te begrijpen en een betere basis dan een of andere magische "document store" waar je alles in kunt flikkeren zonder je te bekommeren om structuur. Begrijp me niet verkeerd, ik ben prima bekend met MongoDB, maar een dergelijke oplossing gebruik je eerder wanneer je data niet in een relationeel model past of je erg omslachtig je data bijelkaar (lees: veel round-trips of ingewikkelde queries met veel joins e.d. bijvoorbeeld) moet plukken en dus over 't algemeen wanneer je met gedenomaliseerde data werkt. Dat is hier helemaal niet aan de orde; sterker nog: deze data is hoogst gestructureerd.

Andere "voordelen" van een NoSQL oplossing die vaak worden aangehaald (redundancy/high-availability, scaling, big-data en noem-maar-op) zijn hier helemaal (nog) niet aan de orde*. En tot slot denk ik dat je post het beeld van TS, die toch waarschijnlijk "nog wat nat achter de oren is", aardig vertroebelt met je suggestie. NoSQL is nooit bedoeld als "alternatief voor een RDBMS". Ja, je kunt er ook data in opslaan maar daar houdt de gelijkenis al een heel eind op. En, hoewel je specifiek MongoDB aanhaalt, de denkrichting NoSQL is in die zin ook nog eens gevaarlijk IMHO omdat onder de paraplu NoSQL een heleboel producten vallen die wild van elkaar variëren waarbij je dat onder de RDBMS paraplu, op SQL-dialectjes/derivaten en wat andere kleinigheidjes na, véél minder hebt. Maar goed; die laatste opmerking is dus vooral 'pre-emptive' voor TS en niet iets wat specifiek op je post slaat oid.

* En vaak met een beetje fatsoenlijk RDBMS ook prima (of althans een heel eind) op te vangen met clustering, loadbalancing, caching, partitioning en weet-ik-veel voor technieken.

[ Voor 14% gewijzigd door RobIII op 30-08-2012 18:19 ]

[FastFox91]

Ik zeg dat het "misschien iets te veel van 't goede is", omdat het ook prima kan met SQL, ik zeg niet dat ik het onnodig veel moeilijker maak, dat maak jij ervan. Omdat MongoDB ook om kan gaan met ongestructureerde data en SQL minder goed, wil nog niet zeggen dat alle gestructureerde data maar met SQL moet worden opgeslagen. Het verschil is dat jij RDBMS simpeler vindt te begrijpen en ik juist NoSQL, dat kan.

Josaus schreef op woensdag 29 augustus 2012 @ 14:30:
[...]
Objecten is ook een goeie, gewoon class User met alle waardes er in. Ik zal even kijken naar de mogelijkheden van Mongodb

Aan deze post is te zien dat TS al begrijpt wat ik bedoel, terwijl in dit topic al aardig wat posts gaan om TS te overtuigen hoe het zou moeten met SQL. Wat die uiteindelijk kiest maakt mij niet uit, maar hij weet nu van het bestaan af.

Verder vind ik deze discussie aardig offtopic, ik wilde alleen reageren op je opmerking dat je mijn post nutteloos vond.

[RobIII]

FastFox91 schreef op donderdag 30 augustus 2012 @ 18:32:
Omdat MongoDB ook om kan gaan met ongestructureerde data en SQL minder goed, wil nog niet zeggen dat alle gestructureerde data maar met SQL moet worden opgeslagen

Over het algemeen zal een RDBMS wel beter presteren op dit vlak maar los daarvan: de TS is bezig in "3 (en meer) dimensies" te denken. Dan vind ik 't behoorlijk gevaarlijk een NoSQL-achtige als mogelijke oplossing te opperen want daarin gaat 't hem geheid lukken met alle consequenties van dien (zoals het zichzelf onnodig moeilijk maken de data te queryen, aggregeren etc.)

FastFox91 schreef op donderdag 30 augustus 2012 @ 18:32:
Het verschil is dat jij RDBMS simpeler vindt te begrijpen en ik juist NoSQL, dat kan.

Uiteraard.

[Gomez12]

RobIII schreef op donderdag 30 augustus 2012 @ 18:11:
[...]
Begrijp me niet verkeerd, ik ben prima bekend met MongoDB, maar een dergelijke oplossing gebruik je eerder wanneer je data niet in een relationeel model past of je erg omslachtig je data bijelkaar (lees: veel round-trips of ingewikkelde queries met veel joins e.d. bijvoorbeeld) moet plukken en dus over 't algemeen wanneer je met gedenomaliseerde data werkt.

Ach, dan voeg ik voor de volledigheid maar weer even toe dat "veel joins" een relatief begrip is. Als 1 master-overzicht 20 joins vereist dan is dit geen ramp.

Ingewikkelde queries zijn op zichzelf ook geen ramp als je data structuur het vereist.

Een data structuur opzetten is een balans vinden tussen normaliseren / denormaliseren. Als 99% van je query's met 3 of 4 joins werken dan is die ene procent niet zo belangrijk, als 99% van je query's ingewikkeld zijn dan is je datastructuur verkeerd.

FastFox91 schreef op donderdag 30 augustus 2012 @ 18:32:
Omdat MongoDB ook om kan gaan met ongestructureerde data en SQL minder goed, wil nog niet zeggen dat alle gestructureerde data maar met SQL moet worden opgeslagen.

Ik denk dat jij NoSQL verkeerd begrijpt, use the right tool for the right job. Je gestructureerde data in je SQL-db, je ongestructureerde data in je NoSQL-db.
En ja, dit betekent dat je 2 db's mag bij gaan houden als je een combinatie hebt.
Maar dit is ook de praktijk bij de serieuzere partijen.

Ga geen ongestructureerde data in een rdbms gooien (maar probeer het te structureren)
Maar ga ook geen gestructureerde data in een NoSQL dbms gooien (ehm, ehm, destructureer het om op te slaan en structureer het dan weer om te gebruiken in je app? zoiets?)

Ik ken werkelijk waar geen enkele case van een NoSQL db die niet als showcase bedoelt is en die zonder rdbms ernaast draait.

[RobIII]

Gomez12 schreef op donderdag 30 augustus 2012 @ 18:56:
Ach, dan voeg ik voor de volledigheid maar weer even toe dat "veel joins" een relatief begrip is. Als 1 master-overzicht 20 joins vereist dan is dit geen ramp.

Nee, dat bedoelde ik ook niet zo zeer. Ik doelde meer op draken van queries met god-knows-what voor vage constructies. Maar inderdaad, en uiteraard, zegt 't "aantal joins" helemaal niets verder.

Gomez12 schreef op donderdag 30 augustus 2012 @ 18:56:
Ingewikkelde queries zijn op zichzelf ook geen ramp als je data structuur het vereist.

Again, uiteraard. Ik doelde meer op queries waarbij je jezelf in allerlei bochten moet wringen omdat je je data al op allerlei rare manieren in tables hebt proberen te rammen omdat 't eigenlijk ongestructureerde data is.

Gomez12 schreef op donderdag 30 augustus 2012 @ 18:56:
Een data structuur opzetten is een balans vinden tussen normaliseren / denormaliseren. Als 99% van je query's met 3 of 4 joins werken dan is die ene procent niet zo belangrijk, als 99% van je query's ingewikkeld zijn dan is je datastructuur verkeerd.

Psies.

[Josaus]

Janoz schreef op donderdag 30 augustus 2012 @ 10:43:
[...]


De fout die je hier maakt is dat je teveel redeneert vanuit de weergave van de data. Een database bevat tabellen welke records bevatten. Dat is conceptueel weer te geven als een tabel zoals je die ook op een excel sheet hebt, maar dat betekend echter niet automatisch dat je dat ook de andere kant op kunt redeneren.

Vanuit het perspectief van de database bestaat een tabel uit een definitie van kolommen (restricties en relaties (de koppelingen met kolommen in andere tabellen)) en een set records die aan die definitie voldoen. Niets meer en niets minder (muv uiteraard van enkele apart opgeslagen metadata om het zoeken en afdwingen van die restricties te vergemakkelijken uiteraard). Zelfs de volgorde is niet vastgesteld!

De weergavevorm met rijen en cellen komt pas op het moment dat je kiest voor een weergave. Dat kan inderdaad door simpel alle records onder elkaar te zetten, maar ook als een tree, met een grafiek of een '3d'-dataset. Je moet echter het idee loslaten dat de gegevens die je op het scherm ziet ook in die vorm in de database moeten komen. In de tabellen op het scherm staat data die op een bepaalde manier aan elkaar gerelateerd is. Als ontwikkelaar (of ontwerper) is het je taak om die relaties uit te zoeken en dit om te zetten naar een databasemodel. Ja dat model bestaat ook uit tabellen, maar dat zijn 'data' tabellen (goed door de computer te interpreteren), en niet 'weergave' tabellen (goed door mens te interpreteren).

Ja, dat was het grappige: nadat ik dit schreef, bedacht ik een manier om het gewoon te doen *facepalm*

En verder:

Josaus schreef op woensdag 29 augustus 2012 @ 14:49:
Tabel users:
(ja ik wil ook mensen op nonactief (record = false) kunnen zetten om te zorgen dat database niet vol raakt met onnodige velden)
ID | user | datum | record
1 | Kees | 29-08-2012 | true
2 | Sjaak | 30-08-2011 | true

Tabel data:
ID | UID | datum | leeftijd | gewicht | lengte
1 | 1 | 30-09-2012 | 15 | 60 | 180
2 | 2 | 30-09-2012 | 31 | 138 | 150
3 | 1 | 31-09-2012 | 15 | 61 | 187
4 | 2 | 31-09-2012 | 32 | 145 | 148

update.php:
Haal users uit database, dan voor elke user:
zoek data, maak nieuwe rij in database met ID ALS data veranderd is, UID, datum en waardes.

Is het nu duidelijk? xd

Dat wordt 'm. Ik heb alle berichten even doorgelezen (was gisteren weg), en ben blij dat mensen hun mening uiten en me helpen De database wordt inderdaad niet zo groot, maar door ervaring ben ik hier bang voor geworden (had een website met een tracker die o.a. MySQL injecties opslaat in database, en had na een tijdje 10m+ queries o_o, het laden van een pagina duurde hier ontzettend lang door ).

[Paul]

Josaus schreef op vrijdag 31 augustus 2012 @ 12:15:
en had na een tijdje 10m+ queries o_o, het laden van een pagina duurde hier ontzettend lang door ).

Dat is gewoon slecht ontwerp

Uiteraard is er zoiets als overdreven 'premature optimization' maar bij het maken van een pagina moet je wel in gedachten houden dat zoiets wel eens (veel) langer of vaker gebruikt kan worden dan je denkt Gaan itereren over, of iets doen met alle rijen die je terugkrijgt is wel vaker een slecht idee, zeker als ieder result een extra round-trip naar de DB oplevert

[Josaus]

Paul schreef op vrijdag 31 augustus 2012 @ 12:22:
[...]
Dat is gewoon slecht ontwerp

Uiteraard is er zoiets als overdreven 'premature optimization' maar bij het maken van een pagina moet je wel in gedachten houden dat zoiets wel eens (veel) langer of vaker gebruikt kan worden dan je denkt Gaan itereren over, of iets doen met alle rijen die je terugkrijgt is wel vaker een slecht idee, zeker als ieder result een extra round-trip naar de DB oplevert

Het grappige was, dat dat allerlei spambots waren (onder anderen). Hele rare invoer geven die dingen.. Is dat trouwens normaal ? XD