MasterZiv
Cat2 пишет:

> Может меняться. Если уровень вложенности конечен и известен, то проще
> использовать связи один-ко-многим
Это вообще-то и есть связь один-ко-многим. Один родитель, много детей.


Видимо не "один-ко-многим". Если количество вложений ограничено, можно использовать не только связь вида "свиное ухо", или как там его ещё называют... "рыбий хвост", т.е. когда внешний и первичный ключи находятся в одной таблице. Вариантов становится значительно больше.
Можно для каждого яруса создать отдельную таблицу. Такой подход оправдан, если ярусы дерева имеют разный тип, или есть желание декларативно ограничить число ярусов.
Можно использовать хитрый ключ, типа "id яруса 1,id яруса 2,...". Тогда будет очень просто писать иерархические запросы используя только SQL базового уровня.
И т.д.

Иногда нереляционные древовидные структуры пытаются тупо переносить в реляционную БД, при этом моделируемый объект оказывается разбитым на множество записей, которые сами по себе лишены бизнес смысла. Например, что такое имя файла без полного пути? Понятно, что в файловой системе операционной системы удобно иметь иерархию вложенных папок, но в реляционной БД более осмысленным будет хранение полного имени файла (хотя бы для того, чтобы обновления и поиски нормально работали).

MasterZiv

Имя файла в дирректории. А что такое полный путь к файлу ?


Полный путь - строка по которой можно однозначно идентифицировать файл в файловой системе.

MasterZiv

Сегодня он один, завтра - другой.



Прекрасно. Завтра делаем Update и всё в порядке.

MasterZiv
Вообще в современных
файловых системах путей к файлу вообще много. И, кстати,
имён тоже.


Бывает и такое. Только при чём тут деревья? Тут просто нужно отделять имя файла от его содержимого.

MasterZiv
А вот размер поля вы под полный путь какой зададите ? В файловой системе по идее путь может быть бесконечно длинным --
он не ограничен.


varchar2(256). Вы не поверите, но длина пути к файлу всё же ограничена. Как бы строковые буферы в системе для хранения полного имени имеют ограниченный размер.

MasterZiv

И уже не говорю о том, что если нам нужно обрабатывать
отдельные каталоги полного пути, это будет нарушение 1НФ.



Где же тут нарушение? Никакого нарушения тут нету. Есть файл или каталог, есть его полное имя. Два атрибута записи.
Конечно, операция переименования каталога не сводится к update одной записи. Нужно будет сделать update всех записей, которые относятся к этому каталогу. К стати тут автоматически будет выполняться проверка того, что в этом каталоге нет открытых файлов, что в иерархической структуре сделать не так просто.
Если обновить не все записи каталога, могут остаться файлы в старом каталоге, и появятся записи в новом каталоге, возможно это будет нарушением правил целостности с точки зрения обычной иерархической файловой системы, но кто говорил, что транзакции должны быть простые, а ограничения целостности исключительно декларативные!?

Nafandreych,
я же написал "условно это". Я и сам использую денормализацию время от времени. Потому что места лишнего не жалко, а жалко времени выполнения. как говорится "либо много храним лишнего, либо долго считаем". Но в денормализации есть другая более опасная проблема. Источников данных получается несколько. В данном случае уровень можно вычислить, а можно получить из поля - 2 источника. и если какой то нерадивый (забывчивый) разработчик забудет синхронизировать эти источники, то получим большую проблему.

Прикольно будет, когда в дереве образуется петля...

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

С введением сурогатных ключей классическое понятие нормализации отношения БД потеряло свой смысл. Мы можем произвольным образом взять набор атрибутов, прицепить к ним суррогатный ключ и сказать, что это новое отношение БД. Как выбрать эти атрибуты - дело вкуса и здравого смысла. Вы не докажете, что именно такое отношение однозначно правильное.
Дерево можно описывать маршрутами от корня к ветке или листу. Все маршруты с одинаковым корнем образуют дерево. Это удобно в том плане, что в одной записи сосредоточены все ключевые данные, чтобы простым запросом получить данные для любого яруса на маршруте. Легко исключить петли. Но высота таких деревьев ограничена.

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