[PHP/MySQL]Array in database??

[Postman]

Is het mogelijk om een array vanuit PHP in MySQL te proppen?? Ik zit namelijk met het probleem dat ik gebruikers heb die van een aantal dingen gebruik kunnen maken. Nou zou ik dus per gebruikt object de id samen met een seperator in een tekstveld kunnen stoppen, maar mooier en vooral makkelijker is het als ik een array kan gebruiken.

Het maken van het script kan ik zelf wel, ik vraag me alleen af of het kan en eventueel hoe je dan zoiets moet doen (zult wel een apart type veld moeten gebruiken ofzo).

Oh ja, ik kan niks testen dus post ik zonder code. Mijn domein bij ASHosting ligt eruit en dus wordt het lastig om iets te proberen

[gorgi_19]

Waarom zou je dit zo willen oplossen en maak je hier niet een aparte tabel voor aan?

Om een array in een database te stoppen: scheidt de gegevens door middel van bijvoorbeeld ; en split ze weer op ; bij het uithalen.

[ Voor 45% gewijzigd door gorgi_19 op 08-01-2003 20:31 ]

[Postman]

Aparte tabel zou kunnen, maar ik blijf zelf met het probleem zitten hoe ik het oplos als gebruiker A, 1 object heeft, B heeft er 4 en C heeft er 56.

Tja, scheiden was mij ook al opgevallen, maar een echte array is makkelijker (of object, als je maar een hoop data zo aankan zonder eerst te moeten scheiden).

[gorgi_19]

Een voorbeeld van een tabel:

KoppelTabelID autonumber
UserID int
objectID int

[Verwijderd]

echte array kan niet... gebruik explode() om de data erin te mikken, en vervolgens implode() weer om de data uit de dbase te halen

[Postman]

gorgi_19 schreef op 08 januari 2003 @ 20:41:
Een voorbeeld van een tabel:

KoppelTabelID autonumber
UserID int
objectID int

Thnx

Zit momenteel in een deadlock en kan dus niet erg goed meer denken. Zoiets is zeker een oplossing.

Maar (weet het, val in herhaling): kun je een PHP array in MySQL krijgen??
_{Tja, nou wil ik het ook weten ook.}

[sebas]

FlamerX schreef op 08 January 2003 @ 20:47:
[...]
Maar (weet het, val in herhaling): kun je een PHP array in MySQL krijgen??
_{Tja, nou wil ik het ook weten ook.}

gorgi_19 schreef op 08 januari 2003 @ 20:31:
[...]
Om een array in een database te stoppen: scheidt de gegevens door middel van bijvoorbeeld ; en split ze weer op ; bij het uithalen.

[Postman]

Dat zag ik ook wel hoor sebas. En als je echt goed gelezen had, zag je ook deze regel in mijn eerste post staan:

Nou zou ik dus per gebruikt object de id samen met een seperator in een tekstveld kunnen stoppen

En zo heb ik nog geen array object in mijn database, alleen tekst.

Ik neem dus aan dat het niet mogelijk is om een echte array in mysql te stoppen. Jammer, maar ik heb iig een oplossing voor mijn probleem

[ Voor 90% gewijzigd door Postman op 08-01-2003 21:24 . Reden: Vaute knop :P ]

[Verwijderd]

gorgi_19 schreef op 08 januari 2003 @ 20:31:
Waarom zou je dit zo willen oplossen en maak je hier niet een aparte tabel voor aan?

Om een array in een database te stoppen: scheidt de gegevens door middel van bijvoorbeeld ; en split ze weer op ; bij het uithalen.

Ik wil je niet tegen de schenen schoppen, maar ik zou dus echt nooit iemand aanraden dit zo te doen. Elk veld in een database moet enkelwaardig zijn, anders voldoet je database niet eens aan de eerste normaalvorm.

Meestal resulteert zo'n situatie in het gebruik van een koppeltabel, wat een prima oplossing is.

