[MySQL/PHP] Hoe kan dit mooier? Genres in DB inserten

[monnick]

Ik heb een tabel met allerlei filmgenres (id en genres). Een gebruiker kan een nieuwe film toevoegen en daarbij genres opgeven. Ik heb ook een tabel met filminformatie, deze wil ik met behulp van Joins aan de genre tabel koppelen (nog geen idee hoe, nog nooit eerder met joins gewerkt).

Nu moeten bestaande genres niet nog een keer in de tabel genres ingevoerd worden, van bestaande genres heb ik alleen het genre ID nodig om deze in de tabel met filminformatie te stoppen. Genres die niet bestaan moeten in de database worden ingevoerd en vervolgens heb ik het genre ID van het zojuist gemaakte genre nodig om deze vervolgens weer in de tabel met filminformatie in te voeren.

Op zich niet zo moeilijk te realiseren, ik heb alleen het idee dat de onderstaande methode die ik geklust heb een stuk mooier / eenvoudiger kan. Ik weet alleen niet hoe Misschien met wat geavanceerde SQL queries? Mijn SQL is niet zo goed, dus ik zou het niet weten.

Hier de PHP code die ik gebruik:

PHP:

$dbGenres =     array();
$dbGenres[] =   htmlspecialchars(addslashes($_POST['genre1']));
$dbGenres[] =   htmlspecialchars(addslashes($_POST['genre2']));
$dbGenres[] =   htmlspecialchars(addslashes($_POST['genre3']));
    
$genreIDs =     array();
    
foreach ($dbGenres as $genre) {
    if ($genre !== "") {
        $selectGenreQuery = "SELECT `id` FROM `genres` WHERE `name` = '{$genre}'";
        $execQuery = mysql_query($selectGenreQuery) or die("MySQL error: could not select genre");
        $countResult = mysql_num_rows($execQuery);
            
        // Genre does not exist, insert it into the database and retrieve ID.
        if ($countResult == 0) {
            // Inserting genre 1 in database
            $insertGenreQuery = "INSERT INTO `genres` (`name`) VALUES ('{$genre}')";
            mysql_query($insertGenreQuery) or die("MySQL error: failed to insert genre1");
                    
            // Retrieving id of just created genre
            $getIDQuery = "SELECT `id` FROM `genres` WHERE `name` = '{$genre}'";
            $execQuery = mysql_query($getIDQuery) or die("MySQL error: could not select ID of new genre");
            $genreIDs[] = mysql_result($execQuery, 0);
        } else {
            // Genre already exists.
            $genreIDs[] = mysql_result($execQuery, 0);
        }
    }
}

[dragontje124]

je kan het laatst geinserte ID ophalen met mysql_insert_id(); die ken ik ook pas sinds een weekje
edit:
daarnaast is het ook handig om een koppeltabel te gebruiken, dus:
een tabel films
een tabel genres
en een koppeltabel waarin een film id en genreid staan

zo kan je dus meerdere genres aan 1 film koppelen

zo zou je alle genres bij een film op kunnen vragen (even uit de losse pols)

SQL:

SELECT genres.naam AS naam FROM genres,films,koppeltabel WHERE films.id=koppeltabel.filmid AND genres.id=koppeltabel.genreid AND films.id=HIERHETIDVANDEFILM

volgens mij moet zoiets werken, weet het niet zeker wat betreft die query

[ Voor 109% gewijzigd door dragontje124 op 03-08-2010 21:17 ]

[Voutloos]

^^ en om strings écht voor mysql te escapen is er mysql_real_escape_string().

Op zich kan je huidige aanpak wel, alhoewel ik denk ik het managen van genres in aparte acties zou doen. Dus bij films editen enkel bestaande genres kunnen kiezen, en dan het aanmaken van genres heel bewust los doen. Als het goed is heb je bij de meeste films geen nieuw genre, en bovendien heb je dan een drempeltje tegen onzin/dubbele genres.

[monnick]

Aha, bedankt! De functie mysql_insert_id() maakt het alweer een paar regels korter. Ik heb net nog zitten zoeken of alleen mysql_real_escape_string() voldoende is, maar kwam wel tot de ontdekking dat het alsnog verstand is om addslashes() toe te passen, of is dat bollocks?

[dragontje124]

monnick schreef op dinsdag 03 augustus 2010 @ 21:17:
Aha, bedankt! De functie mysql_insert_id() maakt het alweer een paar regels korter. Ik heb net nog zitten zoeken of alleen mysql_real_escape_string() voldoende is, maar kwam wel tot de ontdekking dat het alsnog verstand is om addslashes() toe te passen, of is dat bollocks?

