20 марта в 11:27
Есть тип материала, в котором планируется порядка 20 файловых полей. И 20 текстовых. Итого 40 таблиц будет создано в БД + еще 40 для ревизий. Ужас же, не? Столько таблиц для одного типа материала состоящего из кучи одинаковых полей... Может существуют способы как-то иначе организовать хранение в БД? Или ревизии хотя бы отключить? Полностью, чтобы и таблицы не создавались.
Комментарии
Ревизии в типе материала можно отключить.
Заменить 20 файловых и текстовых полей может и возможно (черз paragraphs, или еще как-то), но это врядли разгузит БД. Главное, проектировать так, чтобы контентщику и вам было удобно работать.
Ну а в чём конкретно ужас-то?
Чем больше таблиц в запросе, тем запрос медленнее работает. Да и сама база раздута, много места занимает. Всего-то один тип материала, а 40 таблиц. А если таких типов 10, 20? А есди не 20 полей, а 50? Уже 100 таблиц будет создано...
Да, на небольших сайтах с небольшой посещаемостью это скорее всего и незаметно будет. Но в целом, если о тенденции говорить...
Если нужны поисковые фильтры - можно Search API для облегчения нагрузки на БД использовать. Сама БД от этого конечно же меньше не станет.
Если только вывод информации - голову не морочьте.
Это что ж за запрос такой, которому нужны абсолютно все поля всех записей?
Отображение ноды. Вывод значений всех 20 полей. Системе нужно дернуть все 20 таблиц. А может и 40, не знаю, может она что-то проверяет с ревизиями связанное. Чем меньше таблиц, тем быстрее всё работает.
Отключены изначально, при создании типа материала. Но это, похоже, не работает. И таблицы в БД все равно создаются, да и сам функционал ревизий никуда не исчезает. Есть вкладка "Редакции" при отображении ноды и есть чекбокс "Создать новую редакцию" при ее редактировании. Так что, совершенно неясно, что собственно делает снятие галки с "Создать новую редакцию" при редактировании типа материала.