$Id: SQLTools.txt 1280 2007-08-20 11:37:37Z cray $

Авторы: Андрей Орлов, Егор Шершнев.

Продукт разработан при участии Арвида Пэаглита и других сотрудников компаний Key Solutions & IIG.

Про SQLTools:

SQLTools - это набор продуктов, облегчающий использование SQL на сайтах, функционирующих на платформе Zope3. Все продукты, входящие в набор, основаны на стандартных средствах (коннекторах к базам данных, Z SQL Method, Catalog и др.) и могут быть легко использованы с любыми реляционными базами данных, для которых в Zope3 существует коннектор.

Идея, лежащая в основе SQLTools, проста: реляционные и объектные базы данных имеют очевидные, но различные преимущества, поэтому прозрачное смешение реляционных данных и объектов позволяет получить существенный выигрыш в решении различных задач. Фактически, в типовом решении, интенсивно использующем SQLTools, часть объектов хранится в виде реляционных данных, часть - в ZODB, а некоторые объекты используют смешанное хранение (например, контент - в ZODB, индексы - в RDBMS.

Основная задача, решаемая набором SQLTools - это реляционно-объектное отображение, которое осуществляется посредством двух основных инструментов:

SQLIndex

продукт, позволяющий сохранять индексы объектов, индексируемых через Zope3 Catalog, в произвольных таблицах реляционной базы данных;

simplesqlui

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

Остальные инструменты набора (SQLObject, SQLVocabulary, zcmljunction) имеют вспомогательный характер и предназначены для реализации полей интерфейсов, получения списка объектов и т.п.

Расскажем подробнее об SQLIndex и simplesqlui.

SQLIndex:

SQLIndex

это разновидность индекса для Zope3Catalog. Как и в случае обычного индекса, его применение требует привести объект к определенному интерфейсу. От одиночной индексации атрибутов пришлось отказаться из-за требований эфективнной работы с реляционными базами, вследствие чего SQLIndex индексирует весь интерфейс целиком. Тривиальное отображение класс-таблица не представляет большого практического интереса, а выделение и индексация сложных отношений между объектами требует одновременного учета нескольких атрибутов.

В процессе работы, индекс обрабатывает различные события жизненного цикла объекта (создание, редактирование, удаление, перемещение), что приводит к выполнению соответствующих операций над реляционной базой данной, которые реализуются методами, написанными на SQLMethod.

ПРИМЕР:

Теги объектов. Каждый индексируемый объект может иметь ноль или более тегов так, чтобы объекты можно было искать по тегам, вести статистику тегов и выполнять аналогичные операции. Вместо наивного подхода, состоящего в том, чтобы завести таблицу, соответствующую объекту и в ней атрибут, хранящий все теги объекта (некоторые RDBMS предоставляют специальные типы, позволяющие сделать это), можно завести таблицу объектов (содержит только идентификатор и поле уникального object_id) и таблицу тегов, на которую ссылаются строки таблицы объектов. Каждый тег имеет счетчик доступа, а пара триггеров управляет созданием и очисткой тегов.

Преимущества:

• Экономится место в RDBMS;
• Статистика считается непосредственно при хранении, а не вычисляется при каждом обращении;
• Модель данных в RDBMS отличается от модели данных в ZODB и оптимизирована под требуемые операции.

Из приведенного приимера ясно, что одним из основных преимуществ продукта SQLIndex является возможность создания альтернативной модели данных при индексации.

Очевидное использование SQLIndex - это подготовка данных для быстрого поиска и сортировки объектов, что достигается не только обращением через поисковый Zope3 Catalog, но и прямым обращением к базе данных с помощью инструментов набора SQLObject и SQLVocabulary:

SQLObject

позволяет получать списки объектов, удовлетворяющие произвольно-сложным запросам к RDBMS (которые невозможно получить, оставаясь в рамках парадигмы Zope3 Catalog);

SQLVocabulary

позволяет получить списки возможных значений атрибутов из числа реально использованных в объектах, и впоследствии использовать их в схемах форм объектов (например, можно в поле из примера с тегами поставить словарь, позволяющий выбрать теги из числа существующих);

simplesqlui:

simplesqlui - это продукт, позволяющий отобразить произвольную реляционную базу на иерархию объектов, доступных в Zope. Для создания такой иерархии используются следующие правила:

1. Каждый объект соответствует записи, полученной запросом к реляционной базе данных (он может включать данные из одной или более таблиц);
2. Каждый объект является контейнером;
3. Содержимое контейнера - это записи, получаемые посредством связи содержимого другого запроса с записью, соответствующей контейнеру.

Отметим особенность такого подхода: любая база данных может быть отображена на любую иерархию объектов. Более того, иерархия объектов для базы данных может быть не единственной. Фактически, иерархия объектов - это один из способов взглянуть на базу данных, удобный, например, для определенной категории пользователей.

Zope объекты, получаемые с помощью simplesqlui, мало отличимы от обычных: их можно прозрачно редактировать, они обладают произвольными интерфейсами, на которые можно накладывать произвольные виды, они доступны через стандартные скины (такие как rotterdam). Объекты можно удалять, переименовывать и копировать между контейнерами (если это позволяют ограничения модели реляционных данных). Cпециально для редактирования контейнера simplesqlui, был создан вид, позволяющий задать форму поиска в контейнере, снабженный пейджингом и другими возможностями.

Общее заключение:

Совокупность продуктов SQLTools позволяет выполнить полный цикл отображения данных, хранимых в ZODB, в данные, хранимые в RDMS, и обратно, причем без каких-либо ограничений на модели хранения данных. Фактически, любые объекты сохраняются в базе RDBMS любой структуры, из которой восстанавливается удобная иерархия объектов.

Это является существенным отличием от того, что предоставляется такими системами как Django или Ruby On Rails. В simplesqlui реляционная база данных - это полноценный инструмент для хранения и анализа отношений между объектами, тогда как в других системах реляционная база данных - это всего лишь способ хранить объекты. Таким образом, работу с объектами и данными, реализованную в Django и Ruby On Rails следует признать неудачной по определению, поскольку хранить объекты должна объектная база, а реляционную базу лучше использовать как один из инструментов исследования отношений между объектами, что совершено не реализовано в указанных выше системах, но полностью представлено в SQLTools.

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

История и текущий статус:

• 2000 год -- первая реализация идеи иерархического реляционного отображения, сделанная на основе perl;
• 2002 год -- реализация идеи иерархического реляционного отображения, сделанная на основе Zope2;
• 2003 год -- ZCatalog, основанный на RDBMS, сделанный на основе Zope2;
• 2004 год -- реализация идеи иерархического реляционного отображения, обычно используемая в Plone;
• 2005 год -- продукт NavigatorGear, реализующий идею иерархического реляционного отображения. В Zope3x, продукт был реализован, но работы над ним были заморожены из-за отсутствия возможности внедрения в реальных Zope3 проектах;
• 2007 год -- продукт simplesqlui, быстрая реализация идеи иерархического реляционного отображения в Zope3. Создана в учебных целях из-за необходимости быстро устранить оставание от сроков при разработке крупного промышленного проекта, требующего совместного использования RDBMS и ZOPE.

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

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

На сегодняшний день основным продуктом считается NavigatorGear, так как он обладает наименее противоречивой реализацией иерархического реляционного отображения, хотя он и не используется ни в одном проекте и не является работоспособным в текущей версии Zope. Рабочий продукт simplesqlui - это полноценное решение, хотя и имеющее существенные упрощения по сравнению с NavigatorGear.

В будущем планируется, используя опыт, накопленный в simplesqlui, привести NavigatorGear в рабочее состояние, сохранив совместимость с simplessqlui, а также выпустить все компоненты SQLTools под свободной лицензией.