База данных в DLE: как делать правильно и без поломок

В DataLife Engine одна неосторожная правка таблицы может сломать публикации, комментарии или обновление ядра. Правильная работа с базой в DLE начинается не с SQL-запроса, а с определения границы: что можно настроить штатно, что вынести в собственную таблицу, а что нельзя менять без понимания схемы и механизма обновлений.

Сначала определите версию и точку изменения

Материал ориентирован на практику с DLE 17.x–18.x. Перед работой проверьте точную версию в панели администратора: названия разделов, структура отдельных таблиц и поведение дополнений между ветками могут отличаться.

До подключения к базе подготовьте:

• доступ к панели администратора DLE;
• доступ к панели хостинга или к инструменту управления MySQL/MariaDB;
• резервную копию файлов сайта и базы данных;
• описание задачи: какие данные нужно хранить, читать или изменять;
• копию сайта на тестовом домене или локальном сервере.

Уточните префикс таблиц. В новой установке он не обязан быть dle_: владелец сайта мог указать другой вариант. Поэтому название вроде dle_post нельзя без проверки переносить в запрос или расширение.

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

Три способа хранить данные в DLE

Одинаковая задача в DLE может решаться через настройки, собственную таблицу или изменение штатной схемы. Разница — в цене поддержки после обновления.

Если дополнение нельзя удалить без ручного восстановления таблиц ядра, оно слишком тесно связано с DLE.

Рабочие правила для схемы DLE

Не добавляйте колонки в таблицы ядра без необходимости

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

Для дополнительного значения у публикации сначала проверьте штатные поля и механизм, который предлагает ваша версия DLE. Если данные сложнее одного значения — например, у материала несколько записей истории, тегов внешней системы или статусов — вынесите их в отдельную таблицу. Связь храните через идентификатор материала, а не через заголовок или URL.

Не полагайтесь на имя таблицы

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

Разделяйте данные и логику

Запись в базу не должна происходить прямо из шаблона. Шаблон отвечает за вывод, а обработчик — за проверку входных данных, права пользователя, запись и обработку ошибок. Это особенно важно для форм комментариев, обратной связи и личных кабинетов.

Перед сохранением проверяйте тип и длину каждого значения. Идентификатор материала должен обрабатываться как число, дата — как дата, а текст нельзя склеивать с SQL-запросом. Для запросов используйте штатный слой работы с базой, доступный в вашей версии DLE и документации разработчика дополнения; не копируйте вызовы из старого модуля без проверки совместимости.

Как спроектировать собственную таблицу

Начните не с полей, а с операций. Запишите, какие действия должны выполняться: найти записи по материалу, показать последние события, изменить статус, удалить данные пользователя. Индексы проектируются под эти операции, а не добавляются «на всякий случай».

1. Опишите одну запись. Решите, что она означает и кто владеет данными. Если строка представляет событие, не смешивайте в ней текущий статус объекта.
2. Выберите идентификаторы. Для связи с материалом храните его числовой идентификатор. Не делайте URL единственным ключом: адрес может измениться.
3. Задайте обязательность полей. Отделите обязательные значения от необязательных. Для пустого значения выберите одно правило: NULL или заранее определённое значение, но не смесь обоих подходов.
4. Добавьте индексы под реальные запросы. Если записи выбираются по идентификатору материала и сортируются по дате, индекс должен соответствовать этому сценарию. Лишние индексы замедляют запись и увеличивают размер резервной копии.
5. Подготовьте удаление. Определите, что происходит с дополнительными строками после удаления материала или пользователя. Если автоматической связи с каскадным удалением нет, удаление должно выполнять само дополнение.

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

Резервная копия и обновления

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

Перед обновлением DLE сохраните:

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

Если дополнение создаёт собственные таблицы, его обновление должно быть повторяемым: сначала проверка версии схемы, затем последовательное изменение структуры. Ручные изменения в продакшене без журнала приводят к ситуации, когда неизвестно, какие колонки и индексы уже существуют.

Что ломается чаще всего

Данные есть, но DLE их не показывает

Проверьте префикс таблиц, идентификатор материала и условие выборки. Частая причина — поиск по URL вместо внутреннего идентификатора или обращение к таблице с префиксом из другой установки.

После обновления исчезли дополнительные поля

Сначала восстановите сайт на копии и сравните структуру базы до и после обновления. Не исправляйте проблему повторным добавлением колонок: сначала найдите, какое дополнение их создавало и поддерживает ли оно новую версию DLE.

Запросы работают медленно

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

Форма записывает дубликаты

Проверки в PHP недостаточно: два параллельных запроса могут пройти её одновременно. Для уникальных значений задайте ограничение на уровне базы, а в коде дополнения корректно обработайте отказ повторной записи.

Когда нужна отдельная база

Выносите данные за пределы основной базы DLE не ради моды, а когда у них другой жизненный цикл. Например, журнал событий может расти ежедневно, а каталогу сайта нужны быстрые запросы по материалам. В таком случае раздельное хранение упрощает очистку и нагрузочное планирование, но добавляет задержки сети, отдельные резервные копии и риск рассинхронизации.

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

Что сделать дальше

Создайте тестовую копию DLE и воспроизведите в ней один сценарий: создание материала, запись дополнительных данных, обновление, удаление и восстановление. Затем измерьте время запросов на странице до и после индексации. В продакшене наблюдайте за длительностью запросов, размером базы, числом ошибок записи и успешностью восстановления резервной копии — эти показатели полезнее абстрактного ощущения, что база «работает нормально».