je moet bij het inserten van genres ook htmlentities() gebruiken om te voorkomen dat iemand er html code in dumpt die anderen dan weer kunnen zien

kijk ook even naar mijn koppeltabel oplossing, heb een beetje veel lopen editen
edit:
htmlentities is beter dan htmlspecialchars

[ Voor 4% gewijzigd door dragontje124 op 03-08-2010 21:20 ]

[Woy]

dragontje124 schreef op dinsdag 03 augustus 2010 @ 21:19:
[...]

je moet bij het inserten van genres ook htmlentities() gebruiken om te voorkomen dat iemand er html code in dumpt die anderen dan weer kunnen zien

kijk ook even naar mijn koppeltabel oplossing, heb een beetje veel lopen editen
edit:
htmlentities is beter dan htmlspecialchars

Je moet bij het inserten helemaal niet de htmlentities/htmlspecialchars doen, dat moet je bij het presenteren doen. Anders kan je straks weer terug gaan converteren als je naar wat anders dan HTML wil outputten

[dragontje124]

Woy schreef op dinsdag 03 augustus 2010 @ 21:23:
[...]

Je moet bij het inserten helemaal niet de htmlentities/htmlspecialchars doen, dat moet je bij het presenteren doen. Anders kan je straks weer terug gaan converteren als je naar wat anders dan HTML wil outputten

yup je hebt gelijk, had ik even niet bij nagedacht

[Cartman!]

Ik zou sowieso met arrays werken in je formulier. Nu gebruik je genre1, genre2 en genre3 maar als je daar genre[] van maakt krijg je gewoon een array binnen, veel handiger natuurlijk en beter uit te breiden

En om te checken of een variabele leeg is heb je empty(). Succes!

[Niemand_Anders]

Waarom gebruik je niet gewoon de replace statement van MySQL? Die bepaald voor jouw of een insert of update nodig is..

http://dev.mysql.com/doc/refman/5.0/en/replace.html

[monnick]

Wat ik uit die pagina over REPLACE begrijp is dat dan eerst het oude genre verwijderd wordt en het nieuwe genre (welke dus hetzelfde is) wordt ingevoerd. De ID (=primary key) van het genre verandert dus. Elke film entry in de database die datzelfde genre heeft kan dus niet meer gelinkt worden aan het genre aangezien het genre met dat ID niet meer bestaat.

Of zie ik iets over het hoofd?

Verder, ik heb ooit eens van iemand geleerd om if ($blaat == "") te gebruiken in plaats van if (empty($blaat)). Maakt in principe niet zo veel uit toch?

[Cartman!]

Zou ik nogal zonde vinden, replace verwijdert eerst een record om hem vervolgens weer te inserten. Als je string niet de primary key is dan kloppen je verwijzingen niet meer.

Verder, ik heb ooit eens van iemand geleerd om if ($blaat == "") te gebruiken in plaats van if (empty($blaat)). Maakt in principe niet zo veel uit toch?

Hangt er vanaf wat je wilt toestaan Het kan potentieel heel veel uitmaken ieder geval.

[ Voor 43% gewijzigd door Cartman! op 03-08-2010 22:49 ]

[dragontje124]

Verder, ik heb ooit eens van iemand geleerd om if ($blaat == "") te gebruiken in plaats van if (empty($blaat)). Maakt in principe niet zo veel uit toch?

The following things are considered to be empty:

"" (an empty string)
0 (0 as an integer)
"0" (0 as a string)
NULL
FALSE
array() (an empty array)
var $var; (a variable declared, but without a value in a class)

http://nl2.php.net/empty
hangt er dus inderdaad vanaf wat jij wil, maar in dit geval lijkt mij empty een prima keuze

REPLACE zou ik ook niet gebruiken.

[X_lawl_X]

monnick schreef op dinsdag 03 augustus 2010 @ 21:17:
Aha, bedankt! De functie mysql_insert_id() maakt het alweer een paar regels korter. Ik heb net nog zitten zoeken of alleen mysql_real_escape_string() voldoende is, maar kwam wel tot de ontdekking dat het alsnog verstand is om addslashes() toe te passen, of is dat bollocks?

mysql_real_escape_string() is genoeg, gewoon altijd van addslashes afblijven.

