Форум русской поддержки Joomla!® CMS
03.12.2016, 17:47:37 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
   
   Начало   Поиск Joomla 3.0 FAQ Joomla 2.5 FAQ Joomla 1.5 FAQ Правила форума Новости Joomla Реклама Войти Регистрация Помощь  
Страниц: [1] 2  Все   Вниз
  Добавить закладку  |  Печать  
Автор

Кодировка кириллицы в БД - все ли хорошо?

 (Прочитано 1644 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Beer
Живу я здесь
******

Репутация: +41/-1
Offline Offline

Сообщений: 1050


БИРУ - БИР!


« : 10.05.2014, 18:36:06 »

 Смущает меня сохранение записей в БД (`jos_zoo_item` set `elements`) вида:

Код:
"1a696e9e-938b-4b16-b64a-33f6a2612d46":  {
"0":  {
"value": " \u0410\u043a\u0432\u0430\u0414\u043e\u043a - \u044d\u0442\u043e \u043f\u0440\u043e\u0434\u0430\u0436\

Таблицы все utf-8_general_ci

 Т.е. хренчегопрочтешьнапрямую...
Записан
Влад
Осваиваюсь на форуме
***

Репутация: +2/-0
Offline Offline

Сообщений: 119



« Ответ #1 : 04.03.2016, 21:51:04 »

Вопрос актуален, так как база данных растет как грибы  Cry
Записан
ameli90
Осваиваюсь на форуме
***

Репутация: +1/-0
Offline Offline

Сообщений: 34


« Ответ #2 : 15.03.2016, 17:47:18 »

Ну правильно, символ кириллицы шифруется несколькими байтами
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #3 : 18.03.2016, 19:25:36 »

чет я разочаровался в zoo. полез смотреть, как данные хранятся, а тут такая "песня".
не удивительно, что при овер 1000 элементов грозятся апокалипсисом.
Записан
b2z
Support Team
*****

Репутация: +707/-0
Offline Offline

Пол: Мужской
Сообщений: 7517


Разраблю понемногу


« Ответ #4 : 18.03.2016, 19:47:54 »

Это стандарт сохранения JSON и ZOO тут не причём. Решение есть, но только для 5.4+

Код
$value = json_encode($value, JSON_UNESCAPED_UNICODE);

http://php.net/manual/ru/json.constants.php
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #5 : 18.03.2016, 20:00:39 »

Спасибо, ясность пришла.
Но на счет "ни при чем" - не согласен.
Это же они выбрали такой формат. Вообще не айс иметь большую базу с таким хламом вместо текстов.
Я так понимаю, в качестве решения надо раз в n дней скриптом шерстить по доп. полям и все в божеский вид перегонять?
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #6 : 18.03.2016, 20:54:40 »

Пол мира на JSON+utf8 работает и хранит данные так... Все новомодные решения либо json, либо yml. Откуда такой негатив к формату?) Вы правите базу руками? Печально...

И причем тут Zoo ? Почему это внезапно так плохо?
Я знаю огромные базы в десятки гигабайт и все хранится именно так. Это можно сказать обычный документоориентированный подход для базы.
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #7 : 18.03.2016, 21:08:47 »

в данный момент вопрос не к формату, а уже к его использованию.
коль скоро появилась возможность не генерировать мусор, по то почему бы её не включить опционально.
я ничего не имею против гигабайтных баз данных. я только против гемороя с их использованием / импортом / экспортом в условиях наших ценовых хостинговых реалий.
Записан
robert
Профи
********

Репутация: +343/-11
Offline Offline

Пол: Мужской
Сообщений: 3567


« Ответ #8 : 18.03.2016, 22:08:04 »

Ну, json - это тот же текст, только
хренчегопрочтешьнапрямую...
, зато никаких сюрпризов с utf8 не будет.
И ничего этого
надо раз в n дней скриптом шерстить по доп. полям и все в божеский вид перегонять?
не нужно делать.
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #9 : 18.03.2016, 22:17:22 »

robert, ну так в стандартных компонентах Joomla тоже нет никаких проблем с utf и база не растет в n раз.
ну реально, если мне нужен 1 язык, русский - зачем мне эти лишние мегабайты в бд?
даже часть местных профи НЕ советуют использовать zoo на больших проектах. Интересно, почему?...
типа, давайте придумает *** кэширование, php7 поставим, но, блин, не тронем священную корову БД, потому что... потому.
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #10 : 18.03.2016, 22:20:31 »

Это не мусор, а utf8. Так выглядят 2 байта. Компонент работает с любыми языками и обязан хранить данные правильно.
Хостинг и размер базы тоже тут не играют особой роли, очень странный аргумент.  Диски очень дешевая штука. Это поле не используется для поиска, не индексируется MySQL и не учавствует в условиях выборки, весит мало.

Уверен что если отключить и почистить умный поиск то сразу база похудеет. Кто-нибудь пробовал?) похож, нет.

Для подхода с элементами хранить все ввиде документа - вполне разумный вариант. Альтернатива будет разве что eav, а это для таких сайтов не нужно.

Думаю причина в другом, вы хотите править базу руками, а не через api? И чтобы ничего вам за это не было. Это вредно для здоровья...
При этом потеряете целостность данных, например не обновится поисковый индекс для Zoo/Joomla(смарт) и тем более JBZoo.

Наверно десяток лет работаю с сайтами, в базу данных приходится лазить очень редко и то только чтобы увидеть explain или индекс  ли запросы вручную выполнить. Уверен что картинки на большинстве сайтов весят больше чем sql дамп.

Кстати, в последнем мускуле появился тип данных json. Хранит тск же. По сути ничего особого не дает, так же - текстовое поле.
Так в чем собственно апокалипсис?)))  какиенить толковые аргументы?
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #11 : 18.03.2016, 22:23:32 »