[Postman]

Verwijderd schreef op 08 januari 2003 @ 21:24:

[...]

Ik wil je niet tegen de schenen schoppen, maar ik zou dus echt nooit iemand aanraden dit zo te doen. Elk veld in een database moet enkelwaardig zijn, anders voldoet je database niet eens aan de eerste normaalvorm.

Idd, en daarom wou ik dus ook een array in een database kunnen rammen. Is ook enkelvoudig in principe.
Maar de koppeltabel zal ik gaan gebruiken. Stom dat ik daar niet op ben gekomen

[gorgi_19]

Verwijderd schreef op 08 januari 2003 @ 21:24:

[...]

Ik wil je niet tegen de schenen schoppen, maar ik zou dus echt nooit iemand aanraden dit zo te doen. Elk veld in een database moet enkelwaardig zijn, anders voldoet je database niet eens aan de eerste normaalvorm.

Meestal resulteert zo'n situatie in het gebruik van een koppeltabel, wat een prima oplossing is.

ik ben het volledig met je eens.. Dit is gewoon ook zwaar misbruik van een database. Een bericht later heb ik ook een koppeltabel geplaatst als voorbeeld..

Alleen als iemand echt een array in een database wil plaatsen, dan was dat de methode (hoewel dat niet aan te raden is)

[Verwijderd]

FlamerX schreef op 08 January 2003 @ 21:27:
[...]

Idd, en daarom wou ik dus ook een array in een database kunnen rammen. Is ook enkelvoudig in principe.
Maar de koppeltabel zal ik gaan gebruiken. Stom dat ik daar niet op ben gekomen

Dat je dat uberhaupt wilt is wat mij betreft verkeerd. Een database is niet zomaar een opslagplaats, het is een goed georganiseerde opslagplaats.

[_-= Erikje =-_]

serialize is wat je wilt btw, maar idd het moet NIET nodig zijn..

[Shagura]

Je kunt in principe wel gebruik maken van enum als je toch enigszins gebruik wil maken van een rijprincipe

[Verwijderd]

Shagura schreef op 08 januari 2003 @ 21:38:
Je kunt in principe wel gebruik maken van enum als je toch enigszins gebruik wil maken van een rijprincipe

Zoals al gezegd: multi valued atributen mogen niet in een relationele database opgenomen worden.
Daarom is ENUM bijna nooit een goede oplossing.

Afgezien van dat, bij ENUM moet je opgeven welke waarden die verzameling die opgeslagen zal worden mag hebben.
Daarom is het dus (ook) geen goede oplossing, omdat die array hoogstwaarschijnlijk allerlei waarden kan hebben.

[Verwijderd]

Shagura schreef op 08 January 2003 @ 21:38:
Je kunt in principe wel gebruik maken van enum als je toch enigszins gebruik wil maken van een rijprincipe

Enum is voor iets heel anders bedoelt. Bijvoorbeeld wanneer je de invoer wilt beperken tot 'ja' of 'nee'. Niet om rijen gegevens in op te slaan..

[Verwijderd]

Verwijderd schreef op 08 januari 2003 @ 20:44:
echte array kan niet... gebruik explode() om de data erin te mikken, en vervolgens implode() weer om de data uit de dbase te halen

Andersom.

[ACM]

Btw, in tegenstelling tot een aantal grotere databases kent mysql geen echt array-type.

Postgresql, oracle e.v.a. kennen dat wel, van postgres weet ik zelfs zeker dat je de array kan indexeren en doorzoeken. Het is natuurlijk zelden nodig, maar altijd beter dan bovenstaande serialize/implode oplossingen.

Verder is het natuurlijk over het algemeen raadzaam de boel dmv koppeltabellen op te slaan, alhoewel deze ook wel degelijk nadelen hebben, zoals veel meer opslagruimte (voor elk array-element een record, ipv alleen een stukje geheugen in een kolom), minder inzichtelijk als de data niet bedoeld is voor joins en/of verdere database-operaties maar alleen voor opslag van client-data en er zijn nog wel meer te bedenken

