blog html pagina vs blob in mysql qua snelheid

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Production Engineer

Supermicro® (NASDAQ: SMCI), the leading innovator in high-performance, high-efficiency server technology, is a premier provider of advanced server Building Block Solutions® for Data Center, Cloud Computing, Enterprise IT, Hadoop/Big Data, HPC and Embedded Systems worldwide. Supermicro is committed to protecting the environment through its “We Keep IT Green®” initiative and provides customers with the most energy-efficient, environmentally-friendly solutions available on the market. Supermicro Computer B.V. is seeking a: Production Engineer Who is responsible for the assembly and building of Supermicro product that meet products quality requirements and shipment deadlines. This position will be located in the HMEA headquarters in 's-Hertogenbosch,

Bekijk vacature »

Daniel van Seggelen

Daniel van Seggelen

10/05/2017 23:13:51
Quote Anchor link
Ik wil een hoop blogs kunnen aanbieden op mijn site.

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
 
PHP hulp

PHP hulp

17/12/2018 21:42:25
 
- Ariën -
Beheerder

- Ariën -

11/05/2017 08:44:08
Quote Anchor link
Waarom gebruik je geen TEXT-type?
 
Daniel van Seggelen

Daniel van Seggelen

11/05/2017 09:23:16
Quote Anchor link
Nou het punt is dat ik unicode smilies opsla in de database en als ik er een TEXT van maak worden ze niet opgeslagen vreemd genoeg.

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.
 
Ben van Velzen

Ben van Velzen

11/05/2017 10:56:51
Quote Anchor link
Ze worden wel opgeslagen als je een utf8 binary type kiest.
>> 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.
 
Daniel van Seggelen

Daniel van Seggelen

11/05/2017 16:41:35
Quote Anchor link
Is niet waar.

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?
 
Anoniem M

Anoniem M

11/05/2017 17:14:00
Quote Anchor link
WordPress kan ook met emoticons omgaan, ze gebruiken utf8mb4_unicode_ci.
 
Daniel van Seggelen

Daniel van Seggelen

11/05/2017 17:35:03
Quote Anchor link
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?
 
Willem vp

Willem vp

15/05/2017 16:37:04
Quote Anchor link
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
 
Thomas van den Heuvel

Thomas van den Heuvel

15/05/2017 19:31:58
Quote Anchor link
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
 
Daniel van Seggelen

Daniel van Seggelen

15/05/2017 19:36:40
Quote Anchor link
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 -
Beheerder

- Ariën -

15/05/2017 19:46:46
Quote Anchor link
Dat lijkt mij dan meer aan de collatie te liggen dan aan de datatype.
 
Thomas van den Heuvel

Thomas van den Heuvel

15/05/2017 21:37:45
Quote Anchor link
- 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
 
Daniel van Seggelen

Daniel van Seggelen

16/05/2017 11:05:57
Quote Anchor link
de meta tags zijn utf-8,
ook de mysql in UTF-8 voordat ik de insert query uitvoer.

Ik gebruik MariaDB 10.1
 
Thomas van den Heuvel

Thomas van den Heuvel

16/05/2017 18:02:22
Quote Anchor link
"UTF-8" bestaat niet in MySQL. Je zult een utf8* variant moeten kiezen die voldoende lange byte-sequences kan opslaan voor de karakters/emoticons die je wilt opslaan.
 
Daniel van Seggelen

Daniel van Seggelen

16/05/2017 18:38:11
Quote Anchor link
utf8mb4 is de variant voor de mysql collatie.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

16/05/2017 19:35:41
Quote Anchor link
Als utf8mb4 de character encoding is, dan moet je dat ook instellen, anders spreek je twee verschillende dialecten van UTF-8.

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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.