т.е. как не используется для поиска?
если все доп. поля в нем хранятся?
откуда у ZOO проблемы с быстродействием?
типа, делаем выборку самых дешевых товаров, парся все эти учетверенные данные...
или я чего-то не понимаю?

зы
руками ничего править не хочу ))
Записан
passer
Живу я здесь
******

Репутация: +69/-3
Offline Offline

Пол: Мужской
Сообщений: 829



« Ответ #12 : 18.03.2016, 22:29:57 »

Прочитал. Ниче не понял. json универсальный стандарт передачи данных. Просто текст. Отлично хранит в бд структурированные данные. Особой разницы в хранении строки json и просто строки "бла-бла-бла" нет.
Использовать в полях участвующих в поиске можно, но глупо.
Записан
robert
Профи
********

Репутация: +343/-11
Offline Offline

Пол: Мужской
Сообщений: 3567


« Ответ #13 : 18.03.2016, 22:32:06 »

Я про json, а не zoo. Да, zoo, IMHO, переусердствовал с json.
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #14 : 18.03.2016, 22:33:08 »

т.е. как не используется для поиска?
если все доп. поля в нем хранятся?
откуда у ZOO проблемы с быстродействием?
типа, делаем выборку самых дешевых товаров, парся все эти учетверенные данные...
или я чего-то не понимаю?

зы
руками ничего править не хочу ))

Поиск  идет по таблицам индекса. Любой. Там все хранится в нормализованном виде.
Json никто не парсит на ходу))))

Проблемы в основном изза рук. К сожалению 9 из 10 джумлистов знают максимум верстку. У  меня есть несколько тысяч примеров... Sad это очень грустно.

Есть сайт полностью на jbzoo с  десятком тысяч материалов и порядка 200тыс хитов в сутки.
Если не править руками, то почему json проблема? Пока что не видел ниодного аргумента...
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #15 : 18.03.2016, 22:42:50 »

Я про json, а не zoo. Да, zoo, IMHO, переусердствовал с json.
Где?
Joomla и масса других cms настройки тоже хранит в json. Тут контент играет роль конфигов. Обычная строка.

Поиск идет по другим таблицам.
Почему переусердствовал?)
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #16 : 18.03.2016, 22:45:23 »

passer, прочитай еще раз ))
данные практически всех полей в ZOO кодируются в одну ячейку БД в формате \u0410 = одна русская буква.
+ отдельное поле для метаописаний по такому же принципу.

ок, я как раз из тех 9, которые не программеры )
но zikkuratvk или voland (не помню кто, пусть оба ответят )) ) не советуют на больших проектах ZOO.
я подумал, что проблема именно из-за разбухающей БД.
так что хотелось бы ещё кого-то услышать из независимых экспертов )
Записан
passer
Живу я здесь
******

Репутация: +69/-3
Offline Offline

Пол: Мужской
Сообщений: 829



« Ответ #17 : 18.03.2016, 23:04:20 »

