Заключение

Архангельский Андрей

       Описанные в книге примеры показывают, что даже с использованием простейших инструментов Delphi (TreeView) и стандартного языка SQL расширенного хранимыми процедурами можно сделать очень много.
       Расширения языка SQL, в которых делается попытка каким-то образом упростить работу с древовидными структурами, решают частные (узкие) задачи, которые при всей их полезности, не могут охватить все варианты использования древовидных структур.
       С другой стороны, понимание структуры отношений Parent-Child, позволяет строить удобные справочники, даже не вспоминая об специальных компонентах для древовидных структур.
       При использовании готовых компонентов, отображающих простейшую древовидную структуру напрямую из таблицы появляется соблазн подстроить структуру базы данных к интерфейсу пользователя. Это неправильно. На самом деле структура БД и интерфейс пользователя мало связаны друг с другом. Структура БД определяется данными и их структурой. Интерфейс пользователя определяется запросами к этой БД — нужно оформить входные и выходные данные.
       Если же использовать стандартные компоненты для построения древовидных структур, то у программиста появляется широкая свобода действий, которая позволяет строить любой пользовательский интерфейс независимо от структуры таблиц. Работа с древовидными структурами не ограничивается поиском дочерних узлов. Даже в простых древовидных структурах, кроме отображения в интерфейсе пользователя, требуется большое количество вспомогательных операций:
       — изменение структуры из интерфейса пользователя;
       — суммирование зависящих от структуры элементов по уровням, что предъявляет новые требования для программиста и разработчика классификации;
       — построение и заполнение древовидной структуры из SQL-скрипта и, как следствие, сохранение структуры в SQL-скрипте. При этом необходимо учитаыватьмасштабируемость структуры — когда часть одной структуры сохраняется в SQL-скрипте и переносится в другую как ее часть.
       Все вышеописанные операции многократно усложняются при построении нескольких деревьев в одной или двух таблицах. Нет однозначного правила использования одной или двух таблиц — все зависит конкретного проекта. Однако, как только забрезжит возможность неопределенного количества деревьев, то структура на двух таблицах обладает большей гибкостью и возможностями.
       И, наконец, на двух таблицах можно строить очень сложные конструкции как это показано на примере программы подготовки комплексов VAZKompl или транспортных задач на произвольных графах.
       Несколько особняком стоит проблема, о которой математики всегда забывают. Древовидные структуры как правило используют для отображения и поиска в соответствии с какой-либо классификацией — ТН ВЭД, УДК или других. Разработку классификации выполняет некоторый государственный или регулирующий орган, сотрудники которого не имет представления о базах данных. В результате чего в классификациях присутствует значительное количество ошибок, препятствующих построению этой классификации в базе данных. В то же время программист не имеет полномочий (прав) на какую-либо коррекцию (исправление) этих ошибок. Таким образом, любую классификацию необходимо тестировать на возможность ее применения в базах данных.

© 01.08.2009, Архангельский А.Г.

<<Пред. Оглавление
Об Авторе
Все персоны
Главная страница
След.>>



Поддержите культуру
ЯндексЯндекс. ДеньгиХочу такую же кнопку

Google
 
Web azdesign.ru az-libr.ru


Дата последнего изменения:
Wednesday, 23-Oct-2013 09:03:00 UTC