blog html pagina vs blob in mysql qua snelheid
Ik heb een html pagina per site.
Als ik alle teksten nu in een blob field in een mysql database aanmaak dan vermoed ik wel dat dit langzamer is.
Als er straks honderden blogs zijn, denk ik dat de database het zwaar gaat krijgen.
Is het verstandig om steds een html bestand aan te maken voor een nieuwe blog als het om snelheid gaat?
groet
Daniel
Maar buiten dat is het sneller om alle tekst gewoon als html statische files te laden met een referentie vanuit de database?
Ik denk van wel.
>> Maar buiten dat is het sneller om alle tekst gewoon als html statische files te laden met een referentie vanuit de database?
Soms wel, soms niet. Meten is weten.
je moet utf8mb4 hebben, voor emoticons in mijn geval.
utf-8 kan alleen 3 byte characters opslaan en het laatste 4 byte characters.
Daarnaast werkt het allen in blob velden en worden niet opgeslagen als text, waarom weet ik niet. IS blob langzamer?
Daniel van Seggelen op 11/05/2017 17:35:03:
Ja dat gebruik ik ook, maar mijn vraag was dus, waarom text niet werkt in mijn geval, en is BLOB geen goede optie qua snelheid?
Het lijkt me bij een blog wel handig als je ook text searches kunt doen. Dat is niet mogelijk bij BLOBs.
Meestal werkt het het best als je een datatype gebruikt op de manier waarvoor het bedoeld is. Ga dus geen tekst opslaan in een BLOB-veld.
Gewijzigd op 15/05/2017 16:38:35 door Willem vp
PHP Maarten op 11/05/2017 17:14:00:
WordPress kan ook met emoticons omgaan, ze gebruiken utf8mb4_unicode_ci.
Dat is een collation, geen character encoding.
@Daniel ben benieuwd waarom je TEXT in Binary Large OBjects zou willen opslaan en hoe je aan dit idee komt?
Los daarvan, ben je ook nagegaan of je vervolgens tekstpassages (makkelijk) kunt zoeken in zo'n BLOB? En je zult op een of andere manier moeten bijhouden welke character encoding je gebruikt bij opslaan en welke mogelijke conversies je moet uitvoeren bij uitlezen. Wat @Willem zegt: BLOBs zijn nu niet bepaald bedoeld voor opslag van tekst, dus je zult een (of meer) goede reden(en) moeten hebben om dit te doen (EDIT) die je ertoe hebben doen besluiten om niet voor een meer gangbare oplossing te kiezen.
Gewijzigd op 15/05/2017 19:34:27 door Thomas van den Heuvel
Quote:
@Daniel ben benieuwd waarom je TEXT in Binary Large OBjects zou willen opslaan en hoe je aan dit idee komt?
Dat schreef ik al, de enige reden is, dat als ik er een TEXT van maak, dan worden de unicode emoticons niet erin opgeslagen, in een blob wel en het lijkt prima te werken.
- Ariën - op 15/05/2017 19:46:46:
Dat lijkt mij dan meer aan de collatie te liggen dan aan de datatype.
Een collation bepaalt hoe tekst wordt geselecteerd en gerangschikt. Ik denk niet dat dit de boosdoener is, ik zou eerder verwachten dat het in de hoek van de character encoding zit. Om dit echter na te gaan zul je meer data moeten verschaffen over:
- hoe het HTML-document waarin je de code weergeeft in elkaar zit (meta-tags of een header() die aangeeft welke character encoding je gebruikt?)
- hoe je een connectie maakt met je database en/of je een character encoding selecteert met een set_charset() methode
- hoe de tabel- en kolomdefinities van de tabellen luiden (ondersteunen deze voldoende lange UTF-8 karakters om deze emoticons op te slaan?)
Idealiter is al het bovenstaande UTF-8. In MySQL heb je echter meerdere utf8-smaken.
Ben je ook nagegaan of er op byte-niveau iets verandert als je data uit je database uitleest? Dat zou dan een indicatie zijn van mogelijke ongewenste vertalingen of data die corrupt is geraakt tijdens wegschrijven/updaten.
Gewijzigd op 15/05/2017 21:39:30 door Thomas van den Heuvel
ook de mysql in UTF-8 voordat ik de insert query uitvoer.
Ik gebruik MariaDB 10.1
De charset is urf, want dit doe ik voordat ik hem invoer in de BLOB field:
mysqli_set_charset($DBD->conn(),"utf8");
Maar lees ook aub de gehele post, want daar staat dit ook al genoemd.
En nogmaals, collation is niet hetzelfde als character encoding...
EDIT: dit is je probleem. set_charset() zegt zoveel als "geef mij data terug in deze character encoding". Omdat de tabellen utf8mb4 zijn (en de data hopelijk ook) wordt alles terugvertaald naar utf8 (single byte UTF-8). Alle karakters die hiervan afwijken (meer dan 1 byte innemen) worden vertaald naar een vraagteken (?) of worden gestript.
Gewijzigd op 16/05/2017 23:25:24 door Thomas van den Heuvel