не советуют на больших проектах ZOO.
На больших проектах и Joomla не советуют. И правильно.
Для поиска есть сфинкс и подобные. Если проект большой то это обязательно vds, а значит поисковую машину поставить не проблема.
И CCK не требуется ибо делается сразу как нужно, в том числе на уровне БД.
Так что для больших проектов json не проблема. По сути особой необходимости хранить данные в json нету. От конкретной ситуации зависит.
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #18 : 18.03.2016, 23:08:37 »

Я бы тоже хотел прочитать мнения экспертов.
И так чтобы оно было подкреплено измерениями или какими то аргументами. Чтонить больше чем "тормозит потому что большая"))) так говорят те кто не понимает принципов бд.

Так же рекомендую измерить размеры таблиц. Самые большие будут - умный поиск, он коробочный.
Кстати, что такое большой проект? И все ли знают особенности работы сфинкса и оных. Его ограничения?

Так забавно порой зайти на джуфорум, почитать экспертов)
Записан
robert
Профи
********

Репутация: +343/-11
Offline Offline

Пол: Мужской
Сообщений: 3567


« Ответ #19 : 18.03.2016, 23:10:05 »

Где?
Joomla и масса других cms настройки тоже хранит в json. Тут контент играет роль конфигов. Обычная строка.

Поиск идет по другим таблицам.
Почему переусердствовал?)
Не готов аргументированно дискутировать, поскольку нечасто работал с zoo и последний раз был довольно давно (нужно было прикрутить свой компонент к zoo), но помню, что очень много ругался из-за неоправданно сложной структуры и излишней любви к формату json. Да, если не ошибаюсь, то из-за нее zoo пришлось создать отдельную таблицу (нехилую, по-моему) для поиска.
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #20 : 18.03.2016, 23:18:30 »

имхо, массы интересует формат 1000 - 5000 позиций каталога / магазина в сочетании с обычным, не выделенным хостингом.
и это, думается, именно та аудитория, для которой у JBZoo есть минимальный платный тариф.
лично я заинтересован в подобных конфигурациях и жизнеспособных решениях, которые не умрут под собственной тяжестью ).

Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #21 : 18.03.2016, 23:23:18 »

Ок, как хранить что-то чуть более сложнее чем строка, например плоский массив, а лучше вложенный. И искать по нему без готового индекса?

Почему все считают что отдельная таблица для поиска это плохо? Вот смотрю, все так делают. Вот вообще все!
Даже индекс полей в мускуле это по сути отдельная таблица для поиска.
И сфинкс работает по тому же принципу - делает свой индекс.
Записан
passer
Живу я здесь
******

Репутация: +69/-3
Offline Offline

Пол: Мужской
Сообщений: 829



« Ответ #22 : 18.03.2016, 23:28:09 »

Ну про экспертов это слишком. Куда нам.
Что касается больших проектов сие нам не ведомо. Ибо самые доходные оказались простые лендинги, вернее все что вокруг них накручено.
По сфинксу были несколько проектов. Ничего особо сложного нет. Файл конфигурации вроде этого
Показать текстовый блок
И оболочка php. Есть родной класс для работы с ним.
И ну да, свой индекс как видим. И не один.
« Последнее редактирование: 18.03.2016, 23:37:25 от passer » Записан
robert
Профи
********

Репутация: +343/-11
Offline Offline

Пол: Мужской
Сообщений: 3567


« Ответ #23 : 18.03.2016, 23:34:01 »

Ок, как хранить что-то чуть более сложнее чем строка, например плоский массив, а лучше вложенный. И искать по нему без готового индекса?

Почему все считают что отдельная таблица для поиска это плохо? Вот смотрю, все так делают. Вот вообще все!
Даже индекс полей в мускуле это по сути отдельная таблица для поиска.
И сфинкс работает по тому же принципу - делает свой индекс.
Возможно, в целом вы правы, но видел не одно сообщение о том, что с zoo БД растет в астрономической прогрессии.
И с passer солидарен: у меня тоже немереное ЧСВ, но чтобы плюнуть на весь форум...
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #24 : 18.03.2016, 23:43:09 »

Возможно, в целом вы правы, но видел не одно сообщение о том, что с zoo БД растет в астрономической прогрессии.
И с passer солидарен: у меня тоже немереное ЧСВ, но чтобы плюнуть на весь форум...

Хорошо. Почему большая база данных это плохо? Например, есть такие ребята - эквид (думаю все знают). Они хранили довольно долго все картинки в базе для всех магазинов. Да, да. Бинарные картинки. На скорость это не влияет. Поиск по ним не идет, только отдает по запросу файл с диска. А тут проще. Строка.

