Работа с базой данных DLE: структура таблиц и связи

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

Как DLE раскладывает данные по таблицам

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

Главный принцип такой: DLE хранит сущность в основной таблице, а связанные данные — отдельно. Внутри движка связи обычно строятся по числовому идентификатору новости, пользователя или категории. При этом база может не содержать внешних ключей, которые автоматически запретят опасное удаление. Контроль целостности часто лежит на коде самого движка.

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

Ключевые таблицы DLE

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

Что находится в главной таблице новостей

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

Важный нюанс — дополнительные поля DLE часто хранятся не в отдельных нормализованных колонках, а в одном поле, например xfields. Внутри лежит сериализованная строка с парами «имя поля — значение». Её нельзя надёжно обрабатывать простым поиском по подстроке: значение может содержать разделители, HTML или одинаковый фрагмент в другом поле.

Если нужно массово изменить дополнительное поле, сначала найдите, как это поле сериализует именно ваша версия DLE. Без резервной копии ручная замена в xfields опасна: можно повредить сразу несколько полей у всех публикаций.

Как проверить структуру перед запросом

Для диагностики используйте phpMyAdmin, Adminer или консоль MySQL с учётной записью, у которой нет лишних прав на удаление. Запросы ниже предназначены для чтения и подходят для MySQL и MariaDB, которые обычно используются с DLE.

SHOW TABLES LIKE 'dle%';

SHOW CREATE TABLE `dle_post`;

SELECT
    TABLE_NAME,
    COLUMN_NAME,
    COLUMN_TYPE,
    IS_NULLABLE,
    COLUMN_KEY
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN ('dle_post', 'dle_category', 'dle_comments', 'dle_users')
ORDER BY TABLE_NAME, ORDINAL_POSITION;

Если префикс другой, замените имена таблиц в запросах. Результат SHOW CREATE TABLE важнее примера из документации: он показывает реальные типы, индексы и состав полей на вашем сервере.

Как читать связи между таблицами

Новости и категории

Категории лежат в dle_category, но связь с публикацией не всегда выглядит как отдельный числовой столбец. В DLE список категорий новости может храниться в поле основной записи. Поэтому перед JOIN нужно посмотреть тип и формат соответствующего поля, а не предполагать классическую связь «одна новость — один category_id».

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

Новости и авторы

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

Новости и комментарии

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

Почему прямое редактирование часто ломает сайт

• Изменение алиаса. Символьный URL может участвовать в кэше, ссылках, карте сайта и внешних публикациях. Новая строка в базе не создаёт автоматически редирект со старого адреса.
• Удаление пользователя. У публикаций могут остаться старые авторские значения, а служебные записи — потерять ожидаемого владельца.
• Замена текста через SQL. В тексте могут быть HTML, кавычки, кодировка и служебные разделители. Неправильное экранирование повреждает содержимое или открывает путь к SQL-инъекции.
• Изменение категории. Если обновить только строку в категории, но не учесть формат списка категорий в новости, публикация исчезнет из раздела.
• Очистка таблиц плагина. После удаления расширения его таблицы не всегда нужно трогать вручную: в них могут лежать настройки, журнал или данные, которые понадобятся при повторной установке.

Что проверять при диагностике

1. Определите версию DLE и сделайте полный бэкап базы вместе с файлами. Архив проверьте восстановлением на тестовом сервере.
2. Узнайте префикс таблиц по конфигурации и результату SHOW TABLES. Не подставляйте dle_ автоматически.
3. Найдите идентификатор проблемной новости и проверьте её строку в dle_post. Сравните статус публикации, дату, категории и символьный URL.
4. Проверьте связанные таблицы: комментарии, изображения, файлы, теги и данные установленных расширений.
5. Повторите запрос на копии базы и только после этого планируйте изменение на рабочем сайте.

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

Где структура DLE ломает привычный SQL

Главная граница — отсутствие гарантии, что все связи оформлены внешними ключами. Кроме того, часть данных хранится в составных строках: списки категорий, дополнительные поля, настройки модулей. Обычный JOIN по одному столбцу в таких местах либо не сработает, либо вернёт неполные результаты.

Вторая граница — плагины. Они могут добавлять таблицы, менять обработчики удаления и записывать данные в существующие поля. Запрос, который работал на чистой установке, не обязательно безопасен на сайте с форумом, магазином, SEO-модулем или собственными дополнениями.

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

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

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

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

¹ Сериализация — хранение нескольких логических значений внутри одной строки или поля. Такой формат экономит отдельные таблицы, но усложняет поиск, обновление и проверку целостности данных.