Цитата:
Потому увидел предлагаемый пример "Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые"
В этой иерархии признак "Для наружных работ" является межвидовым. Этот признак скорее всего будет повторяться в других группах.
Поэтому я и написал ниже "(*То что я сейчас говорю является своеобразным "правилом нормализации" для древовидных классификаторов. Правило это как {и любое} правило {,как правило,} не может быть соблюдено в полно объеме - *)".
Тут действительно трудно обойтись без обозначенных вами коллизий. Давайте присмотримся к ним повнимательнее:
Цитата:
Лакокрасочная продукция / Эмали / Эмали для наружних работ
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Лаки / Лаки для наружних работ
Действительно (так и есть) у нас внедренный в классификатор признак "для наружних" работ присущ почти всей ветке "Лакокрасочной продукции". Казалось бы типичная денормализация, но ведь мы ничего (почти) с ней не можем поделать, ибо кроме этой ветки этот признак нигде больше не будет встречаться, следовательно выносить его в отдельное поле таблицы "ForOuterWork" - нерационально и ненужно для 99% остального справочника, следовательно эту ситуацию разрешить разбиением на отдельные поля и фильтрацией по ним - тоже затруднительно. Возможен вариант с выведением таких свойств из классификатора и введением некоторого строкового поля таблицы ExtraDescription, который будет заполнятся совершенно разными значениями в зависимости от того в какой ветке он будет находится. Мне такой вариант не нравится и имхо лучше иметь на 10% "ненормализованное дерево" (термин то состряпан мной еще вчера, так что не судите строго). Вообще в литературе такие ситуации ("ООП таблицы") предлагается делать специальным образом, но он тут неуместен и только безмерно усложнит ситуацию. Хотя.... кто знает... Тут еще имеет смысл посмотреть на всё глазами предполагаемых пользователей - а важен ли вообще этот момент для них? Например у нас есть разбиение групп ванн на подгруппы "чугунные", "стальные", "акриловые" - тоже так и просится сделать вместо этого разбиения у таблицы поле "материал", но опять же - не всем строкам таблицы это поле нужно, не у всех оно совпадает по возможному набору значений, да и по большому счёту пользователям это поле (сейчас) не нужно - это разбиение последнего уровня и дополнено чем то оно не может быть. Да и возьмём абстрактный пример "иерархического оглавления в книге" - хотя в каждом разделе первым подразделом всегда может быть раздел "Введение", это не является денормализацией - пользователю никогда не нужно получать из книги только введения.
На самом деле путешествуя по нашему дереву я нахожу более "страшные" моменты, когда лаки разбиты на "...внешние работы" и "...внутренние работы", а на уровне ниже каждая из этих веток разбита на "Водные" и "Полимерные". Вот это уже серьезный недочет, но согласитесь - хорошего, универасльного решения нет ни в "древовидном", ни в "плоском" подходе нет.
Цитата:
Да, прежде всего отделить формат хранения и формат представления.
Что еще?
Делать дерево.
На самом деле я просто обратил внимание что читая вашу статью у читателя может возникнуть ощущение что любое дерево заведомо можно описать другими средствами - расчленяя его на группу несвязанных полей. И не сказано что на самом деле действительно существуют заковыристые внутриклассовые иерархии, которые ну никак нельзя уложить в СУРБД иначе чем древовидным подходом.
Действительно реализовавывать деревья в СУРБД - плохой тон. Действительно в аксапте нет встроенной поддержки древовидности.
Действительно нужно 10 раз подумать прежде чем нагружать SQL-сервер сериями из сотен рекурсивных запросов, НО
Желание клиента слишком часто действительно является законом.
Правильная древовидность может действительно помогать и упрощать решение многих задач.
На самом деле в аксапте и так есть куча мест где постоянно происходит КУЧА рекурсивных и не очень запросов, так что ответ на вопрос о том стоит ли оно того падение производительности не столь очевиден.
Цитата:
Для нормализованного дерева действует только одно правило "Нормализованное дерево - это дерево построенное исключительно в рамках одного свойства объекта"? Может есть другие правила?
Как я уже говорил термин рожден меньше 24 часов назад, так что...
Правило как раз не только одно - главное правило в "нормализованном" дереве является то, что у потомков узла не должно быть повторяющихся подпотомков на любых уровнях вложенности, а всё остальное - следствие из этого правила. Причём словосочетание "повторяющиеся подпотомки" не надо воспринимать категорично - как я уже показывал с примером книжного оглавления - здравый смысл должен решать является ли появление на первый взгляд одинаковых узлов в разных местах классификатора повторением или нет.
Цитата:
Бывает ли несколько степеней нормализованности деревьев?
Наверное да. По хорошему над этим должны думать современные создатели СУБД.