En als je het nog overzichtelijker wilt maken kun je is naar PDO kijken, indien dat tot je beschikking hebt.

[ Voor 10% gewijzigd door X_lawl_X op 03-08-2010 23:59 ]

[monnick]

X_lawl_X schreef op dinsdag 03 augustus 2010 @ 23:53:
[...]


mysql_real_escape_string() is genoeg, gewoon altijd van addslashes afblijven.

En als je het nog overzichtelijker wilt maken kun je is naar PDO kijken, indien dat tot je beschikking hebt.

Om hier nog even op terug te komen, dit klopt volgens mij niet. Als je mysql_real_escape_string() wilt gebruiken kan je beter eerst nog addslashes() toepassen.

Ik had een tekst waarin voorkwam "Stanley Kubrick's", dus een accent er in. Wanneer ik dit door mysql_real_escape_string() haalde kwam dit in de database terecht als Stanley Kubrick’s. Na het uit de database halen nog even door htmlentities() gehaald, maar dat maak niks uit natuurlijk. De html output was dus lelijk

Als je eerst addslashes() gebruikt wordt daarna de ' niet vern**kt door mysql_real_escape_string()

[RobIII]

monnick schreef op woensdag 04 augustus 2010 @ 19:08:
Ik had een tekst waarin voorkwam "Stanley Kubrick's", dus een accent er in. Wanneer ik dit door mysql_real_escape_string() haalde kwam dit in de database terecht als Stanley Kubrick’s. Na het uit de database halen nog even door htmlentities() gehaald, maar dat maak niks uit natuurlijk. De html output was dus lelijk

Ik zie een klok en een klepel en die hangen mijlenver uit elkaar
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[monnick]

Oke je had helemaal gelijk!

Die addslashes() heeft helemaal niks met de encoding te maken natuurlijk. Andere fancy characters gaan alsnog even hard op hun bek.

Erg ophelderend artikel, net helemaal doorgelezen. Dat had ik veel eerder moeten doen want ik wist amper wat UTF-8 was

Ik heb nu met mysql_client_encoding() achterhaalt dat de gebruikte encoding "latin1" is. Waar mijn website als UTF-8 staat ingesteld. Probleem dus...Alleen na verder zoeken weet ik nog niet hoe ik dit probleem oplos. Kun je me nog wat verder in de goede richting helpen?

In ieder geval al heel erg bedankt voor het artikel (Leuke schrijfstijl trouwens)

[Zeebonk]

Je snapt nu dus dat er dus moet worden geconverteerd. Zoeken naar "php convert text encoding" op google had je als eerste hit: http://php.net/manual/en/function.mb-convert-encoding.php gegeven.

Daarmee kan je de encoding van een string omzetten naar de encoding die jouw database lust.

[Woy]

Zeebonk schreef op woensdag 04 augustus 2010 @ 22:25:
Je snapt nu dus dat er dus moet worden geconverteerd. Zoeken naar "php convert text encoding" op google had je als eerste hit: http://php.net/manual/en/function.mb-convert-encoding.php gegeven.

Daarmee kan je de encoding van een string omzetten naar de encoding die jouw database lust.

Of, nog makkelijker, je stelt de database ook in op UTF-8. Latin-1 is een encoding die een veel kleinere set aan characters aan kan. Je moet met UTF-8 alleen oppasen i.c.m. PHP aangezien de standaard string functions geen raad weten met UTF-8

[RobIII]

Woy schreef op woensdag 04 augustus 2010 @ 22:36:
aangezien de standaard string functions geen raad weten met UTF-8

Volgens mij wel, toch? (PHP-lutser-alert hoor ) Alleen zal een strlen bijvoorbeeld een incorrect aantal karakters geven op een mb-string en dat soort ongein, maar wat ik meende begrepen te hebben was dat 't verder wel goed ging

Laat maar, bij de eerste-de-beste functie die ik opzoek zie ik al dat er ook een mb_ versie van is. Dat betekent dus mb_ versies gebruiken wanneer beschikbaar; als ik zo vrij mag zijn die conclusie even vlug te trekken

[ Voor 26% gewijzigd door RobIII op 04-08-2010 22:57 ]

[monnick]

Oke....nogmaals bedankt voor jullie reacties. Misschien ben ik gewoon niet zo slim bezig, maar het wil me nog steeds niet lukken om de tekst op een juiste manier in de database op te slaan en vervolgens weer te geven.

Het gaat nog steeds om diacritische tekens en vreemde accenten enzo. Bijvoorbeeld de accent in de onderstaande zin.

