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.
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:Op vrijdag 7 juni 2013 20:34 schreef pascal08 het volgende:
[..]
Weet je dat zeker? Als ik LIKE 'B%' doe vind ik wel de juiste records, als ik LIKE 'Bi% doe niet.
Ik zoek met LIKE, maar dat werkt niet. Een genormaliseerde kolom is een serieuze optie. Moet ik die encoderen?quote:Op vrijdag 7 juni 2013 20:20 schreef zoem het volgende:
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:Op vrijdag 7 juni 2013 20:41 schreef pascal08 het volgende:
Ik ben nog helemaal niet thuis in de encode/decoding.
utf8_bin geeft een geëncodeerde string. Geen flauw idee wat ik daarmee moet.
Het is dat we posts niet kunnen plussen of liken! anders had je er 1 te pakkenquote:Op dinsdag 4 juni 2013 21:17 schreef zoem het volgende:
[..]
Veel korter dan dit kan haast niet lijkt me
[ code verwijderd ]
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)
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:Op zaterdag 8 juni 2013 18:39 schreef Juicyhil het volgende:
[..]
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
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:Op zaterdag 8 juni 2013 18:41 schreef Juicyhil het volgende:
En ja, gewoon PDO gebruiken. Nog beter met prepared statements omdat sneller/veiliger.
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: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?
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:Op zaterdag 8 juni 2013 18:45 schreef n8n het volgende:
[..]
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
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:Op zaterdag 8 juni 2013 18:50 schreef zoem het volgende:
[..]
Twee kolommen aanmaken, eentje met de originele inhoud en eentje voor de geparste versie.
Ik lees nog even verderquote:Op zaterdag 8 juni 2013 18:50 schreef Juicyhil het volgende:
[..]
Absoluut niet. Voor veel zaken zijn in principe geen id's nodig. Maar doen veel dba's dat uit gemakszucht.
Daarom coden we toch?quote:Op zaterdag 8 juni 2013 18:50 schreef Juicyhil het volgende:
Absoluut niet. Voor veel zaken zijn in principe geen id's nodig. Maar doen veel dba's dat uit gemakszucht.
Dat is ook te zien aan de code van sommige programmeursquote:
phpStormquote:Op zondag 9 juni 2013 18:01 schreef Purplesparks het volgende:
Wat is tegenwoordig een goede php editor? Besloten toch maar eens van kladblok af te stappen.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |