Може ли вака.
Да, може
. Слика е, не е карактер
.
Не сум админ, ама према горенаведеното не би требало да има проблем ради што сега емоцијата е слика од некој си "third party" сајт ( нз како е превод).
Nope, грешка си
.
Се зачувува како:
&#XXXXXX;Конкретно слончето на Toma е зачувано како:
🐘Е сега, што е проблемот. Ако скриптата за upgrade, при upgrade само ги смени колоните од UTF8 (тоа требало да биде UTF8MB3 на времето, но некој изгледа сакал да поедностави и го крстил само UTF8
) во UTF8MB4, но кодот во табелите остане ист, можно е да се јават неколку различни проблеми. Прво, новата верзија од скриптата да не знае да го интерпретира HTML кодот за emojis и да не го прикаже emoji-то. ОК, ова не е толку голем проблем, само ќе има кодови низ post-ови кои треба да бидат emojis, но не се. Второ, поголем проблем, да стигне до кодот, да знае дека станува збор за emoji, но да не знае да го прикаже, бидејќи, нели сега адекватните колони се во UTF8MB4 и не би требало да има проблем, нели
. Епа не е се баш така розово. Може да не го прикаже бидејќи дел од кодот можно е и да не биде пишан како што треба и да е направен да препознава HTML кодови за emojis, но да не e пишано како да изврши конверзија на овој код од HTML во binary и да го прикаже во неговиот native формат, т.е. хексадецимално. Можно е и при конверзија (кога ќе треба да го прикаже на екран), само да фрли некој error со бел екран и толку
.
Ова се само дел од проблемите кои може да настанат. Зависи од тоа што ќе избереш при upgrade процесот, но ако избереш да изврши конверзија на цела база од UTF8 во UTFMB4, ќе треба да ги помине сите post-ови и приватни пораки, а на форум со 100.000 post-ови (каков што е овој), прво, тоа одзема време, второ, ако наиде на emoji карактер, можно е да углави и да врати назад error "incorrect string value" да ти изнареди hex карактери, па ај барај кои се тие, па ај менувај ги рачно во базата
... се е*авав со вакви работи при првиот upgrade, немам намера пак да го правам тоа.
Е сега, пошто сме 2019-та, вањда може да се користат и двата кода, потоа компресијата на самите податочни сервери е поголема, самоте сервери се поголеми, па теореткстата разлика од 3 до 4 бајта односно 25% може да се преслика како некоја знемарлива разлика од 2-3%, но 3% од 1000 тв и не е баш тљка малце.
Не смееш да користиш компресија додека базата работи, т.е. додека скриптата чита и запишува во неа (најпросто, додека форумот или било кој друг сајт e online). Прво, тоа екстремно ќе дигне CPU usage бидејќи при секој запис или исчитување на нешто од базата (сметај дека и ботови и гости се присутни на форумов, не само членовите), базата ќе треба да се отпакува, да се запише или исчита нешто од неа и потоа пак да се спакува. Згора на тоа, при отпакување мора да се направи нов фајл (нели, отпакуваниот) и потоа, откако пак ќе се спакува, да се избрише. На големи форуми, ова можно е да треба да се случува и неколку пати во секунда. Да не правам муабет и за time delay кој ќе се јави поради пакување и отпакување, за CRC error-и од 100 пати отпакувана и спакувана база (можеби не за неколку недели, но за месец или два, базата сигурно ќе почне да јавува error-и бидејќи, при секое отпакување и пакување, нема CRC проверка дали отпакуваното е идентично со оригиналната верзија, т.е. онаа која била пред да биде спакувана пак базата, а и дури и ако има таква проверка, тоа ќе трае многу на бази со големина од 100, 200, 300MB, така да, ова е практично неизводливо), како и за фактот дека кај hosting компаниите, најевтини на понуда се shared hosting пакетите (повеќе клиенти на еден сервер), а верувај дека форумов немаше да постои ако мораше цел сервер некаде да се рента за да може на него да седи само форумов (чинат од 50 евра месечно, па нагоре... истото важи и за VPS, тие се дури и поскапи, по $70, $80 месечно па нагоре).
Така да, ова што го спомна е неизводливо. Да, базите ги чувам во архиви, но како backups, кога се offline. И да, така драстично се намалува големината на базата (компресијата е од прилика 1/5 за zip, 1/7 или 1/8 за 7zip), но тоа само ако е offline базата
.
Инаку, да, серверот на кој е поставен форумов користи data compression, но само за http data, т.е. податоците кои се примаат од страна на серверот кога ќе се најавиш на форумов, кога ќе пишеш во некоја тема, кога ќе отвориш некоја тема, итн. Значи, само за http requests.
Разликата во големината на UTF8 и UTFMB4 сега е веќе занемарливо мала. Но, како што пишав, ова не беше така пред 15 години. Така да, да, во повеќето случаи, сега веќе без проблем може да дефинираш data type за колона како UTF8MB4, но пак ќе пишам, ова сеуште не е ситуација насекаде. За година или две, да, би требало целосно да ги снема оние сервери кои не поддржуваат UTF8MB4 data type (т.е. на кои сопствениците им ја имаат ограничено оваа опција во SQL), но сега за сега, реалноста е таа
.
Друга работа за да се запишат 100мб на сервер треба 133,166 или 200 мегабајти минимум, оти нели ти му плаќааш за местото и хостот мора да ти даде некаква гаранција дека нема да ти се поебаат податоците од "bad sector", или друг тривијален проблем.
На host-от на кој моментално лежи форумов, таква гаранција нема... бидејќи чини $12 годишно
. Да имавме повеќе пари, ќе имавме и поскап host... колку пари, толку музика.
Сепак, тоа не значи дека не се прават редовни backup-и на базата. Правам редовни backup-и и на базата, и на скриптата и се чуваат идентични копии на барем две локации
.
