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