A Clockwork Orange is one of Stanley Kubrick’s greatest works about a gang of dangerous teenagers in future Britain.

Wat ik dacht: de database staat standaard op Latin8 ingesteld. Alleen UTF-8 ondersteunt velen malen meer tekens, dus ik zet met de php functie mysql_set_charset() aan het begin de page de MySQL connectie op UTF-8:

PHP:

mysql_set_charset("utf8", $link);

Als ik met dan met mysql_client_encoding() de encoding van de SQL connectie check dan wordt er inderdaad UTF-8 gebruikt.

Dan ga ik de tekst die mogelijk bijzondere tekens bevat opslaan in de database. Hiervoor heb ik diverse varianten geprobeerd, maar de meest logische manier lijkt me:

PHP:

$dbPlot =  utf8_encode($row['plot']);
$dbPlot = htmlentities($dbPlot);

Maar dat gaat dan dus al fout, in de database komt de onderstaande tekst terecht

A Clockwork Orange is one of Stanley Kubrickâ??s

Als ik dan nog utf8_decode() gebruik na het uitlezen van de database haalt dat (natuurlijk) ook niks uit. Deze manier werkt dus niet....

Dan heb ik ook nog geprobeerd om de database gewoon op Latin8 te laten staan en dan haal ik de tekst die ik wil opslaan in de database eerst door

PHP:

mb_convert_encoding($dbPlot, "ISO-8859-1", "UTF-8");

Ook dan komt de verkeerde data in de database terecht:

A Clockwork Orange is one of Stanley Kubrick?s

Kan iemand me helpen?? Ik weet het niet meer

[MueR]

Staan je tabellen/kolommen in de database uberhaupt wel op UTF8? Als die nog op latin staan kan jij nog zo lief spelen met encoding in php, dan gaat het stuk als het in de database aankomt.

[monnick]

Ja, staat op "utf8_unicode_ci" (ook latin8 geprobeerd).

Ik vind het ook vreemd dat ik niet (enorm) veel informatie over dit probleem vind. Het lijkt me toch iets waar developers die data in-en-uit een database halen waarin rare tekens kunnen voorkomen tegen aan moeten lopen.

Ik ben bijna zo ver dat ik een eigen functie schrijf die tekens die niet in Latin-8 voorkomen even verander naar tekens die daar wel in voorkomen. Dus dat de gekke apostrof uit "Kubrick's" verandert wordt naar een normale '.

[ Voor 29% gewijzigd door monnick op 06-08-2010 01:01 ]

[Woy]

monnick schreef op vrijdag 06 augustus 2010 @ 00:43:
utf8_encode()
....
utf8_decode()

Zolang alles in de hele chain gewoon utf-8 is, heb je die functies nooit nodig. Je hoeft immers niet te encoden, want de string is al in UTF-8, en decoden hoeft ook niet, want je wil het ook weer als UTF-8 weergeven.

Decode/encode hoef je in principe alleen maar te gebruiken als je van of naar UTF-8 gaat, en dat is hier dus niet het geval, want als het goed is, krijg je al UTF-8 binnen.

Als ik jou was zou ik alle encode/decodes er dus uithalen, en gaan kijken in welke schakel er geen UTF-8 gebruikt word. Het zou inderdaad best zo kunnen zijn, zoals MueR zegt, dat je database gewoon niet op UTF-8 ingesteld staat. Dan kun je je connectie wel op UTF-8 instellen, maar dat veranderd natuurlijk niks aan je database.

edit:
als de database wel goed staat, dan moet je eens gaan kijken of de data wel echt als UTF-8 doorgestuurd word naar de web-server

[ Voor 7% gewijzigd door Woy op 06-08-2010 01:02 ]

[RobIII]

monnick schreef op vrijdag 06 augustus 2010 @ 01:00:
Ik vind het ook vreemd dat ik niet (enorm) veel informatie over dit probleem vind.

Dan zoek je toch niet goed. En op google wemelt het al helemaal...

[monnick]

Aah, opgelost! De data kwam uiteindelijk goed in de database te staan. Problemen hier waren dat de encoding van de tabel eerst op UTF-8 stond en dat ik data nog door urf8_encode() heen haalde.

Alleen toen werd de output vern**kt door htmlentities(), dat is opgelost door de charset parameter mee te geven.

PHP:

$dbPlot =       htmlentities($row['plot'], ENT_QUOTES, "UTF-8");