[Verwijderd]

Verwijderd schreef op 08 January 2003 @ 22:48:
Zoals al gezegd: multi valued atributen mogen niet in een relationele database opgenomen worden.
Daarom is ENUM bijna nooit een goede oplossing.

Afgezien van dat, bij ENUM moet je opgeven welke waarden die verzameling die opgeslagen zal worden mag hebben.
Daarom is het dus (ook) geen goede oplossing, omdat die array hoogstwaarschijnlijk allerlei waarden kan hebben.

Verwijderd schreef op 08 January 2003 @ 23:56:
Enum is voor iets heel anders bedoelt. Bijvoorbeeld wanneer je de invoer wilt beperken tot 'ja' of 'nee'. Niet om rijen gegevens in op te slaan..

Uhm je hebt gelijk ik bedoelde SET

[ Voor 17% gewijzigd door Verwijderd op 09-01-2003 14:26 ]

[djluc]

Er wordt constant egkeken naar de normaalvorm en andere dingen maar qua performance in mysql denk ik toch dat je met meerdere gegevens in een veld in de database optimaler bezig bent dan met een koppeltabel, en dan wel om het feit dat we geen sub-query's kunnen toepassen.

[Verwijderd]

djluc schreef op 09 January 2003 @ 16:54:
Er wordt constant egkeken naar de normaalvorm en andere dingen maar qua performance in mysql denk ik toch dat je met meerdere gegevens in een veld in de database optimaler bezig bent dan met een koppeltabel, en dan wel om het feit dat we geen sub-query's kunnen toepassen.

Stel je hebt een array met 100.000 variabelen...
Dan mag je PHP scriptje dat eerst even helemal ontvangen van de MySQL server, het ding gaan ontleden, iets toevoegen of verwijderen, en dan weer terugsturen?

Nee sorry, ik denk dat die database engines toch aardig zijn geoptimaliseerd.

[Tom-Eric]

Ok, ik kick een al wat ouder topic omhoog (niet zo oud), maar ik kan wel een mooi doeleind bedenken om een array in mysql te zetten. Zo ben ik bezig met een stackbases forumcode parser en hij is al redelijk snel, maar als ik de tree generatie skip spaar ik toch echt 50/60%. Aangezien de tree makkelijk te reversen is is het dus fantastisch als ik deze in een database kwijt kan bij het posten van een nieuw bericht of het wijzigen van een oud bericht.

Misschien denk ik verkeerd, maar ik denk dat dmv. deze methode je een redelijk snelle parser kan ontwikkelen.

[Kees]

(un)serialize()
http://nl2.php.net/manual/en/function.serialize.php
http://nl2.php.net/manual/en/function.unserialize.php

[Verwijderd]

Tum|mut schreef op 17 januari 2003 @ 21:36:
Ok, ik kick een al wat ouder topic omhoog (niet zo oud), maar ik kan wel een mooi doeleind bedenken om een array in mysql te zetten. Zo ben ik bezig met een stackbases forumcode parser en hij is al redelijk snel, maar als ik de tree generatie skip spaar ik toch echt 50/60%. Aangezien de tree makkelijk te reversen is is het dus fantastisch als ik deze in een database kwijt kan bij het posten van een nieuw bericht of het wijzigen van een oud bericht.

Misschien denk ik verkeerd, maar ik denk dat dmv. deze methode je een redelijk snelle parser kan ontwikkelen.

Leg me nu eens uit waarom die gegevens in één veld moeten?

[Tom-Eric]

Verwijderd schreef op 17 January 2003 @ 21:45:

[...]

Leg me nu eens uit waarom die gegevens in één veld moeten?

De enige gegevens die in dat veld gaan is de array van een post nadat ik daar door heen ben gegaan. Ik zal even een voorbeeldje zoeken en weer hier posten.

