Хранение дерева в базе данных

[baldr]

Хочу посоветоваться по тому как правильно хранить данные в базе..
Есть несколько групп конфигурационных файлов разных типов - INI, XML и т.п.
Файлов довольно много - 3-4 файла на каждом из 100 серверов.
Данные в них могут незначительно меняться, скажем, несколько раз в день.
Проверка на изменение производится с удаленного сервера раз в 5 минут.
Нужно хранить данные из этих файлов, причем с возможностью быстро вытащить какое-то значение.
На мой взгляд логично представить их в виде дерева нодами в виде записей nodeid-parentid-nodename-nodetype-nodevalue.
Это позволит хранить как атрибуты, так и ветви.
Но встает следующий вопрос - обновление.
Допустим, у нас хранится в базе такое дерево - мы его распарсили и уже сохранили.
Теперь мы имеем новый файл и знаем что в нем "что-то" поменялось - необходимо удалить старые ноды и добавить новые.
Как правильнее поступить - убить все дерево и создать новое, либо искать по всему дереву и удалять/вставлять только изменения?
В первом случае мы делаем только "delete from nodes where " по какому-либо простому условию и затем серия insert.
Во втором случае мы бегаем по всему дереву, выполняя кучу select и сравнений, а затем delete/insert.
Что более накладно для базы?
Или есть какой-то более правильный способ?

[baldr]

Забыл указать - размеры файлов - 10-40 Кб

[Dale]

Что более накладно для базы?

Забыл указать - размеры файлов - 10-40 Кб

При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных.

Или есть какой-то более правильный способ?

Самый правильный способ - реализовать максимально просто и оптимизировать лишь при необходимости, когда это действительно нужно.

[baldr]

При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных.

Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами.
400*100=40000 записей для 100 серверов.
Еще есть XML с более сложной структурой (навскидку около 700 строк - минимум пара тысяч нод на файл).

Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново.
Но как-то это не очень красиво что ли..

[Sla]

тю... то ж немного

какой server  SQL?

для mysql можно посмотреть в сторону
http://dev.mysql.com/doc/refman/4.1/en/insert.html
INSERT ... ON DUPLICATE KEY UPDATE

или

http://dev.mysql.com/doc/refman/4.1/en/replace.html

[Kivals]

baldr, да - но задача будет распаралелена на 100 серверов, так что по сути загрузка минимальная. Ну а если ты обновление сделаешь не с одного сервера, а построишь сбалансированное дерево серверов - то все они вообще будут отдыхать
Я бы добавил к ноде время последнего обновления (заполняется автоматом: триггером on update).
Соответственно - выборка всех нод, у которых время изменения выше времени последнего обновления.

[Dale]

Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами.
400*100=40000 записей для 100 серверов.

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

Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново.
Но как-то это не очень красиво что ли..

Красив код, который прост и понятен. Если работает медленно - будем думать, как ускорить. Но это явно не тот случай.

[baldr]

Ок, всем спасибо, попробую тупо пересоздавать дерево - посмотрим что получится.

[Dimka]

За лимит времени в 5 минут даже на умеренно старой рабочей станции СУБД будет способна перелопатить порядка миллиона записей (если оперировать запросами, а не курсором). Тут масштаб на два порядка меньше, поэтому способ реализации - абсолютно любой, всё равной выйдет с изрядным запасом. Присоединяюсь к мнению, что в таких условиях лучше писать, как удобнее программисту.

[HandKot]

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

ИМХО здесь ключевой момент
если мы знаем то, что изменилось, тогда проще найти и заменить
если мы не знаем, то, что изменилось тогда  получаем парсинг файла по-любому, в этом случае проще убить все дерево и заново его прописать

скорость суля здесь уже не важна, так как пойдет парсинг файла

[Dimka]

HandKot, твоё предложение обходит сторой важный вопрос: насколько часто эти данные из базы нужны читателям. Убить дерево, и начать его создавать заново - это создать период времени, когда их в базе нету, в который кто-то может захотеть прочитать эти данные оттуда. И либо этот кто-то прочитает неполные данные, либо СУБД придётся нагрузить довольно тяжёлой (на 40 тыс. записей) транзакцией, суть которой сводится к тому, что СУБД сначала "в сторонке" сформирует новую базу, а потом быстренько перезапишет имеющуюся, заблокировав читателей на время перезаписи.

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

[HandKot]

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

[baldr]

Решил реализовать полное сравнение деревьев и замену только изменившегося участка. Старая часть не удаляется, а верхняя изменившаяся нода помечается - получается заодно хранение истории изменений..
Что-то получилось, но еще не тестировал..

[Dimka]

HandKot, хоть целиком, хоть часть, хоть одну запись - всё едино. Вероятность ошибки чтения снижается, но достигает 0 только в том случае, когда так не делают.

[HandKot]

ну уж лучше пользователь в блокировке повисит, чем получит "левые" данные и будет уверен, что они верны
хотя все зависит от задачи:
- и отчет строить без заблокированных записей
- и отчет строить на данных не завершенной транзакции
- и отчет строить на данных до обновления