[php/MySql] array's in MySql mogelijk?

[Sosabowski]

Hallo,
ik ben bezig met een database voor hitlijsten. Dus van elke week een rijtje van 20 cd's. Nu heb ik dit

SQL:

CREATE TABLE `lijst` (
  `lijst_ID` int(11) NOT NULL auto_increment,
  `week` tinyint(3) unsigned NOT NULL default '0',
  `jaar` year(4) NOT NULL default '0000',
  `pos01` int(11) NOT NULL default '0',
  `pos02` int(11) NOT NULL default '0',
  `pos03` int(11) NOT NULL default '0',
  `pos04` int(11) NOT NULL default '0',
    ..........
  `pos20` int(11) NOT NULL default '0',
  PRIMARY KEY  (`lijst_ID`)
) TYPE=MyISAM AUTO_INCREMENT=0 ;

Waar in ieder posxx een integer komt die verwijst naar een tabel met de albums (album_ID).

Maa voor mijn gevoel moet dit veel makkelijker en overzichterlijker kunnen. Wie weet hier meer vanaf en kan mij op wel helpen?

[ Voor 8% gewijzigd door curry684 op 10-08-2003 20:14 . Reden: mooi he die [code] tags :) ]

[supakeen]

Je kan een array omzetten in een tekstfield, is een functie voor in PHP. Je kan hem daarna ook weer terughalen

[ Voor 23% gewijzigd door supakeen op 10-08-2003 20:16 ]

[Erkens]

implode, explode

echter als je zo moet werken is er iets mis met je datamodel

[gorgi_19]

Erkens schreef op 10 August 2003 @ 20:17:
implode, explode

echter als je zo moet werken is er iets mis met je datamodel

Alleen het feit al dat ik pos01 t/m pos20 zie, doet me dat vermoeden...
Oftewel: imho horen de posities in een aparte tabel.

[Dido]

Waarom niet gewoon de velden lijst_ID, week, jaar, positie en album in je tabel opnemen? Dan kun je later desnoods nog eens besluiten posities 21-40 in te gaan vullen als je dara zin hin hebt, zonder dat je datamodel hoeft te veranderen...

edit: of je gooit je posities in een aparte tabel, zoals hierboven gezegd wordt. Is nog netter, dan hoef je week en jaar niet meerdere keren op te slaan.

[ Voor 25% gewijzigd door Dido op 10-08-2003 20:20 ]

[ACM]

Array's in databases worden vaak opgelost met een extra tabel, dat is ook min of meer de bedoeling van die tabellen

Sommige databases hebben ook nog eens een record-type array, maar eigenlijk zou die niet nodig hoeven zijn (hoewel er best aardige voorbeelden te geven zijn waar ze wel handiger/beter zijn).

[Sosabowski]

Ok, dat implode - explode maar het niet makkelijker of netter.
Ik denk dat ik het maar ff ga veranderen in lijst_ID, week, jaar, positie en album. In ieder geval bedankt allemaal!

[supakeen]

IorGie schreef op 10 August 2003 @ 20:27:
Ok, dat implode - explode maar het niet makkelijker of netter.
Ik denk dat ik het maar ff ga veranderen in lijst_ID, week, jaar, positie en album. In ieder geval bedankt allemaal!

Makkelijker, dan moet je even een koppel tabel aanleggen en een tabel met de nummers erin

[SWINX]

IorGie schreef op 10 augustus 2003 @ 20:27:
Ok, dat implode - explode maar het niet makkelijker of netter.
Ik denk dat ik het maar ff ga veranderen in lijst_ID, week, jaar, positie en album. In ieder geval bedankt allemaal!

misschien ook een tabelletje voor je albums, en dan het album_id gebruiken?

[JaQ]

en ik altijd maar denken dat een array ongeveer een "geheugentabel" was?

Overigens is het wel mogelijk in postgresql (daar kan je in 1 kolom een array drukken)

[djluc]

DrFrankenstoner schreef op 11 augustus 2003 @ 12:59:
en ik altijd maar denken dat een array ongeveer een "geheugentabel" was?

Overigens is het wel mogelijk in postgresql (daar kan je in 1 kolom een array drukken)

Dat het kan wil nog niet zeggen dat het ook zo de bedoeling is. Je moet eens gaan zoeken naar normalisatie van gegevens. Er zijn verschillende normaalvormen, de 1e t/m de 6e geloof ik. Als je die netjes doorloopt zul je wel merken hoe je de gegevens op correcte wijze in je db plaatst. In ieders geval is dat geen lijst in één veld proppen, zelfs al kan het.

[bigtree]

zmn schreef op 10 August 2003 @ 20:16:
Je kan een array omzetten in een tekstfield, is een functie voor in PHP. Je kan hem daarna ook weer terughalen

Zei iemand serialize?