In ieder geval wel een nuttig probleem om eens te hebben!

[Verwijderd]

monnick schreef op vrijdag 06 augustus 2010 @ 01:12:
Aah, opgelost! De data kwam uiteindelijk goed in de database te staan. Problemen hier waren dat de encoding van de tabel eerst op UTF-8 stond en dat ik data nog door urf8_encode() heen haalde.

Alleen toen werd de output vern**kt door htmlentities(), dat is opgelost door de charset parameter mee te geven.

PHP:

$dbPlot =       htmlentities($row['plot'], ENT_QUOTES, "UTF-8");

In ieder geval wel een nuttig probleem om eens te hebben!

Is dit niet beter op te lossen door deze query na je connectie als eerste uit te voeren?

code:

set names 'utf8'

[RobIII]

Verwijderd schreef op vrijdag 06 augustus 2010 @ 01:31:
[...]

Is dit niet beter op te lossen door deze query na je connectie als eerste uit te voeren?

code:

set names 'utf8'

Heb je het topic überhaupt gelezen?

[Verwijderd]

RobIII schreef op vrijdag 06 augustus 2010 @ 01:35:
[...]

Heb je het topic überhaupt gelezen?

[ Voor 42% gewijzigd door Verwijderd op 08-02-2011 23:37 ]

[Voutloos]

En die query heeft als voetnoot dat het niet de aanbevolen manier is. Gebruik liever functies als mysql_set_charset() .

Verder valt je post onder het stereotype hint bij character encoding problemen: "Gok X voor component Y en kijk eens of dat helpt!!!1111one". Je moet gewoon van elke schakel weten hoe elke string qua character encoding geinterpreteerd dient te worden.

[ Voor 51% gewijzigd door Voutloos op 06-08-2010 09:33 ]

[roy-t]

In plaats van replace kun je natuurlijk ook een stored procedure gebruiken die checkt of een waarde uniek is en zo ja deze insert, anders niets doet.

Voor T-SQL moet dat ongeveer zo: http://roy-t.nl/index.php...nique-transact-sqlms-sql/ maar ik neem aan dat het met MySQL niet heel veel anders is.

Edit hiermee moet je er wel kunnen komen: http://www.mysqltutorial....d-procedure-tutorial.aspx


Voordeel: maar 1 round trip naar de database (dus sneller), stored procedures zijn veiliger en minder redundante code. (Hoewel het initialiseren van een stored procedure wel een paar regels kost)

[ Voor 30% gewijzigd door roy-t op 06-08-2010 09:53 ]

[JochemK]

monnick schreef op dinsdag 03 augustus 2010 @ 21:17:
Aha, bedankt! De functie mysql_insert_id() maakt het alweer een paar regels korter.

Het maakt het ook foutgevoeliger lijkt me. Stel dat In de tijd tussen dat jij een record insert en het laatst ingevoerde id opvraagt iemand anders nog iets insert...

[webfreakz.nl]

kingjotte schreef op vrijdag 06 augustus 2010 @ 15:22:
[...]


Het maakt het ook foutgevoeliger lijkt me. Stel dat In de tijd tussen dat jij een record insert en het laatst ingevoerde id opvraagt iemand anders nog iets insert...

Dat leek mij ook, en volgens http://php.net/manual/en/function.mysql-insert-id.php

Note: Because mysql_insert_id() acts on the last performed query, be sure to call mysql_insert_id() immediately after the query that generates the value.

klopt dat... niet echt handig dus Maar misschien kan je dit voorkomen door de "link_identifier" te specificeren, al blijkt uit die manual niet of dat het verhelpt.

[ Voor 12% gewijzigd door webfreakz.nl op 06-08-2010 15:38 ]

[cariolive23]

kingjotte schreef op vrijdag 06 augustus 2010 @ 15:22:
[...]


Het maakt het ook foutgevoeliger lijkt me. Stel dat In de tijd tussen dat jij een record insert en het laatst ingevoerde id opvraagt iemand anders nog iets insert...

Een ander gebruikt een andere databaseconnectie. Dat is dus geen probleem, je mag best een kwartiertje wachten. Zolang jij jouw eigen database connectie open houdt, kun je het laatste id opvragen van de insert query die jij hebt verstuurd. Je hoeft er alleen maar voor te zorgen dat jij na iedere INSERT het id opvraagt en niet eerst tig INSERT's gaat uitvoeren en dan nog probeert om de id's van deze tig queries op te vragen.