edit:
Hier is die dan

code:

Array
(
    [content] => Array
        (
            [0] => 

            [1] => nohtml
            [2] =>  
            [3] => quote
            [4] =>  
            [5] => b
            [6] =>  
            [7] => message=16797901,noline
            [8] => Tum|mut schreef op 17 januari 2003 @ 21:36
            [9] => /message
            [10] => :
            [11] => /b
            [12] => Een heleboel tekst
            [13] => /quote
            [14] =>  
            [15] => /nohtml
            [16] => 
Leg me nu eens uit waarom die gegevens in één veld moeten?


        )

    [type] => Array
        (
            [0] => 2
            [1] => 0
            [2] => 2
            [3] => 0
            [4] => 2
            [5] => 0
            [6] => 2
            [7] => 0
            [8] => 2
            [9] => 1
            [10] => 2
            [11] => 1
            [12] => 2
            [13] => 1
            [14] => 2
            [15] => 1
            [16] => 2
        )

)

Bovenstaande is wat ik in het veld wil stoppen die de post heeft.

PHP:

define("START_TAG", 0);
define("END_TAG", 1);
define("CONTENT", 2);

[ Voor 94% gewijzigd door Tom-Eric op 18-01-2003 00:21 ]

[Verwijderd]

Ik zie nog steeds niet waarom dit in één veld zou moeten, sorry.

[Tom-Eric]

Verwijderd schreef op 18 January 2003 @ 10:49:
Ik zie nog steeds niet waarom dit in één veld zou moeten, sorry.

Hoe zou je dit dan over meerdere velden willen verspreiden?

[--MeAngry--]

Probeer het eens door met een for-lus alles in aparte rijen te zetten...

PHP:

<?php
$array[1] = 'Eerste waarde';
$array[2] = 'Tweede waarde';
$array[3] = 'Derde waarde';
$totaal = 3;
for ($nummer = 1 ; $nummer <= $totaal ; $nummer++ ) {
 $commando = "INSERT INTO `tabelnaam` ( `id` , `waarde` ) VALUES ( '$nummer', '$array[$nummer]' )";
 $invoeren = @mysql_query($commando);
}
?>

[Tom-Eric]

--MeAngry-- schreef op 18 January 2003 @ 11:20:
Probeer het eens door met een for-lus alles in aparte rijen te zetten...

PHP:

<?php
$array[1] = 'Eerste waarde';
$array[2] = 'Tweede waarde';
$array[3] = 'Derde waarde';
$totaal = 3;
for ($nummer = 1 ; $nummer <= $totaal ; $nummer++ ) {
 $commando = "INSERT INTO `tabelnaam` ( `id` , `waarde` ) VALUES ( '$nummer', '$array[$nummer]' )";
 $invoeren = @mysql_query($commando);
}
?>

Dat lijkt me niet echt een snelle oplossing voor bijvoorbeeld een forum.

[Apache]

Tum|mut: als je nu in de content gewoon html plaatste (pre-parsed) en enkel bij een edit terugparsed naar de originele code bvb

zoiezo kan je een veld bericht hebben met alle tags etc in en een nl2br gedaan hebben dan kan je nog terug je originele regels bekomen door die nl2br om te draaien of de \n'en er te laten instaan (\n door <br />\n)

[drm]

Tum|mut:
Dat lijkt me niet echt een snelle oplossing voor bijvoorbeeld een forum.

Mits je de code een beetje optimaliseert, is het zo gek nog niet, imho ...

PHP:

<?php
// waarom op 1 beginnen :? </irrelevant>
$array[1] = 'Eerste waarde';
$array[2] = 'Tweede waarde';
$array[3] = 'Derde waarde';

// waarom geen foreach :?
#snip    $totaal = 3;
#snip    for ($nummer = 1 ; $nummer <= $totaal ; $nummer++ ) {

