заранее хочу решить этот вопрос и выбрать более верное решениеПредварительная (ака преждевременная) оптимизация вредна, по очевидным профи причинам. Для новичков это становится идеей фикс - как бы не сделать плохо, и сразу оптимально. Что приводит к размазыванию задачи вокруг возможных решений, вместо реализации ЛЮБОГО рабочего решения, в рамках задачи. И вот если тесты показывают что есть проблемы с производительностью, тогда думать как решить проблему. В 99% случаев все работает настолько хорошо, что любые оптимизации либо дадут мизерный прирост (вышеупомянутая экономия на спичках), либо только сделают хуже. Все современные инструменты разработки и исполнения ПО уже оптимизированы под типовые задачи, в кои безусловно и очевидно входит и поиск по слагу...
а проблему производительности решают при помощи модулей кеширования и тем самым снижают нагрузку на сервере.какую проблему производительности? У вас есть проблемы с производительностью? Вы уже все протестировали и сделали вывод что без кеширования тормозит?
найти человека, который согласится написать корзину и личный кабинет на JS для WP практически нереально или слишком дорого,Нет, или я выразился не верно, или вы поняли не так. На том же апворке ОЧЕНЬ много разработчиков под вордпресс, другой вопрос что среди них есть как толпа индусов, так и приличный пласт вполне адекватных разработчиков. Хотя бы исходя из того что вордпресс ОЧЕНЬ распространен. Стоит описать нормально требуемый функционал, и как минимум закинуть запрос на пару фриланс сайтов. А уже дальше исходя из предлагаемых бюджетов и количества откликов решать что делать.
Смотришь лог ошибок, так как вряд ли что-то "не работает" просто так.
блоки не будут зависеть от html, изменил компонент - изменился вывод всех зависимых элементов. с обычным html так не выйдет - в бд уже будет храниться строгий html, соответственно для изменений придется вносить изменения в КАЖДЫЙ пост (и речь не о стилях, а о разметке)Пример плс, а то что-то я не догоняю, как может поменяться "компонент" настолько, что поможет только его переписывание??? И чем поможет в этом случае ббкод?
Отдельные элементы одинаковые, соответственно можно использовать компоненты для того чтобы избежать дублирования кода.И какие элементы у вас тут одинаковые? И где вы увидели дублирование кода???
Другое дело что структура контента разная, получается что каждая контент часть поста уникальна по расположении отдельных элементов - обычной вьюшка не дает возможностей.То есть для какого-то блока у вас будет допустим выравнивание вправо, и вы будете создавать элемент с типом алигн_райт, прописывать его в новом ббкоде, а потом заменять его регулярками на элемент с классом алигн_райт? Не кажется проще сразу задать разметку с нужным стилем? Все современные wysiwyg редакторы поддерживают такое форматирование в один клик.
И тут либо bb коды, либо использовать совершенную другую логику.Вы как-то странно позиционируете ббкоды, как будто они сильно превосходят нативную стилизацию через хтмл... Как раз ббкоды - костыли, призванные сильно ограничить пользователей в кастомизации визуала контента, в статьях же вам скорее нужно использовать всю мощь современного хтмл/цсс.
Для ББ кода - это еще один код, вставленный в текст. Для html появится желание обойтись без дополнительного парсинга исходников и вставить кнопку как есть, со стилями и скриптом, или хотя бы с классами.Открою мааааленький секрет: Практически все тексты обрабатываются перед выводом. Некоторые для той же вставки рекламы, некоторые для обработки какого-то функционала, который никак кроме обработки метаинформации по другому не вставишь, некоторые именно для парсинга чего-то типа ббкодов(например если это непремодерированные данные от пользователей). Просто если данные введены из надежного источника и содержит готовый отформатированный хтмл, обработка становится в разы проще, например не нужны регулярки на каждый чих, можно просто найти нужный тег и заменить его на что-то другое стр_реплейсом... По этому никто не будет соблазняться вставкой кнопки в текст.
насчет лишних выборок тоже понимаю.Проблема не в лишних выборках, а в структуре, которая на сегодняшний день считается классически малооптимизируемой.
если речь о порядке, то разные посты могут содержать разное количество тех же самых заголовков (именно заголовки части контента, подзаголовки, подпункты, etc), которые могут находиться в произвольных местах. естественное дело, учитывать структуру необходимо.То есть "заголовки" не будут плавать и прочие блоки не будут плавать внутри контента выше-ниже, а просто будут иметь другой вид? Условно у вас есть название статьи, главная картинка, шорт дескрипшн, и неизменный текст статьи, элементы внутри которого просто стилизованы по разному? Не находите что проще задать им 8 тегов и забыть про какие-то там разбиения? Тем более что и семантически это положительно отразится на контенте, и краткость по сравнению с вашими шорттегами не ухудшится (например что вы там насокращаете в тегах
<h1>,<h2>,<h3>?.. Ну или сократите <span> до [sp]?..).видел также пост на хабре, где человек ровным счетом также хранил html код, перешел на подход похожий на второй, количество хранимой информации уменьшилось в 4 раза (имхо, разница отличная).Во первых накладные расходы на создание дополнительных записей и индексов сожрет сильно больше места, во вторых уверен что подход был похожий, но не такой, и в третьих - возможно что хтмл у товарища занимал СИЛЬНО больше места чем требовалось для обычного поста, то есть это были скорее всего совершенно другие данные. В вашем случае я привел экономию, если у вас тегов ОЧЕНЬ много, возможно вы выгадаете НЕМНОГО больше места чем описано у меня(вам все равно придется как-то обозначать все теги которые вы меняете, и это не сократит ВЕСЬ текст в 4 раза никак), но СИЛЬНО потеряете в производительности.
С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive. Ну если пересчитать удельно сколько стоит гигабайт.Это относится только к собственным серверам, и с натяжкой к арендным мощностям. На "готовых" хостингах например вы платите фикс прайс, не зависимо от использования/неиспользования бд. Ну и тут в целом речь не про "дешевле ли в файлах", а про "хранить какую-то часть данных в бд или генерировать ее программно", что совсем не одно и то же.