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