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

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


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

 Т.е. хренчегопрочтешьнапрямую...

Вопрос актуален, так как база данных растет как грибы 

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

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

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


http://php.net/manual/ru/json.constants.php

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

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

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

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

Ну, json - это тот же текст, только

хренчегопрочтешьнапрямую...

, зато никаких сюрпризов с utf8 не будет.
И ничего этого

надо раз в n дней скриптом шерстить по доп. полям и все в божеский вид перегонять?

не нужно делать.

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

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

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

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

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

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

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

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

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

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

Я про json, а не zoo. Да, zoo, IMHO, переусердствовал с json.

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

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

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

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

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

Я про json, а не zoo. Да, zoo, IMHO, переусердствовал с json.

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

Поиск идет по другим таблицам.
Почему переусердствовал?)

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

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

не советуют на больших проектах ZOO.

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

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

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

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

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

Поиск идет по другим таблицам.
Почему переусердствовал?)

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

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

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

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

Ну про экспертов это слишком. Куда нам.
Что касается больших проектов сие нам не ведомо. Ибо самые доходные оказались простые лендинги, вернее все что вокруг них накручено.
По сфинксу были несколько проектов. Ничего особо сложного нет. Файл конфигурации вроде этого
И оболочка php. Есть родной класс для работы с ним.
И ну да, свой индекс как видим. И не один.

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

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

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

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

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

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

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

А кто говорит что большие БД это плохо. Это наоборот хорошо.

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

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

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

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

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

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

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

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

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

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

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

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

ну на вопрос "а нормально ли хранить лишние байты" ответ получен )
сейчас интересно уже почему нельзя на zoo делать относительно крупные проекты )
если про это эксперты ответят, то можно будет тему закрепить с каким-нибудь жизнеутверждающим заголовком "101 развеянный миф про ужасность и прожорливость ZОО" )