// niet elke keer een query doen, maar 1 query samenstellen voor de values.
$value_clauses = array ();
foreach ( $array as $key => $value ) {
    $value_clauses []= "('$key','$value')";
}

// en natuurlijk nooit het @ -sign gebruiken, zeker niet als je 
// nog in de ontwikkelfase zit ;)
mysql_query ( $tmp = "
   INSERT INTO
       `koppel_table`(`id`,`waarde`)
   VALUES
       " . implode ( ",\n      ", $value_clauses ) . " 
" ) or
   user_error ( mysql_error () . "\n\n" . $tmp );

?> 

heb hier ff geen rekening gehouden met quotes in je keys of values maar goed, 't gaat om 't idee.

Zo'n samengestelde INSERT query is ideaal voor koppelgegevens

[Tom-Eric]

Het lijkt mij dat je bij het inserten van gegevens weinig problemen zal hebben, het gaat mij vooral om het opvragen van gegevens. Het lijkt me niet echt ideaal als je voor een post van 10 berichten 100 database entries moet ophalen en verwerken. Het is natuurlijk wel te doen, maar of dit de snelheid bevordert?

Wat Apache zegt kan natuurlijk ook, maar stel dat ik tags wil gaan maken die een boodschap meerdere keren loopt, dan is het terugparsen natuurlijk niet te doen (dit is misschien onwaarschijnlijk, maar toch zit ik met het idee te spelen om een soort van scripten te ontwikkelen).

Ik heb ook al gedacht aan 2 velden, eentje unparsed en eentje parsed, maar dit neemt gewoon 2x zoveel ruimte in en bij een forum met genoeg posts is dat wederom niet ideaal.

Daarbij neemt het parsen vanaf de array ongeveer 0.06 seconden in voor 100 berichten, dus dat zal je niet zo snel terugzien.

[drm]

't wordt hier op GoT volgens mij ook gedaan, hoor, originele en geparste tekst bijhouden.

chem: harddisk space is er om gebruikt te worden.

qua performance zal je er iig een stukkie op vooruit gaan.

[Tom-Eric]

Ik weet dat het hier op GoT ook gedaan wordt, want ik heb voordat ik ben begonnen met schrijven gewoon een heleboel feature lijsten bekijken en parse heeft gewoon een mooi stukje werk geleverd, maar ik denk bijvoorbeeld dat het maken van een kleine scripting language in de forumsoftware dan onmogelijk zal worden.

Als je kijkt naar bijvoorbeeld de feature om tables te maken, dat wordt in het gamecube topic bijvoorbeeld ontzettend veel gebruikt. Het is imho een nutteloze feature, maar het maakt de posts ook mooier. Als ik bijvoorbeeld wil dat de gebruikers een countdown in elkaar kunnen sleutelen met scripten, dan zou preparsed dus niet gaan.

[Verwijderd]

Tum|mut schreef op 18 January 2003 @ 15:59:
Ik weet dat het hier op GoT ook gedaan wordt, want ik heb voordat ik ben begonnen met schrijven gewoon een heleboel feature lijsten bekijken en parse heeft gewoon een mooi stukje werk geleverd, maar ik denk bijvoorbeeld dat het maken van een kleine scripting language in de forumsoftware dan onmogelijk zal worden.

Als je kijkt naar bijvoorbeeld de feature om tables te maken, dat wordt in het gamecube topic bijvoorbeeld ontzettend veel gebruikt. Het is imho een nutteloze feature, maar het maakt de posts ook mooier. Als ik bijvoorbeeld wil dat de gebruikers een countdown in elkaar kunnen sleutelen met scripten, dan zou preparsed dus niet gaan.

Als alle users hetzelfde te zien krijgen, kun je al het werk al van tevoren doen, wat heb jij dan in gedachten dat onmogelijk is als je gebruik maakt van het idee om posts geparset en ongeparset op te slaan?

[Verwijderd]

Op welke manier wil je dan een index aanleggen op die array (list)voor oa zoekopdrachten Juistem... isniegoenie.

[Verwijderd]

Is het niet veel handiger om die array gewoon weg te schrijven naar een txt of php bestandje? Ik heb de topic niet heel erg goed doorgenomen, dus wellicht slaat dit nergens op...

[ACM]

Ik denk trouwens dat het minder tijd kost om dan domweg de boel in zijn geheel opnieuw te parsen, dan alvast een simpele stap in de database opgeslagen te laten (zeker als je het ofwel serialized, ofwel in losse records hebt staan). (en dan dus de ongeparste tekst op te slaan)

Verwijderd schreef op 18 January 2003 @ 16:14:
Op welke manier wil je dan een index aanleggen op die array (list)voor oa zoekopdrachten Juistem... isniegoenie.

Het zal voorn een zoektocht naar message id's zijn en dat zal er niet moeilijker op worden

[ Voor 47% gewijzigd door ACM op 18-01-2003 16:17 ]

[Tom-Eric]

Zoeken zou iets zijn waar ik nog eens naar moet kijken, maar mij lijkt het het makkelijkste om per post alle woorden die al in het topic zijn gezegd weg te filteren en in een aparte woorden lijst te zetten, daarbij heb ik gekeken naar serialize, en deze output:

code:

a:2:{s:7:"content";a:21:{i:0;s:65:"
Ik denk trouwens dat het minder tijd kost om dan domweg de boel ";i:1;s:1:"i";i:2;s:14:"in zijn geheel";i:3;s:2:"/i";i:4;s:203:" opnieuw te parsen, dan alvast een simpele stap in de database opgeslagen te laten (zeker als je het ofwel serialized, ofwel in losse records hebt staan). (en dan dus de ongeparste tekst op te slaan)

";i:5;s:6:"nohtml";i:6;s:1:" ";i:7;s:5:"quote";i:8;s:1:" ";i:9;s:1:"b";i:10;s:1:" ";i:11;s:23:"message=16803627,noline";i:12;s:46:"Gordijnstok schreef op 18 January 2003 @ 16:14";i:13;s:8:"/message";i:14;s:1:":";i:15;s:2:"/b";i:16;s:117:"
Op welke manier wil je dan een index aanleggen op die array (list)voor oa zoekopdrachten ;) Juistem... isniegoenie.";i:17;s:6:"/quote";i:18;s:1:" ";i:19;s:7:"/nohtml";i:20;s:96:"
Het zal voorn een zoektocht naar message id's zijn en dat zal er niet moeilijker op worden :P
";}s:4:"type";a:21:{i:0;i:2;i:1;i:0;i:2;i:2;i:3;i:1;i:4;i:2;i:5;i:0;i:6;i:2;i:7;i:0;i:8;i:2;i:9;i:0;i:10;i:2;i:11;i:0;i:12;i:2;i:13;i:1;i:14;i:2;i:15;i:1;i:16;i:2;i:17;i:1;i:18;i:2;i:19;i:1;i:20;i:2;}}

is nog steeds te doorzoeken op inhoud hoor, terwijl na het unserializen gewoon weer netjes de array krijg.

Als alle users hetzelfde te zien krijgen, kun je al het werk al van tevoren doen, wat heb jij dan in gedachten dat onmogelijk is als je gebruik maakt van het idee om posts geparset en ongeparset op te slaan?

Stel ik geef de gebruikers toegan tot de tag [!time] waarmee de huidige datum wordt geprint, of een manier om twee datums met elkaar te vergelijken (de huidige tijd en de vastgezette tijd), volgens mij kan je dan niet gebruik maken van reeds geparste inhoud . Het preparsen (dus de array maken en dingen als email adressen / urls's veranderen naar de goede tags hoeft dan niet voor elke post gedaan te worden, dus dat scheelt dan wel weer tijd.

[ Voor 27% gewijzigd door Tom-Eric op 18-01-2003 16:50 ]