Несколько раз слышал об этой статье, слышал много мнений, все (не большинство) не лестные (возможно потому, что кручусь именно в кругу специалистов Лотуса). Но вот добрался до оригинала только сейчас, только через год(!). Понимаю, что как специалиста, меня это характеризирует не с лучшей стороны, но факт остается, так вышло. Сначала думал просто прочесть: итак много обсуждено, наговорено, статья-опровержение вон даже есть (к стати, ее еще мне предстоит прочесть, т.е. сейчас будет только мое мнение, незапятнанное противовесом). Но теперь решил и свое замечание оставить. Я полностью согласен...>>>>
Спасибо Андрею за поптыку объективного разбора. На самом деле он полностью (за исключением уже замеченных и впоследствие исправленных фактических ошибок) подтверждает мои впечатления.
Как о позиционировании системы, так и об ее ограничениях.
Он еще раз демонстрирует, что Лотусисты не понимают, зачем нужны транзакции и ссылочная целостность. И тем самым хорошо характеризует область применимости системы.
Пока модель данных задачи у нас укладывается в ситуацию, что 1 содержательная сущность = 1 документ LN (или Domino, как вроде правильно говорить), и технологиченские операции у нас такие, что одна операция меняет один документ, то все хорошо, и LN дает фору любым реляционным СУБД.
Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо, и чем дальше. тем хуже...
Говорят, кстати, что в 6-ке наконец сделали честные транзакции.>>>>
Вы знаете Андрей, меня всегда несколько удивляли люди, делающие умный вид , скрывая свои мировые знания. Ну разве Вы были удовлетворены, когда Вам писали, что Ваша статья просто туфта? Никак не аргументируя, не проводя никаких паралелей? Фраза 'Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо' - является необоснованной. Дайте какое-то обоснование, пожалуйста, пример. А я Вам тогда расскажу, как все хорошо на самом деле можно построить. Пример: транзакции в описанном Вами виде. Принимаем за истину, что транзакции это автоматическое изменение ...>>>>
Транзакция - это согласованное изменение некоторого множества данных, облажающее таким свойством, что оно либо выполняется до конца, либо от него не остается никаких следов.
В Лотусе изменение одного документа (записи) - транзакционно. Оно либо происходит, либо нет. Но согласованное изменение нескольких документов оформить как транзакцию нельзя (по крайней мере так было).
И если выполняемая технологическая операция требует, чтобы согласованным образом изменились несколько документов, то здесь возникают проблемы.
Поэтому системы на Лотусе стараются строить таким образом, чтобы таких ситуаций было поменьше, и транзакции сводились, по возможности к модификации единичных документов. И пока это получается - все хорошо.
Но вот вам классический реляционный пример - фрагмент какдровой системы. Имеются подразделения, сотрудники, и факты занятия определенным сотрудником определенных должностей в определенных подразделениях на полную/частичную ставку с некоторым окладом. Да, и возможно совмещение, естественно...
Причем смотреть на это нужно как в разрезе сотрудников (где он сейчас работает на каих должностях и с каким окладом), так и в разрезе подразделений. А так же переводить людей из одного подразделения в другое, менять должность и оклады и др.?
Давайте попробуем разобраться с этим конкретным примером. Я уверен, что при его "честной" реализации вы получите ту же самую, или большую, трудоемкость, чем на реляционных СУБД, и менее эффективную и надежную работу - чисто за счет архитектурных особенностей.
Если вы сумеете меня переубедить - отлично, вам зачтется...>>>>
Во первЫх строках спасибо за мирное отношение, для меня это важно. Во вторых, я теперь немного по другому понял, почему Вы считаете систему Домино не способной на подобный подвиг :). Попробую описать, как бы я сам решал подобную задачу. Для начала один момент: я не являюсь специалистом никакой другой технологии (к собственному стыду) кроме Домино, по этому могу не знать о каких-то общепринятых понятиях или названиях, я буду оперировать терминами Домино. Итак, мы создаем форму карточки сотрудника с необходимыми нам пунктами: Организация, Подразделение, ФИО, Должность, Ставка, Notes Name. По необходимости список можно продолжить (например, индекс должности для корректной сортировки сотрудников в таблице «штат»). Форма в Домино это приблизительно такая же маска документа, как вид - маска базы. В форме Вы создаете поля, с которыми должен будет взаимодействовать пользователь при работе с документом, и располагаете их в нужном порядке и виде. Пользователь может создать новый документ для заполнения именно по какой-то форме. Но поля в документе к самой форме никак не привязаны: они могут быть созданы программно, перейти из другой формы, добавлены кодом. Форма к документу также привязана весьма условно и не является составной частью документа (правда, есть одно исключение). Она есть элемент дизайна базы, как и вид. Т.е., один документ может быть открыт по разным формам, или одна форма может быть совершенно разной в разных базах. В случае, если Вы открываете документ на редактирование не по той форме, по которой он был создан, при сохранении документ дополнится новыми полями, которых в нем раньше не было. Но поля, отсутствующие в данной форме, из него не исчезнут, просто пользователь не получит к ним доступ. Это же справедливо и для случая, когда Вы просто удаляете поле из формы. Таким образом, создается видимость работы с совершенно разными записями (например: личная карточка сотрудника и штатная единица организации) в то время, как работа осуществляется с одним и тем же документом. Возвращаемся к нашей форме. Я бы сделал поля «Организация» и «ФИО» обычными текстовыми; поле «Notes Name» именным с выбором значения из адресной книги (пригодится для общения с владельцем карточки); поля «Подразделение» и «Должность» - DialogBox с возможностью ввода значения, отсутствующего в списке; и «Ставка» - числовое с подтипом - денежное. Все эти поля редактируемые. Тип DialogBox напоминает гибрид 'Combobox' и 'Radiobutton' (хотя они 'чистые' также присутствуют в Домино). ДиалогБокс при нажатии на его активный элемент открывает свой список в собственном окошке. Выбор может быть как сингл, так и малти, определяется при программировании. Список может формироваться по разному: забит статически, вызывать для выбора служебные функции Домино (список контроля доступа, адресная книга), может быть привязан к конкретному виду с указанием колонки возвратного значения, или просто запрограммирован кодом. К стати, В Вашей статье нет пары основных базовых языков программирования Домино, которые как раз здесь и применяются: @-formulas & @-commands. Поля в Домино могут иметь атрибут «редактируемое», «вычисляемое», «вычисляемое для показа» и «вычисляемое при создании». Редактируемые - пользователю подвластно менять значение. Вычисляемое выглядит как статическая запись на странице: есть имя, тип, значение, но никаких внешних признаков поля нет; пересчитывается по своей формуле каждый раз при обновлении экрана. Вычисляемое для показа - аналогично предыдущему во всем кроме того, что предназначено лишь для вывода на экран какой-то информации, и в документе не сохраняется. Вычисляемое при создании - в документе хранится, но высчитывается только при своем появлении, в дальнейшем никакие обновления на него не действуют. Программно конечно можно получить доступ и изменить любое поле. Дальше. Принимаем поле «Подразделение» за опорное. Его формула: @Unique(@DbColumn(...)) в вид «Подразделения». Возвращает список всех имеющихся отделов (вложенность отделов не ограничена; DbColumn возвращает массив значений определенной колонки указанного вида). Вид «Подразделения» содержит документы, созданные по данной форме, и категоризирован по полю «Подразделения». Таким образом, мы имеем механизм создания штата организации «на лету». При заполнении карточки сотрудника, отдела которого еще не существует, мы введем его вручную непосредственно в карточке (отпадает необходимость предварительно заходить в раздел «Штат» и заводить там новый отдел и новую штатную единицу, как было бы в реляционной базе, с последующим возвратом к карточке сотрудника и выборе его места). Если отдел уже имеется (в базе есть хоть один сотрудник этого отдела), мы выберем это подразделение из списка в соответствующем поле (так же, как в реляционной базе). Теперь должность. Почти аналогично, его формула будет @Unique(@DbLookup(...)). Отличие от Колумна в том, что возвращаются значения, соответствующие заданному ключу. В качестве ключа используем поле «Подразделение». Если требуемой должности нет, точно также вводим ее вручную прямо в карточке, и в следующее поле (Ставка) забиваем сумму. Если должность уже использовалась, просто выбираем ее из списка у данного поля, а ставка заполнится автоматически, т.к. поле «Ставка» при заполнении должности будет пересчитываться, а формула для вычисления будет @Unique(@DbLookup(...)), где ключом будет уже должность. Еще стоит добавить, что для каждого из этих Лукапов будет создан свой скрытый вид, содержащий документы, созданные по данной форме и отсортированные по значению требуемого ключа. К слову, также создаются нерушимые ссылки: при удалении объекта Лукап его не найдет, и соответственно, ссылка не организуется. При перемещении объекта Лукап найдет его текущее положение и ссылка приведет куда надо. Это базовые функции нашей записи в базе. Еще небольшое дополнение: Внизу формы создаем секцию 'История работы'. Секция - это аналог категории вида, только для обычной страницы. Т.е., имеется как-то озаглавленный треугольничек, имеющий свойство при клике разворачиваться. При его развороте страница увеличивается, дополняясь содержимым секции. В секции создаем таблицу с четырьмя колонками: 'порядковый номер', 'дата/время', 'ФИО редактора', 'действие'. Перед сохранением ставим скрипт, который добавляет запись в данную таблицу. Регистрируемых в этой таблице действий может быть уйма: изменение названия организации или ФИО сотрудника, перемещение из подразделения в.., перевод на должность, и т.п. Отмечу, что «перед сохранением» это системное событие, коих для формы предусмотрено довольно много (как и для других элементов дизайна). Я не знаю, где есть аналогичное дробление, как например «перед открытием документа» и «после открытия документа», «перед обновлением» и «после...», «перед закрытием», «перед сохранением», «после», «перед отправкой» и «после», «перед изменением режима» и «после». Изменение режима - подразумевается переход между режимами редактирования и просмотра документа (когда никакие редактируемые поля для изменения не доступны), хорошо используется для разграничения доступа. Для изменения названий подразделений, должностей и ставок в событии «перед сохранением» будем использовать скриптовый метод StampAll, который применяется к коллекции документов. Это, видимо, и есть примитивный аналог транзакции, позволяющий создать любой транзакционный механизм. Его суть - изменение значения одного поля у всех документов одной коллекции одновременно. Для исключения дополнительных пересудов дополню, что если в долю секунды выполнения этой команды вырубится машина, операция завершена не будет, и новое значение не появится ни в одном документе. А поскольку код будет стоять в событии «ПЕРЕД сохранением», то и в текущем документе, где поле было изменено пользователем, изменения также не останутся. Если сбой произойдет после выполнения stampall, но до сохранения текущего документа, измененное значение в текущем документе останется, т.к. данный документ также будет присутствовать в коллекции, обработанной с помощью stampall. Метод не новый. И осталось последнее: аналоги реляционных таблиц - виды. Создаем столько видов, сколько нам нужно. «Штат» имеет первую категоризированную колонку, показывающую отделы. Остальные колонки опционно: ФИО, должность, ставка... В свернутом состоянии вид будет демонстрировать чистую структуру предприятия в виде привычного «дерева», вложенность структуры, как я говорил, не ограничена. А если мы еще добавим колонку для суммы, то в этом дереве при каждом названии отдела будет стоять цифра, означающая кол-во сотрудников в отделе. В развернутом виде (когда все категории вида открыты) вид будет демонстрировать полноценный штат организации. «Сотрудники» - вид, содержащий эти же документы, но отсортированные по Фамилиям в алфавитном порядке. «Должности» - первая категоризированная колонка содержит должности сотрудников в алфавитном порядке; удобно для нахождения, кто занимает конкретную должность, для контроля, сколько сотрудников назначено на должность. «Подразделения» - аналогично, перечень подразделений не в соответствии со структурой, а в алфавитном порядке. «Перемещения» - содержит сотрудников, в карточках которых в секции «История» имеются записи перемещения с - на. Ну, и т. д. Любой вид, который потребуется для удобства, можно легко добавить, и он сразу будет наполнен необходимой информацией. Состав любого вида также легко меняется/пополняется. Дополнительно следует реализовать Архив, что обеспечит нерушимость штата при переходах и увольнениях, и его наличие, по-моему, обязательно для отдела кадров. Плюс, можно также дополнить базу формами приказов назначений/перемещений/увольнений. Итого: мы имеем базу, в которой создать ошибочную ситуацию практически невозможно, которая будет реплицироваться в мгновение ока (скажем, десяток новых или измененных/перемещенных сотрудников при хреновом диал-апе будут пролазить около полуминуты), которая будет выполнять все функции реляционной базы (в том числе транзакционные), но которая, при этом, будет несколько проще в эксплуатации (ибо исключает пару шагов для пользователя, необходимых при работе с реляционной базой), и которая будет довольно гибкой и легко изменяемой/дополняемой. На разработку подобного «шедевра» у меня уйдет день-два. Плюс, столько же для внесения поправок, которые обязательно наберутся в первую неделю эксплуатации. Еще замечание: обработку типичных ошибок ввода я опускал, но она подразумевается. Данная задача является типичной для полного делопроизводства, ее различных решений на Домино есть великое множество у различных компаний-разработчиков. Даже есть вариант под вэб. Что правда, несколько попроще, чем Вы описали, и на стадии доработки (в моем исполнении, не сочтите за рекламу). work.lotus-ua.com. для просмотра без регистрации нажать ссылку «сюда» и зайти на регистрацию новой организации. С уважением, Андрей Горобчишин. P.s. С Вашего позволения, я добавлю Вашу статью в соответствующий раздел на сайте lotus.net.ua. Если не возражаете, конечно.
Обсуждение (всего 6 реплик, последняя - 13.01.2003 13:27)Настройка
У нас наблюдается явный прогресс, признаю. 1) Я решил задачу, которую Вы поставили, а не ту, которая подразумевалась. При решении любой задачи я стараюсь создать наипростейшее решение, которое будет и самым надежным. Но отступать от задания не в моей манере. Хотите усложнить задачу - я согласен. Только дайте точное описание того, что должно быть реализовано (не как). Иначе Вы снова на что-нибудь скажете, что это должно было быть, как само собой разумеещееся, а я упрощаю. Действительно, я придерживаюсь точки зрения, что Домино - система полнофункциональная. Еще раз повторю, что приведенно...>>>>
1) Я не выбрал единственно верный вариант. Я вам просто указываю на некоторые жизненные реалии - например, что подразделение сначала создается приказом, а потом уже туда нанимают сотрудников.
И что у подразделения (а тем более - у организации) есть свои СОБСТВЕННЫЕ атрибуты (полное/краткое название, код, начальник, телефоны, email, номер приказа о создании, и еще много чего), которые в вашей схеме хранения засунуть некуда, разве что дублировать их в каждом сотруднике, и что сотрудник может совмещать несколько должностей в разных подразделениях...
Приблизительно такой реакции я и опасался. Система естественно влияет, но не столько на мышление, сколько на реализацию задач в ней. В данном случае я вижу, что Вы выбрали для себя единственно верный вариант решения и никакие отклонения не возможны. 'Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.' - не совсем так: я реализую их как единое целое, а вот отображаться они будут по привычному, как вещи отдельные, самостоятельные. Можете мне нарисовать реалию, в которой в организации будет существовать подразделение без сотрудников? Штатная единица согласен...>>>>
Вот я примерно об этом и говорил. Используемая система влияет на стиль мышления. Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.
Вы ведь не забывайте, что Подразделения - это самостоятельная сущность. У них есть свои атрибуты и иерархия. Кроме того, могут быть свежесозданные подразделения, где нет еще ни одного сотрудника.
Кроме того, Должности тоже могут жить без сотрудника. Есть такое понятие - Штатное расписание.>>>>