DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Ik breek m'n nek over het volgende probleem:
Ik heb een database met Poolse, Turkse en andere speciale karakters. Zonder de collatie te veranderen van utf8_general_ci naar een andere collatie kan ik bijvoorbeeld strings met de Poolse "ł" niet vinden door simpelweg een "l" te typen met MySQL. Ik zou de collatie wel willen aanpassen, maar dan zit ik waarschijnlijk met het probleem dan andere karakters, die niet binnen de collatie vallen, weer niet gevonden kunnen worden.
Hoe zouden jullie zoiets oplossing?
Ik heb een database met Poolse, Turkse en andere speciale karakters. Zonder de collatie te veranderen van utf8_general_ci naar een andere collatie kan ik bijvoorbeeld strings met de Poolse "ł" niet vinden door simpelweg een "l" te typen met MySQL. Ik zou de collatie wel willen aanpassen, maar dan zit ik waarschijnlijk met het probleem dan andere karakters, die niet binnen de collatie vallen, weer niet gevonden kunnen worden.
Hoe zouden jullie zoiets oplossing?
Heb je de MySQL-verbinding wel geinitialiseerd met de UTF8-karakterset? (SET NAMES 'utf8' )? De utf8_general_ci collation zou gewoon goed moeten zijn.
Sorry, ik haal 2 dingen door elkaar.quote:Op vrijdag 7 juni 2013 19:03 schreef zoem het volgende:
Heb je de MySQL-verbinding wel geinitialiseerd met de UTF8-karakterset? (SET NAMES 'utf8' )? De utf8_general_ci collation zou gewoon goed moeten zijn.
Ik kan dus wel die Poolse "ł" vinden, door die gewoon in de query te gebruiken, maar ik wil 'm juist kunnen vinden als ik een gewone "l" gebruik.
Hmm dat is lastiger. Utf8_general_ci zou diakriet (en case) insensitive moeten zijn. Al eens LIKE geprobeerd? Een andere -simpel doch doeltreffende- oplossing zou zijn om een genormaliseerde kolom te introduceren. Hangt een beetje van de situatie af wat handig is in deze.
http://dev.mysql.com/doc/refman/5.0/en/charset-literal.html
http://dev.mysql.com/doc/refman/5.0/en/charset-literal.html
Zo'n teken wordt gewoon gematched op i. Anders utf8_ bin nemen
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Weer een mooie vandaag: de Flickr API geeft gewoon ongeldige JSON terug 
WTF, Flickr is nota bene eigendom van Yahoo!, het bedrijf waar jarenlang Douglas Crockford werkte, de uitvinder van JSON.
Echt bizar
Uiteindelijk werkte deze suggestie: http://www.themusingsofal(...)rs-invalid-json.html
WTF, Flickr is nota bene eigendom van Yahoo!, het bedrijf waar jarenlang Douglas Crockford werkte, de uitvinder van JSON.Echt bizar
Uiteindelijk werkte deze suggestie: http://www.themusingsofal(...)rs-invalid-json.html
Weet je dat zeker? Als ik LIKE 'B%' doe vind ik wel de juiste records, als ik LIKE 'Bi% doe niet.quote:Op vrijdag 7 juni 2013 20:31 schreef Juicyhil het volgende:
Zo'n teken wordt gewoon gematched op i. Anders utf8_ bin nemen
Anders moet je dat veld even converteren naar ascii om te kijken waar hij op zoektquote:
[..]
Weet je dat zeker? Als ik LIKE 'B%' doe vind ik wel de juiste records, als ik LIKE 'Bi% doe niet.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik ben nog helemaal niet thuis in de encode/decoding.
utf8_bin geeft een geëncodeerde string. Geen flauw idee wat ik daarmee moet.
utf8_bin geeft een geëncodeerde string. Geen flauw idee wat ik daarmee moet.
Ik zoek met LIKE, maar dat werkt niet. Een genormaliseerde kolom is een serieuze optie. Moet ik die encoderen?quote:
Hmm dat is lastiger. Utf8_general_ci zou diakriet (en case) insensitive moeten zijn. Al eens LIKE geprobeerd? Een andere -simpel doch doeltreffende- oplossing zou zijn om een genormaliseerde kolom te introduceren. Hangt een beetje van de situatie af wat handig is in deze.
http://dev.mysql.com/doc/refman/5.0/en/charset-literal.html
convert(veld as ascii) toch?quote:
Ik ben nog helemaal niet thuis in de encode/decoding.
utf8_bin geeft een geëncodeerde string. Geen flauw idee wat ik daarmee moet.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Het is dat we posts niet kunnen plussen of liken! anders had je er 1 te pakkenquote:
[..]
Veel korter dan dit kan haast niet lijkt me
[ code verwijderd ]
Just say hi!
Zowel met utf8_general_ci als met uft8_bin:quote:
Op 
[ Bericht 7% gewijzigd door pascal08 op 07-06-2013 23:54:39 ]
Over de database structuur in het algemeen, wat zijn tips/concepten die handig zijn met het oog op scheiden van data en het later weer in elkaar parsen. Voor een artikel bijvoorbeeld, doe je dan een artikel incl. mark-up (html) in 1 table-cell? Of gebruik je een row per paragraaf/header/link/afbeelding etc. met elke een id van het artikel of bijvoorbeeld een array met alle paragrafen en een aparte table met alle headers?
En afbeeldingen sla je niet op maar daar verwijs je naar ivm. snelheid, maar hoe beheer je die data dan (volgorde, links naar bestanden, bestanden wijzigen etc.)?
En ik lees 'overal' dat mysql depreciated wordt/is. Is het handiger om mysqli of pdo aanleren (aangezien ik net kom kijken)
En afbeeldingen sla je niet op maar daar verwijs je naar ivm. snelheid, maar hoe beheer je die data dan (volgorde, links naar bestanden, bestanden wijzigen etc.)?
En ik lees 'overal' dat mysql depreciated wordt/is. Is het handiger om mysqli of pdo aanleren (aangezien ik net kom kijken)
“Specialization is for insects”.—Robert Heinlein
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_formquote:Op zaterdag 8 juni 2013 18:36 schreef n8n het volgende:
Over de database structuur in het algemeen, wat zijn tips/concepten die handig zijn met het oog op scheiden van data en het later weer in elkaar parsen. Voor een artikel bijvoorbeeld, doe je dan een artikel incl. mark-up (html) in 1 table-cell? Of gebruik je een row per paragraaf/header/link/afbeelding etc. met elke een id van het artikel of bijvoorbeeld een array met alle paragrafen en een aparte table met alle headers?
En afbeeldingen sla je niet op maar daar verwijs je naar ivm. snelheid, maar hoe beheer je die data dan (volgorde, links naar bestanden, bestanden wijzigen etc.)?
En ik lees 'overal' dat mysql depreciated wordt/is. Is het handiger om mysqli of pdo aanleren (aangezien ik net kom kijken)
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
En ja, gewoon PDO gebruiken. Nog beter met prepared statements omdat sneller/veiliger.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
dus kort samengevat elke type data in een eigen table met id's voor communicatie? ga nog even verder lezen maar dat is de snelle indruk die ik krijg bij het lezen van een bron onderaan de paginaquote:
[..]
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
http://web.archive.org/we(...)malizationRules.html
ik lees idd dat pdo veiliger is (over snelheid gemixte berichten) maar ook gelimiteerder. Nu zal ik daar nu niet tegenaan lopen maar wellicht ooit. bedankt alvast, nuttige infoquote:
En ja, gewoon PDO gebruiken. Nog beter met prepared statements omdat sneller/veiliger.
edit: lees dat pdo gelimiteerd is tot object georienteerd werken maar dat lijkt me alleen maar nuttig (omdat het mij dwingt zo te werken)
[ Bericht 2% gewijzigd door n8n op 08-06-2013 18:50:56 ]
“Specialization is for insects”.—Robert Heinlein
Twee kolommen aanmaken, eentje met de originele inhoud en eentje voor de geparste versie. Ik zou het hele artikel in een enkel record gooien en niet gaan scheiden op paragraaf oid. Dan maak je het jezelf lastiger dan nodig.quote:
Over de database structuur in het algemeen, wat zijn tips/concepten die handig zijn met het oog op scheiden van data en het later weer in elkaar parsen. Voor een artikel bijvoorbeeld, doe je dan een artikel incl. mark-up (html) in 1 table-cell? Of gebruik je een row per paragraaf/header/link/afbeelding etc. met elke een id van het artikel of bijvoorbeeld een array met alle paragrafen en een aparte table met alle headers?
Afbeeldingen gewoon uploaden naar de webserver en daar opslaan in een handige directorystructuur (iets met datum)? De opslag van afbeeldingen/filmpjes/media zou je los moeten zien van een artikel. Metadata kun je eventueel opslaan in een apart ingerichte tabel.quote:En afbeeldingen sla je niet op maar daar verwijs je naar ivm. snelheid, maar hoe beheer je die data dan (volgorde, links naar bestanden, bestanden wijzigen etc.)?
Met JH, ik zou voor PDO gaan icm prepared statements. Er zijn verder geen noemenswaardige limitaties tov mysql vziw.quote:En ik lees 'overal' dat mysql depreciated wordt/is. Is het handiger om mysqli of pdo aanleren (aangezien ik net kom kijken)
Absoluut niet. Voor veel zaken zijn in principe geen id's nodig. Maar doen veel dba's dat uit gemakszucht.quote:
[..]
dus kort samengevat elke type data in een eigen table met id's voor communicatie? ga nog even verder lezen maar dat is de snelle indruk die ik krijg bij het lezen van een bron onderaan de pagina
http://web.archive.org/we(...)malizationRules.html
PDO zelf weet ik niet hoe dat zit met performance. Maar prepared statements hoeven door mysql niet opnieuw gecompileerd te worden, waardoor je daar (minimale) snelheidswinst hebt. Zelf gebruik ik altijd gewoon een ORM module.quote:[..]
ik lees idd dat pdo veiliger is (over snelheid gemixte berichten) maar ook gelimiteerder. Nu zal ik daar nu niet tegenaan lopen maar wellicht ooit. bedankt alvast, nuttige info
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Daar had ik nog niet aan gedacht. Als er dan ooit fundamentele mark-up wijzigingen zijn hoeft er maar 1 keer een nieuwe 'lees'-kolom aangemaakt te wordenquote:
[..]
Twee kolommen aanmaken, eentje met de originele inhoud en eentje voor de geparste versie.
Ik lees nog even verderquote:
[..]
Absoluut niet. Voor veel zaken zijn in principe geen id's nodig. Maar doen veel dba's dat uit gemakszucht.
[ Bericht 17% gewijzigd door n8n op 08-06-2013 18:58:47 ]
“Specialization is for insects”.—Robert Heinlein
Daarom coden we toch?quote:
Absoluut niet. Voor veel zaken zijn in principe geen id's nodig. Maar doen veel dba's dat uit gemakszucht.
In theory there is no difference between theory and practice. In practice there is.
Dat is ook te zien aan de code van sommige programmeursquote:
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Wat is tegenwoordig een goede php editor? Besloten toch maar eens van kladblok af te stappen.
Touching from a distance ~
phpStormquote:
Wat is tegenwoordig een goede php editor? Besloten toch maar eens van kladblok af te stappen.