Неужели несколько десятков мегабайт( или даже сотен) это много?
Записан
passer
Живу я здесь
******

Репутация: +69/-3
Offline Offline

Пол: Мужской
Сообщений: 829



« Ответ #25 : 18.03.2016, 23:48:44 »

А кто говорит что большие БД это плохо. Это наоборот хорошо. Самое ценное на сайте это БД. Особенно если сайт коммерческий и доходный. Вопрос насколько она нормализована, сколько и каких запросов к ней идет. И делать умный поиск в CMS, да еще на php совсем не стоило.
Записан
robert
Профи
********

Репутация: +343/-11
Offline Offline

Пол: Мужской
Сообщений: 3567


« Ответ #26 : 18.03.2016, 23:56:30 »

А кто говорит что большие БД это плохо. Это наоборот хорошо.
В каком смысле? Зачем иметь дико растущую БД без выгоды взамен? Только потому что нынче можно на это не обращать внимания?
Записан
passer
Живу я здесь
******

Репутация: +69/-3
Offline Offline

Пол: Мужской
Сообщений: 829



« Ответ #27 : 19.03.2016, 00:02:47 »

В том смысле, что если у вас большая таблица товаров, значит широкий ассортимент, а если большая таблица юзеров, значит много покупателей в т.ч. постоянных. И это хорошо. Но если база пухнет от избыточности, (дублирования) данных это плохо.  Smiley
Записан
sm_denis
Завсегдатай
*****

Репутация: +35/-1
Offline Offline

Пол: Мужской
Сообщений: 441


Joomla-book.ru / JBZoo.ru


« Ответ #28 : 19.03.2016, 00:18:27 »

А кто говорит что большие БД это плохо. Это наоборот хорошо. Самое ценное на сайте это БД. Особенно если сайт коммерческий и доходный. Вопрос насколько она нормализована, сколько и каких запросов к ней идет. И делать умный поиск в CMS, да еще на php совсем не стоило.

Все верно, главное запросы и индексы. Но почему то сверху всех пугает именно размер и разбухание.
Пока не появились эксперты, рискну подвести промежуточный итог.
 - размер не влияет на скорость.это один из принципов бд. Скорость зависит от совершенно иных факторов. Не так давно по этому поводу был отличный перевод на хабре от маилру.

 - json не мешает поиску, потому что не принимает участия в нем.

 - не важно как хранит компонент свой контент, главное чтобы безопасно (без изменений)

 - русские буквы считаются спец символами потому что не входят в состав латиницы или чисел или первых 127 символов. Поэтому кодируются. Иначе будут проблемы на каждом втором сайте (видел их тысячи). Далеко не у всех правильно создана база.

- у кодировки нет понятия "язык". Это лишь порядковый номер символов.

- utf8 это 2 байта. Всегда. Поэтому json его трансформирует в безопасный вариант.

- не нужно править базу руками. Только через api. На любом проекте.

- индекс для поиска будет всегда и он всегда весит больше оригинала. И json это лишь мизерная часть. Посмотрите размеры таблиц. Умный поиск из коробки самый толстый. Если разберетесь как он работает, то поймете почему. Там хранится все примерно как внутри сфинкса (морфология, словари)

Мой вопрос до сих пор в силе. Почему хранить валидный json в базе это плохо? Про размер... это не аргумент)
Записан
effrit
Группа развития
*****

Репутация: +730/-7
Offline Offline

Пол: Мужской
Сообщений: 6795


effrit.com


« Ответ #29 : 19.03.2016, 00:29:36 »

ну на вопрос "а нормально ли хранить лишние байты" ответ получен )
сейчас интересно уже почему нельзя на zoo делать относительно крупные проекты )
если про это эксперты ответят, то можно будет тему закрепить с каким-нибудь жизнеутверждающим заголовком "101 развеянный миф про ужасность и прожорливость ZОО" )
Записан
Страниц: [1] 2  Все   Вверх
  Добавить закладку  |  Печать  
 
Перейти в:  

Powered by SMF 1.1.21 | SMF © 2006, Simple Machines

Joomlaforum.ru is not affiliated with or endorsed by the Joomla! Project or Open Source Matters.
The Joomla! name and logo is used under a limited license granted by Open Source Matters
the trademark holder in the United States and other countries.

LiveInternet