[ACM]

Er zijn heus wel redenen om een array toe te passen of zelfs te prefereren boven een losse tabel. Redenen in de richting van performance, storage, e.a.

Zo slaat de full-text-indexing engine FTI/tsearch in postgresql de woorden/woordid's in een soort array's (zijn wel array's maar een beetje een speciale vorm om wat functies los te kunnen laten) op, waarschijnlijk omdat dat vele malen efficienter op te slaan is dan allemaal losse records. Postgresql biedt overigens ook indices aan om _in_ die array-waarden te kunnen zoeken (zelfs met boolean-operators), waardoor dat denk ik wat efficienter is dan tabellen doorzoeken en met losse records per woord-document-koppel te werken.

Andere redenen kunnen bijvoorbeeld zijn wanneer de database enkel de gegevens hoeft op te slaan, zonder daar ooit mee te werken (ala een blob), dan kan het ofwel handig zijn de boel gewoon in een blob op te slaan, ofwel om ze in een arrayveld op te slaan.

Dat het niet altijd klopt met de normaalvormen is jammer, die zijn niet echt altijd even goed voor je performance en/of storage... En soms is dat belangrijker dan aan een of andere normaalvorm te voldoen

[SWINX]

djluc schreef op 11 August 2003 @ 13:02:
[...]

Dat het kan wil nog niet zeggen dat het ook zo de bedoeling is. Je moet eens gaan zoeken naar normalisatie van gegevens. Er zijn verschillende normaalvormen, de 1e t/m de 6e geloof ik. Als je die netjes doorloopt zul je wel merken hoe je de gegevens op correcte wijze in je db plaatst. In ieders geval is dat geen lijst in één veld proppen, zelfs al kan het.

dat normaliseren kregen wij ook op school
begon bij NV-0 en tot NV-3, alles wat over was hoorde bij NV-4 geloof ik
misschien dat er wel meer zijn en dat die niet boeiend voor ons waren ofzo
maar ik vond dat hele normaliseren eigenlijk maar een raar gedoe

Ik zag zelf al wel als je een factuur van een auto-garage moest normaliseren, dat je dan de factuurtabel, autotabel en klatentabel hebt bij wijze van spreken.

Maar verder zou normaliseren idd de perfecte oplossing zijn voor dit soort problemen (array's even buiten beschouwing latend)

[whoami]

SWINX schreef op 11 augustus 2003 @ 15:26:
[...]


dat normaliseren kregen wij ook op school
begon bij NV-0 en tot NV-3, alles wat over was hoorde bij NV-4 geloof ik
misschien dat er wel meer zijn en dat die niet boeiend voor ons waren ofzo
maar ik vond dat hele normaliseren eigenlijk maar een raar gedoe

Een raar gedoe?
Je moet eens met een OLTP (Transaction Processing) databasysteem werken dat niet genormaliseerd is. Dat is een hel: redundante data, moeilijk om de juiste gegevens op te halen, ...

Dat normaliseerproces is er gewoon om een soort 'stappen-plan' te hebben. Hoe meer ervaring je erin hebt, hoe minder je dat 'stappen-plan' nodig hebt.

Je hebt idd ook nog de 4de en 5de normaalvorm. (Boyce-Codd toestanden ofzo, ik zou nog eens moeten kijken wat die 4de en 5de NV nu precies weer inhouden).

[Verwijderd]

<sub>aanvulling op whoami:

heb ff mijn lectuur erbij gehaald en kom niet verder dan 1-3 NF en de BCNF

een relatie is in de Boyce Codd normaalvorm indien:
1. de relatie is in 1NF
2. iedere determinant een kandidaat sleutel is</sub>

[JaQ]

djluc schreef op 11 augustus 2003 @ 13:02:
[...]

Dat het kan wil nog niet zeggen dat het ook zo de bedoeling is. Je moet eens gaan zoeken naar normalisatie van gegevens. Er zijn verschillende normaalvormen, de 1e t/m de 6e geloof ik. Als je die netjes doorloopt zul je wel merken hoe je de gegevens op correcte wijze in je db plaatst. In ieders geval is dat geen lijst in één veld proppen, zelfs al kan het.

nofi, maar weet je ook wat sarcasme is? Denk niet dat je mij veel uit hoeft te leggen over het nut van normaliseren of het algehele nut van een goed en correct database ontwerp in z'n algemeen.

Het punt van ACM is wederom geldig, soms kies je voor minder charmante oplossingen, puur uit performance overwegingen. Een goed voorbeeld voor een array in een kolom kan ik echter niet zo 123 bedenken.

[whoami]

DrFrankenstoner schreef op 11 August 2003 @ 16:05:
[...]

Het punt van ACM is wederom geldig, soms kies je voor minder charmante oplossingen, puur uit performance overwegingen. Een goed voorbeeld voor een array in een kolom kan ik echter niet zo 123 bedenken.

Voor datawarehouses of OLAP systemen kan je je design idd gaan denormaliseren.
Deze systemen worden immers toch slechts gebruikt voor data-retrieval en analyse.
De enige data die er in komt, is nieuwe oude data (), nieuwe historische gegevens dus.
Snelheid van gegevens opvragen is in deze systemen dus belangrijk, en dan kunnen joins enzo nog wel eens vertragend werken.
Echter, in dit geval (van de topicstarter) denk ik niet dat een gedenormaliseerde DB de goeie weg is.

[bigtree]

DrFrankenstoner schreef op 11 augustus 2003 @ 16:05:
[...]
Het punt van ACM is wederom geldig, soms kies je voor minder charmante oplossingen, puur uit performance overwegingen. Een goed voorbeeld voor een array in een kolom kan ik echter niet zo 123 bedenken.

Een voorbeeld voor een array in een kolom is als je heel erg dynamische kolomdefinities hebt. Sessie-data is wat mij betreft een goed voorbeeld. Of objecten met variabele (user-defined) kenmerken. Overigens zou je voor dat laatste weer een prachtig genormaliseerd meta-model kunnen implementeren, maar dat kost soms gewoon te veel tijd.
Uiteraard is normaliseren altijd een *betere* oplossing, maar niet noodzakelijk de *snelste* oplossing qua ontwikkeltijd.

[djluc]

We hebben het hier nog steeds over:

ik ben bezig met een database voor hitlijsten. Dus van elke week een rijtje van 20 cd's.

Het normaliseren hiervan is een fluitje van een cent. Ik zou voor deze situatie dus echt nooit kiezen voor een array in één veld. Dat je dat bij sommige uitzonderlijke gevallen misschien een hoop ontwikkelingstijd kan schelen geloof ik meteen, maar dat lijkt mij hier totaal niet nodig.

Verder is het voordeel als je het normaliseerd dat je de album defenities kunt hergebruiken. Dit is zeker als een album meerdere weken in de lijst staat handig, het scheelt namelijk veel tikken.

Uiteraard is normaliseren altijd een *betere* oplossing, maar niet noodzakelijk de *snelste* oplossing qua ontwikkeltijd.

Als je toch een beetje weet hoe het werkt dan kun je een dergelijk systeem waarschijnlijk binnen dezelfde, misschien iets langere tijd in elkaar zetten. Als je het aantal minuten extra typen of kopiëren-en-plakken daar vanaf gaat trekken zal dit waarschijnlijk zelfs nog sneller gaan.

[dusty]

whoami schreef op 11 August 2003 @ 15:31:
[...]
Je hebt idd ook nog de 4de en 5de normaalvorm. (Boyce-Codd toestanden ofzo, ik zou nog eens moeten kijken wat die 4de en 5de NV nu precies weer inhouden).

Even in simpele woorden: als rode lijn ga je in de 4de en 5de normaal vorm weer "dubbele" waarden introduceren.

Bijvoorbeeld bij een forum kan je het aantal reacties dat bij een bericht hoort elke keer gaan tellen hoeveel reacties er zijn, echter kan je dat ook weer opslaan in de tabel over dat topic. In principe is het een waarde die dubbel in de database komt te staan omdat je het ook anders eruit kan krijgen, maar vanwege de efficientie en snelheid is het slimmer om het getal dus wel erbij op te slaan.

^{Uiteraard komt er nog meer bij kijken, en ik kan jou alleen maar aanbevelen om er inderdaad een keer iets over te lezen!}

[SWINX]

dusty schreef op 11 August 2003 @ 23:50:
[...]

... vanwege de efficientie en snelheid is het slimmer om het getal dus wel erbij op te slaan.

hmm.. slim, maar wij leerden dus bij "rekenvelden" geen data op te slaan in de db, maar qua snelheid/pagina opbouw zal het wel schelen om dit wel te doen

[ Voor 5% gewijzigd door SWINX op 12-08-2003 00:54 ]

[ripexx]

SWINX schreef op 12 August 2003 @ 00:07:
[...]
hmm.. slim, maar wij leerden dus bij "rekenvelden" geen data op te slaan in de db, maar qua snelheid/pagina opbouw zal het wel schelen

Denk maar niet dat bij idere index opbouw van react alle post per forum worden geteld. Wat denk je dat dit voor een load kost. In dit geval is het gemakkelijker om gewoon een extra update query te doen bij een move, delete of start. Gewoon een kwestie van afwegen. Maar het is wel goed dat jullie geleerd wordt om rekenveld niet op te slaan. De basis van een goede db setup volgens de normaalvormen veriest dat eigenlijk. Alleen in de praktijk weeg je voor- en nadelen tegen elkaar af.