• Начало

• Hare.ru @ дикое место
  • Лирика
  • Политика
  • Хай-тек
  • Синема
  • Лирика 2
• Hare.ru @ коллективный разум
  • Бухгалтерия и прочий учёт
  • Концептуальные работы
  • Полезные технологии
  • Собственные руки TM
• О проекте
• Информация
  • Реклама
  • Телеканал Россия 1 на компьютере

Собственные руки TM

Все статьи раздела

Можно ли сделать справочник резиновым?

Никита Зайцев (WildHare) (где-то в 2001)

Меня, конечно же, спросят: за каким чёртом может понадобиться изменение структуры данных в процессе работы с базой, да ещё и производимое без участия программиста? На самом деле такие задачи есть, и они не так уж редко встречаются. Например, представьте себе некий мощный классификатор, описывающий предметную область бизнес-процесса — скажем, сборки компьютеров, обработки результатов социологических опросов или страхования финансовых рисков. Что он из себя представляет? Правильно, сложный многоуровневый справочник. Состав классификатора разнороден, элементы разбиты на классы и подклассы, и каждый элемент характеризуется неким набором параметров.

Половина проблемы в том, что у разных элементов разные параметры. Параметр “экранное разрешение” имеет смысл для монитора, параметр “рабочая частота” применяется к процессорам и чипсетам, а если речь идет об игровом девайсе, нам небезраличны количество степеней свободы и наличие силовой обратной связи. Если попытаться хранить все значения всех параметров для всех элементов, то к нашему справочнику более всего подойдет определение “монструозный” (к сведению тех, кому это слово ласкает слух — на русский оно переводится как “громоздкий, неудобный и глючный” ;-). И в любом случае, некоторые ключевые параметры мы определить забудем, у других перепутаем типы, а потом с матюгами будем рихтовать конфигурацию на глазах у заказчика. Но это еще полбеды.

Вторая и главная половина проблемы заключается в том, что классификатор в процессе работы с ним пользователнй растёт не только вширь, но и вглубь. Предположим, завтра на рынке появится новый тип компьютерной железки, главным параметром которой будет количество ударов об стену, которые она выдержит прежде чем сломаться — и что же, нам нужно будет бросить все дела и в срочном порядке дописывать реквизит в справочник, выводить его в формы (куда он, конечно же, уже не влезет и всю форму придётся перекроить заново) и т.п., а потом обновлять базы данных своих заказчиков (ушлые разработчики на этом, конечно, хоть каких-то денег заработают, а честным и того не достанется). Пример с железкой, конечно, притянут за уши, но вот если страховая фирма впридачу к страхованию автомобиля от угона займется страхованием от разбития машины об фонарный столб (а это между прочим, принципиально разные вещи именно в плане хранимых данных), а у социологической фирмы появится принципиально новый тип опросного листа?

К чему я всё это веду. Есть некоторый класс задач, где жизненно необходимо передавать в руки пользователю не набор статичных окон с прописанными в них реквизитами, а гибкий инструмент управления сложным классификатором. Под пользователем здесь понимается пользователь в высшем смысле этого слова, т.е. понимающий разницу между перечислением и справочником и знающий, для чего служит комбинация Shift+Tab. Как показывает практика, среди пользователей серьёзной разработки хотя бы один такой обязательно найдется, а то и целых два.

Технически задача выглядит так: нам нужно в произвольный момент времени, не модифицируя md-файл, добавить в справочник один или несколько реквизитов, причём мы не можем заранее знать, какой тип должен быть у этих реквизитов. Поскольку это будет делаться с подачи пользователя, необходимо исключить ситуации нажатия Не Той Кнопки. Ну и вся остальная механика конфигурации должна быть достаточно умной, чтобы не впасть в ступор при виде возникшего на пустом месте нового объекта.

Один из путей решения заключается с создании нескольких подчинённых справочников с реквизитами неопределённого типа. Лично мне этот путь не нравится — придётся писать громоздкие управляющие процедуры, да и сам по себе механизм подчинённости не очень удобен (справочник может быть подчинён только справочнику определённого вида, но не “справочнику вообще”) и работает он не всегда надёжно.

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

В основе лежат два служебных справочника: Структура и Данные. Справочник структуры выглядит так:

Как несложно догадаться, в этом справочнике хранятся сведения об именах и типах реквизитов, принадлежащих тому или иному справочнику конфигурации, а отбор производится по реквизиту “Ключ”, в который записывается строковый идентификатор типа справочника-владельца.

Второй служебный справочник Данные, как следует из его названия, предназначен для хранения собственно реквизитов:

Два значения сделаны затем, что в реквизит неопределённого вида можно поместить строку не длинее 22 символов (readme с гордостью повествует об этой фиче, памятнику программерской криворукости и лени). В Ключ записывается ссылка на элемент справочника-владельца данного конкретного реквизита, а в Имя — идентификатор реквизита, взятый из справочника структуры.

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

В принципе, получилось бледное подобие SQL-таблицы— всё свалено в одну кучу, проиндексировано, и посредством пары простых запросов/отборов можно быстро и просто получить то, что нужно в данный момент. Искомая гибкость достигнута и, прошу заметить, исключительно штатными средствами V7. Если сюда подключить мощное расширение (я имею в виду DMS), то возможно будет задавать для создаваемых в процессе работы квази-реквизитов формулы, условия, сложные процедуры инициализации и т.п. вещи. Но об этом мы поговорим в следующий раз.

Разумеется, технология имеет спорные моменты:

• Объём служебных данных едва ли не превышает объем полезных данных. Но если использовать технологию для реализации небольших, но критически важных участков конфигурации (вроде упомянутого классификатора), то это вовсе не так страшно, как кажется.
• Программный доступ к реквизитам “резиновых” справочников заметно усложняется. Просто создать объект, что-то изменить и записать уже невозможно, придётся писать процедуры поиска, чтения и записи реквизитов. Правда, это нужно сделать один раз и делается это за полдня.
• Штатная процедура удаления объектов оказывается бессильной (каждый квази-реквизит система будет считать полноценным связанным объектом), поэтому её придётся заменить своим аналогом. Это тоже не смертельно.
• Необходимо очень тщательно продумать схему блокировок, разграничения прав доступа, механизмы отката, действующие при удалении существующих квази-реквизитов или при изменении их типа. Здесь всё зависит от конкретной задачи. Я вполне допускаю, что технология будет эффективна далеко не всегда.
• Наконец, фирма 1С, скорее всего, не даст сертификата совместимости конфигурации, если в ней будет использована описанная методика. Там не любят отклонений от генеральной линии ;-).

Партнеры: