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

Не претендую на роль эксперта, тем более я всего лишь самоуверенный самоучка, но считаю, что вопрос не совсем корректно поставлен: никто не говорил, что хранить json в БД - плохо. Вопрос в том, зачем в json сохранять, когда он не нужен, еще и расплачиваться за это постоянным update отдельной для организации поиска таблицы и размером БД?

Вопрос в том, зачем в json сохранять, когда он не нужен, еще и расплачиваться за это постоянным update отдельной для организации поиска таблицы и размером БД?

Я задался вопросом выше. Как хранить что-то более сложное чем строку и искать по ней?
Почему вас смущает практика отдельного индекса? Эту практику используют все, начиная от индексов самого MySQL и коробочной cms, заканчивая внешними решениями.
Как только вам нужно будет искать по сложным структурам данных (чуть сложнее плоского массива) - потребуется их нормализация.
И как быть...
 - не хранить ничего, что сложнее строки?
 - не искать по сайту?
 - ваше решение без json и без доп таблиц? желательно пример, который можно посмотреть.

сейчас интересно уже почему нельзя на zoo делать относительно крупные проекты )

Выше я задавался вопросом, что такое крупный проект. Никто не ответил.

У нас есть на поддержке проект, где одновременный онлайн более 1000 человек - http://llfl.ru/mo1ndd
и держит порядка 200 тыс хитов и 50тыс хостов в сутки - http://llfl.ru/p1gk0t
Там десяток тысяч материалов. Это крупный проект в рамках типичных сайтов на Joomla?

Буду рад прочитать экспертное мнение, которое как-то подкреплено числами, измерениями.
Чтобы не получилось как в комментарии - http://joomlaportal.ru/blogs/extensions/2570-cck-joomla#comment-960

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

т.е. в каждом столбце:

тип хостинга и несколько его ключевых параметров.
кол-во посетителей сайта в день
кол-во полей у материала
количество материалов max, которое вы бы порекомендовали для данного тарифа.

я думаю, если такую таблицу с 6 (3-шаред и 3-выделенный), столбцами, закрепить на видном месте, это снимет много вопросов.
и у вас будет меньше работы с возражениями ).

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

Кстати, для проверки скорости у нас есть тесты, как в битриксе. Нормальный шаред за 2-3 евро вполне.
Хостинги меня не особо напрягают. Но не переводите тему, пожалуйста.

Вопрос все тот же.
Так почему индексные таблицы и валидный json в базе это плохо?
Почему это по вашему тормозит сайт? Почему вы считаете это лишними мегабайтами?

Смотрю типичный сайт с 11000 материалами. База весит 40мб. Это много?)))

sm_denis, вы невнимательно читаете )
я написал, что ответ на свой вопрос получил.
я вам предложил облегчить боль и страдания от подобных периодических вопросов.
просто получается так, что у ZOO - никакой саппорт, даже платный. поэтому на вопросы может ответить только местный спец.

Жаль, хотел конструктивно подискутировать... 
Буду ждать еще экспертных  мнений о базе и удобствам json.  как раз для нового компонента пилим схему и тесты, будет кстати.

Да чего тут обсуждать...
в JBzoo в целом нормально Денис многое переделал, чтоб нагрузку держало в оригинальном Zoo все несколько хуже. Но опять же при условии, что у вас нормально настроен хостинг, zoo просто необходимы акселераторы, Денис лучше по этому поводу ответит.
Из претензий я бы сказал что рендерится админка ужасно особенно когда много объектов, но это уже конструктивные особенности.

Что касается больших проектов, давайте определимся, что такое большой проект? Я могу точно сказать, что сейчас ни zoo ни сама Joomla не будет тормозить на сайте с 2000-5000 посетителей и 5000 тысячами материалов даже на шаред хостинге. Если тормозит, то что-то у вас сделано не так либо хостинг пипец, типа опенсервера виндового))))

На 50000-100000 посетителей в сутки вам уже все равно надо думать о сервере выделенном, а если у вас миллионами исчисляется народ, то там уже совсем другой разговор.

sm_denis, я как раз за, а не против json и об этом я говорил effrit чуть выше. Не нужно так остро реагировать на "IMHO,zoo переусердствовал с json" - в конце концов, это не такая уж большая беда. А чтобы предметно дискутировать, нужно быть пользователем zoo, кем я не являюсь.

Я делаю базу по отчетам, некоторые отчеты, которые весят например 104КБ, в файле  TXT. Этот же отчет в этой кодировке весит 248КБ. И при сохранение или правке выдает "502 Bad Gateway" Хотя если сохранять эту же информацию в стандартно в Joomla, то все нормально. Что делать?

И если Zoo тратит ресурсы на перевод из одной кодировки в другую и обратно, то зачем?

Влад, я так понимаю, совет будет - переехать на выделенный сервер ).
ну или попробовать увеличить лимиты памяти и время выполнения скрипта.
Или попробовать FLEXIcontent.

И если Zoo тратит ресурсы на перевод из одной кодировки в другую и обратно, то зачем?

Zoo всегда работает в одной и той же кодировке - UTF-8
В ней и только в ней работает вся Joomla. Нет таких мест где кодировка меняется в отличную от UTF-8.
Думаю, у вас что-то совершенно иное.

кстати, в связи с выходом 3.5 и конвертацией в UTF8MB4, я так понимаю, необходимость в доп кодировании символов отпадает?
иначе вообще будет сказочный рост БД.

Необходимость то может и отпадает, но кто ж сразу резко код то перепишет?

дык понятно. любители каталогов с текстовыми отчетами скорбят )

Если смайлы (emoji) не нужно хранить в базе, то нет большого смысла в UTF8MB4.
То что поддерживает 4 байтные кодировки для японского, не значит что обязательно использовать. Можно и дальше использовать utf8_general_ci

И так, есть ли хак, чтоб информация сохранялась в кирилице, а не json?