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