Цитата:
Сообщение от
Marshak IX
Чертовски было интересно ознакомиться с предоставленным материалом, с которым полностью согласен. Огромное спасибо за введенный новый для меня термин "Нормализованное дерево", которое очень мне сейчас поможет.
Но считаю, что все изложенное верно с основного постулата, написанного в статье "Предполагается, что иерархия нужна для того, чтобы пользователь быстро искал информацию".
Но ведь это не единственное назначение иерархии. Привожу дополнительные назначения, которые вкратце были выссказаны другими участниками данного форума:
- Иерархия позволяет указать суммирование значений элементов
Примеры,
- Бухгалтерский план счетов, где в счете суммируется итоги по субсчетам
- Сруктура предприятия, где суммируется фонд оплаты труда, вакансии и занятые вакансии и т.п.
- Статьи затрат, где в группы статей суммируются элементы статей затрат
- и т.д.
- Упрощение ввода новых элементов
Не секрет, что в различные группы могут вводиться элементы с разными значениями реквизитов по умолчанию. У нас так вводятся различные группы готовой продукции, что существенно упрощает для пользователя ввод новых элементов, так как ему необходимо правильно выбрать группу иерархии и значительная часть реквизитов будет определена по умолчанию.
Сделаю некоторое отступление:
- Глубина иерархии
Обращу внимание, что при разработке не всегда известно какая глубина иерархии будет существовать при дальнейшей работе системы (месяц, год, десятилетие и т.д.), особенно со структурой предприятия и статьями затрат, которые могут измениться со временем.
- Пример реализации в САПе
Интересная реализация иерархии была сделана в САПе для структуры Мест возникновения затрат (МВЗ):
- Одновременно может существовать несколько структур иерархии одних и тех же элементов МВЗ
- Каждая структура иерархии МВЗ может быть изменена со временем, но остается известным какая структура была до момента изменения
- Чего не хватает в 1С
В 1С мне страшно не хватает одновременного использования иерархии и отбора элементов по фильтру. К сожалению, либо по дереву, либо по отбору элементов, а это позволило бы существенно упростить поиск в статьях затрат, плане счетов (когда план счетов существенно развернут) и т.д.
Что мне бы хотелось от функциональной возможности иерархии справочника:
- Одновременное использование нескольких иерархий одного справочника
Например, по разным характеристикам/реквизитам справочника, но так же несколько представлений по одной и той же характеристике,
- Возможность сохрание истории изменения иерархии
Не у всякого справочника необходимо сохранять историю, по этому эта возможность должна быть опциональна
- Возможность определения умолчаний по группе иерархии
- Возможность одновременого использования иерархии и фильтров
Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?
Алексей.
Если говорить об объектах системы, то что дает суммирование номенклатурных позиций в иерархическом справочнике?
Апологеты "иерархии" и "фильтрации" собственно спорят на счет только этого справочника.
План счетов, МВЗ и другие справочники, которые предназначены для хранения информации в денежном выражении потому и могут быть иерархичными, что денежный измеритель в Средние века был введен как универсальный эквивалент натуральных измерителей, чтобы можно было как-то суммировать имущество купцов, монастырей и феодалов.
Очень сложно представить, чтобы в плане счетов появился бы дублирующий счет, а вот в номенклатурном справочнике - запросто, если он иерархический, потому что взгляды на классификацию у тех, кто им оперирует могут быть разные.
То есть я бы все таки подумал о том, какой справочник, для чего он собственно, вместо того, чтобы подходиться к вопросу на уровне среды разработки.
И даже если программист напишет, а пользователь будет пользоваться иерархическим номенклатурным справочником, то стоит задуматься к чему это может привести? А собственно будет ли удобно работать другим пользователям? Как они будут бороться с дубликатами?