Несколько раз слышал об этой статье, слышал много мнений, все (не большинство) не лестные (возможно потому, что кручусь именно в кругу специалистов Лотуса). Но вот добрался до оригинала только сейчас, только через год(!). Понимаю, что как специалиста, меня это характеризирует не с лучшей стороны, но факт остается, так вышло. Сначала думал просто прочесть: итак много обсуждено, наговорено, статья-опровержение вон даже есть (к стати, ее еще мне предстоит прочесть, т.е. сейчас будет только мое мнение, незапятнанное противовесом). Но теперь решил и свое замечание оставить. Я полностью согласен...>>>>
Спасибо Андрею за поптыку объективного разбора. На самом деле он полностью (за исключением уже замеченных и впоследствие исправленных фактических ошибок) подтверждает мои впечатления.
Как о позиционировании системы, так и об ее ограничениях.
Он еще раз демонстрирует, что Лотусисты не понимают, зачем нужны транзакции и ссылочная целостность. И тем самым хорошо характеризует область применимости системы.
Пока модель данных задачи у нас укладывается в ситуацию, что 1 содержательная сущность = 1 документ LN (или Domino, как вроде правильно говорить), и технологиченские операции у нас такие, что одна операция меняет один документ, то все хорошо, и LN дает фору любым реляционным СУБД.
Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо, и чем дальше. тем хуже...
Говорят, кстати, что в 6-ке наконец сделали честные транзакции.>>>>
Вы знаете Андрей, меня всегда несколько удивляли люди, делающие умный вид , скрывая свои мировые знания. Ну разве Вы были удовлетворены, когда Вам писали, что Ваша статья просто туфта? Никак не аргументируя, не проводя никаких паралелей? Фраза 'Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо' - является необоснованной. Дайте какое-то обоснование, пожалуйста, пример. А я Вам тогда расскажу, как все хорошо на самом деле можно построить. Пример: транзакции в описанном Вами виде. Принимаем за истину, что транзакции это автоматическое изменение ...>>>>
Транзакция - это согласованное изменение некоторого множества данных, облажающее таким свойством, что оно либо выполняется до конца, либо от него не остается никаких следов.
В Лотусе изменение одного документа (записи) - транзакционно. Оно либо происходит, либо нет. Но согласованное изменение нескольких документов оформить как транзакцию нельзя (по крайней мере так было).
И если выполняемая технологическая операция требует, чтобы согласованным образом изменились несколько документов, то здесь возникают проблемы.
Поэтому системы на Лотусе стараются строить таким образом, чтобы таких ситуаций было поменьше, и транзакции сводились, по возможности к модификации единичных документов. И пока это получается - все хорошо.
Но вот вам классический реляционный пример - фрагмент какдровой системы. Имеются подразделения, сотрудники, и факты занятия определенным сотрудником определенных должностей в определенных подразделениях на полную/частичную ставку с некоторым окладом. Да, и возможно совмещение, естественно...
Причем смотреть на это нужно как в разрезе сотрудников (где он сейчас работает на каих должностях и с каким окладом), так и в разрезе подразделений. А так же переводить людей из одного подразделения в другое, менять должность и оклады и др.?
Давайте попробуем разобраться с этим конкретным примером. Я уверен, что при его "честной" реализации вы получите ту же самую, или большую, трудоемкость, чем на реляционных СУБД, и менее эффективную и надежную работу - чисто за счет архитектурных особенностей.
Если вы сумеете меня переубедить - отлично, вам зачтется...>>>>
Во первЫх строках спасибо за мирное отношение, для меня это важно. Во вторых, я теперь немного по другому понял, почему Вы считаете систему Домино не способной на подобный подвиг :). Попробую описать, как бы я сам решал подобную задачу. Для начала один момент: я не являюсь специалистом никакой другой технологии (к собственному стыду) кроме Домино, по этому могу не знать о каких-то общепринятых понятиях или названиях, я буду оперировать терминами Домино. Итак, мы создаем форму карточки сотрудника с необходимыми нам пунктами: Организация, Подразделение, ФИО, Должность, Ставка, Notes...>>>>
Вот я примерно об этом и говорил. Используемая система влияет на стиль мышления. Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.
Вы ведь не забывайте, что Подразделения - это самостоятельная сущность. У них есть свои атрибуты и иерархия. Кроме того, могут быть свежесозданные подразделения, где нет еще ни одного сотрудника.
Кроме того, Должности тоже могут жить без сотрудника. Есть такое понятие - Штатное расписание.>>>>
Приблизительно такой реакции я и опасался. Система естественно влияет, но не столько на мышление, сколько на реализацию задач в ней. В данном случае я вижу, что Вы выбрали для себя единственно верный вариант решения и никакие отклонения не возможны. 'Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.' - не совсем так: я реализую их как единое целое, а вот отображаться они будут по привычному, как вещи отдельные, самостоятельные. Можете мне нарисовать реалию, в которой в организации будет существовать подразделение без сотрудников? Штатная единица согласен...>>>>
1) Я не выбрал единственно верный вариант. Я вам просто указываю на некоторые жизненные реалии - например, что подразделение сначала создается приказом, а потом уже туда нанимают сотрудников.
И что у подразделения (а тем более - у организации) есть свои СОБСТВЕННЫЕ атрибуты (полное/краткое название, код, начальник, телефоны, email, номер приказа о создании, и еще много чего), которые в вашей схеме хранения засунуть некуда, разве что дублировать их в каждом сотруднике, и что сотрудник может совмещать несколько должностей в разных подразделениях...
У нас наблюдается явный прогресс, признаю. 1) Я решил задачу, которую Вы поставили, а не ту, которая подразумевалась. При решении любой задачи я стараюсь создать наипростейшее решение, которое будет и самым надежным. Но отступать от задания не в моей манере. Хотите усложнить задачу - я согласен. Только дайте точное описание того, что должно быть реализовано (не как). Иначе Вы снова на что-нибудь скажете, что это должно было быть, как само собой разумеещееся, а я упрощаю. Действительно, я придерживаюсь точки зрения, что Домино - система полнофункциональная. Еще раз повторю, что приведенное мной решение есть ответ на Вашу постановку задачи: это не попытка упростить отдел кадров делопроизводства, устроенный по ГОСТам. Я даже могу Вас уверить, что Ваша информация по поводу тотального упрощения Доминошных систем делопроизводства неверна. Мне досконально известно устройство ОК системы "Босс:Референт" от АйТи и системы "InTeam" от ПУЛ. Первая упрощена - она исходила не из канонов советского делопроизводства, а из реальной необходимости некоторых заказчиков. А вот вторая соответствует максимальным требованиям и является кандидатом на учебное пособие для Международного Университета Менеджмента Украины. И ее ПУЛ каждый раз упрощает индивидуально для каждого покупателя. В таком объеме ни ОК ни делопроизвводство вообще не используется нигде. Еще добавлю, что пять лет назад изучал делопроизводство около года (подготовка для написания одного из вариантов "упрощенной" автоматизации) и могу сказать, что ГОСТов на делопроизводство не существует. Есть масса материалов по этой теме, но разняться они очень серьезно. Есть попытка создания ГОСТа электронного документооборота (в который мое решение вписалось почти на сто процентов). Есть, конечно, узловые моменты. Но вот например, набор атрибутов отделов не стандартизирован, приказы также сильно разняться. По этому и прошу составить описание системы в таком виде, в каком лично Вы хотите ее увидеть. Для того, чтобы потом Вы конкретно могли указать пункт (или функцию), которую Вы заявили, а я опустил в своем решении. Для лучшего качества могу предложить Вам установить у себя клиентскую часть. Тогда я смогу набросать рабочий локальный образец, который Вы сможете потрогать реально. Возможно тогда станут более понятны те вещи, о которых я пытаюсь сказать (я не педагог, понимаю, что не обладаю достаточным красноречием для подобной задачи. например, мне кажется, я не смог объяснить так, чтоб Вы смогли представить подразделение, работающее как самостоятельная запись в то время, как внутри системы такой отдельной записи не существует). 2) Согласен абсолютно. Привел пример лишь для того, чтоб показать, что ошибки возможны везде. По поводу финансовых систем: да, LN признан повсеместно тормозом в данной сфере. Почему - имею мнение: решение подобных задач на Домино также нецелесообразно, как документооборот на SQL. Есть системы специализированные, Домино не расчитан на конкретику. Это не значит, что она ему не подвласна, это означает, что другая среда с ней справляется лучше. 3) вот тут не могу согласиться. Это заблуждение. Домино расчитан на полную, любую автоматизацию, не малую. И подходит для этой цели гораздо больше любой другой системы/среды (имеется в виду именно комплексная автоматизация). Системы на Домино весьма гибки и живучи. Они живут годами, переходят из релиза в релиз и меняются вместе с потребностями. Для этого просто нужен нормальный хозяин, как и для любой вещи. То, что указано наоборот, справедливо и для Домино. Лучший тому пример: продукт "eSales" (бывшая Overquota) от компании Relavis. 4) благодарю.
Обсуждение (всего 2 реплики, последняя - 13.01.2003 13:27)Настройка