Наши недостатки есть продолжение наших достоинств. Народная мудрость...
...
Практически все специалисты по информационным технологиям слышали о Lotus Notes (LN), но относительно немногие имели с ним дело на практике. В следствие этого по Лотусу имеется катастрофический дефицит объективной информации. Вся доступные публикации об этом продукте имеют вид рекламных проспектов или фрагментов технических описаний.
Там, где нет объективной информации - она замещается мифами. Сейчас в России Lotus продвигается в основном как система организации корпоративного документооборота, хотя на самом деле это не совсем так. Мнения об этом продукте полярны - одни преподносят его как панацею от всех болезней корпоративной автоматизации, другие и слышать о нем не хотят.
В то же время реальная значимость Lotus Notes для корпоративного рынка чрезвычайно велика. Многие крупные российские копании стоят сейчас на пороге выбора корпоративной информационной среды, и Lotus - один из основных претендентов на это. Поэтому мне показалось важным рассказать - что такое LN на самом деле, какие проблемы он решает, а какие - создает.
Я давно вынашивал эту идею, почитывая описания и расспрашивая знакомых. Окончательным толчком для меня стало знакомство с бывшим начальником IT очень крупного банка, поведавшего о некоторых особенностях эксплуатации LN, с которыми ему пришлось столкнуться.
Немного истории
Компания Лотус была пионером во многих направлениях софтверного бизнеса. Сейчас это многие не помнят, но в самом начале 90-тых "Lotus 1-2-3" был синонимом электронной таблицы - достойных конкурентов у него просто не было... Почтовая программа "CC-mail" оставалась лучшей корпоративной почтовой системой до середины 90-тых.
Аналогов выпущенного в конце 80-тых LN вообще не существовало - для него пришлось придумать отдельный термин - "GroopWare" (обеспечение коллективной работы). Это была первая и долгое время единственная система, реально позволяющая обеспечить быстрое создание единого информационного пространства компании и системы корпоративных коммуникаций.
Триумфальное шествие LN продолжалось почти десять лет, и основными его пользователями являлись крупные и средние корпорации. Не удивительно, что интерес к компании Лотус проявила IBM, традиционно обслуживающая Top1000 мирового бизнеса, и в конце концов таки купила эту компанию на корню. Так что ныне Лотус - это подразделение IBM, сохранившее некоторую самостоятельность, и торговую марку "Lotus".
Сейчас, впрочем, от всей линейки продуктов Лотус на рынке реально остался только Lotus Notes - остальные офисные приложения практически умерли, не выдержав конкуренции с Microsoft office. А Lotus Notes не просто остался, но активно продвигается - по крайней мере, на российском рынке.
Lotus Notes - что это такое?
Говоря простыми словами, LN - это такой гибрид СУБД и почтовой системы, обладающий рядом интересных особенностей. Имеется также ряд возможностей для организации структурированной коммуникации - форумы, календари и др.
Главной особенностью лотусовской базы данных является ее ориентация на хранение больших плохо структурированных документов и коллективную работу с ними. Под коллективной работой подразумевается возможность нескольким человекам одновременно править одну и ту же запись (документ). Соответственно, поддерживается аппарат версий и возможности отслеживания изменений, сделанных отдельными пользователями. Кроме текстов, записи лотусовских БД могут содержать произвольное количество настраиваемых пользователями реквизитов разных типов. Причем настройка состава реквизитов достаточно проста и посильна конечным пользователям. Документы в базе могут ссылаться друг на друга (что-то типа вебовских гипертекстовых ссылок), и кликнув на ссылку в тексте документа, можно открыть другой документ.
В LN реализована изощренная система управления правами пользователей, позволяющая назначать права отдельным пользователям и их группам как на базы данных, так и на документы и их отдельные поля. Также поддерживается аутентификация документов с помощью электронной подписи - т.е. при помещении в базу созданный или модифицированный документ может подписываться подписью сотрудника, который с ним работал.
Почтовая программа и прочие приложения (форумы, календарное планирование и др.) надстроены над этой самой системой хранения документов. Адресные книги, папки с письмами, календари и др. также являются записями в БД, и на них распространяются все общие механизмы - версии, поддержка коллективной работы и др.
Еще одним базовым механизмом, впервые реализованный именно в Lotus Notes, является репликация - т.е. возможность серверов LN синхронизировать свои базы, пересылаю друг другу документы в свободное от основной работы время. Таким образом обеспечивается возможность работы в территориально распределенной среде при медленных каналах связи, когда каждый сотрудник работает со своим ближайшим сервером (т.е. быстро), а, скажем, по ночам эти сервера синхронизируют свои базы.
Естественно, предусмотрена возможность разработок специализированных приложений в среде LN. Для этой цели в систему встроен язык программирования (Lotus script), открывающий доступ к API системы, и позволяющий создавать достаточно сложные приложения. Можно также разпрабатывать приложания для Lotus на более традиционных Java & JavaScript, к кторомы также имеются библиотеки объектов для работы с Lotus-овским API,
Обратная сторона медали
Лотус - чрезвычайно функциональная система с элегантной архитектурой, реально позволяющей создать общую информационную среду в большой компании, имеющей много офисов в разных городах и странах. И в этом качестве он почти десять лет практически не имел конкурентов. За это время он обрел заслуженную популярность - по официальным данным им пользуются порядка 700 компаний из Top1000 мирового бизнеса.
Но времена меняются... И в сегодня то, что вчера было достоинствами, сегодня зачастую становится недостатками вызывающими изрядную головную боль у пользователей и служб сопровождения.
Lotus Notes - функционально замкнутая система, предоставляющая пользователю все необходимые ему средства работы - текстовый редактор, почтовую программу, электронную таблицу, систему календарного планирования и др. И пока пользователь пользуется для этих целей Lotus-овскими приложениями, все очень удобно и хорошо.
Но сегодня значительная часть пользователей предпочитает использовать офисные приложения других фирм - например, Microsoft, которые стали сегодня стандартом де-факто. В Lotus-овском хранилище документов можно хранить "чужие" файлы, но, как только мы начинаем использовать MS Word совместно с Lotus, тут же выясняется, что половина всех прелестей, которые были при работе со встроенным редактором LN, теряется.
Зато добавляются проблемы - специальные процедуры экспорта-импорта. Или скажем, невозможность открыть вложенный в письмо файл одним кликом - его нужно экспортировать на диск, и там уже открывать. И вообще - почтовая программа LN по своей эргономичности оставляет желать лучшего. Мои знакомые, "простые пользователи" перешедшие на работу в "Никойл" (LN - там корпоративный стандарт), уже три года с тоской вспоминают простой и удобный в обращении Outlook...
А почтовая программа - это вам не текстовый редактор, это сердце LN, и без нее полноценно эксплуатировать Lotus Notes не получается.
Еще одна особенность, показавшая свою оборотную сторону - это репликация в сочетании с общей требовательностью к ресурсам. Упоминавшийся мной начальник IT-департамента крупного банка, в котором было больше 2000 рабочих мест на LotusNotes вспоминал, как у них репликация между крутыми серверами по выделенному оптоволокну шла часами (а это означает, что люди часами не могли получить отправленные им на визирование срочные документы, так как лотусовская почта между пользователями разных серверов "ходит" также через репликацию).
А необходимость во множестве серверов возникала из-за того, что одиночные сервера не справлялись с нагрузкой. А с нагрузкой они не справлялись из-за того, что в силу свой интегрированности LN очень требователен к серверным ресурсам. И когда в результате они переписали приложение на MS SQL, выяснилось, что всех пользователей спокойно "тянет" один не самый крутой сервер, и пропускной способности каналов (которой не хватало для репликации) вполне хватает для нормальной удаленной работы пользователей.
При больших объемах базы также выступает "родовая травма" Lotus Notes - его система хранения данных не поддерживает ряд вещей, являющихся стандартом для современных СУБД, и совершенно необходимых для функционирования реальных систем автоматизации.
1. Во первых, БД Lotus Notes не поддерживает транзакции - т.е. согласованные изменения нескольких таблиц выполняемые как единое целое. Т.е. если, например, приложение, работающее на клиенте, успело модифицировать одну запись, но не успело другую, и отвалилось (например, свет выключился), то в базе данных LN измененная запись останется таковой, в то врем как во всех современных СУБД в такой ситуации на сервере произойдет откат до начального состояния.
Из-за этого поддерживать целостность больших баз на LN становится проблематично.
2. Как мы говорили выше, LN поддерживает возможность связывания документов. Но при этом контроля ссылочной целостности в нем нет - вы спокойно можете удалить документ, на который кто-то ссылается, и образуется "висячая" ссылка. Естественно, нет никаких более продвинутых механизмов контроля целостности - типа constraints в реляционных базах данных.
3. И наконец - в отличии от современных реляционных СУБД, где индексирование записи происходит при помещении ее в базу, в LN индексирование - это отдельный процесс, происходящий обычно по ночам, и при больших объемах данных, не всегда успевающий закончиться к утру. Т.е. получается забавная ситуация - вы документ добавили, а найти его - не можете. Видимо, так сделано потому что кроме индексирования коротких полей LN выполняет и полнотекстовое индексирование, поэтому индексирование одной записи (документа) может занять изрядное время. Но прелесть полнотекстового индексирования полностью пропадает из-за того, что значительная часть документов хранятся в виде вордовых и эксельных документов, внутрь которых Lotus-овскому индексатору хода нет...
Дополняет картину эксплутационных "прелестей" "толстый" клиент (не просто толстый, а очень толстый) с большим клиент серверным трафиком и среда разработки приложений, требующая редких и поэтому дорогих программистов.
Специалисты, эксплуатирующие Lotus notes, также жалуются на трудоемкость первоначальной установки и настройки, и, что гораздо более серьезно, большое количество критических для работы ошибок, в том числе в системе безопасности, которые очень медленно исправляются компанией-разработчико.
Лотус как система документооборота
Но, может быть, Lotus так хорош в качестве системы организации документооборота, что все вышесказанное можно проигнорировать? Действительно, у LN в этом качестве есть один большой плюс - он позволяет быстро создать корпоративное хранилище документов и обеспечить базовые процедуры работы с ним.
Но наряду с этим у него есть и большой недостаток - что, кроме этого Lotus сам по себе ничего больше не умеет. Т.е. сделать макет базовыми средствами Lotus можно, а вот реализовать полноценную систему корпоративного документооборота, удовлетворяющую требованиям ГОС-ов, не получается. Говорить - "Для автоматизации делопроизводства мы купим Lotus Notes" - такой же нонсенс, как и "Для автоматизации делопроизводства мы купим MS SQL". Необходимо либо разрабатывать систему, используя LN как инструмент, либо покупать специализированное решение.
Достоинством LN как среды разработки является наличие ряда встроенных механизмов работы с документами. О недостатках мы говорили выше - дорогие разработчики, устаревшая технология хранения данных и трудности интеграции с другими системами.
В целом выходит, что при несколько меньшей трудоемкости сроки разработки прикладной системы на базе Lotus не отличаются от аналогичных разработок на базе скажем, MS SQL и Visual Basic, а стоимость (с учетом лицензий и дорогих разработчиков) может и заметно превосходить. Не говоря уж о том, что эксплутационные свойства систем на LN, такие, как надежность и эффективность, заметно хуже, чем у решений на базе полноценных СУБД.
Специализированные решения для организации делопроизводства на Lotus на российском рынке есть. Наиболее распространенными системами являются разработка компании Intertrust - "Office Media", система "Босс-референт" от АйТи и "Золушка" разработки Института развития Москвы, и ряд других систем.
Но они стоят дополнительных к самому Lotus Notes денег, и, по оценке специалистов, их функциональности и эксплутационным характеристикам уступают системам, реализованным на базе полноценных СУБД и функционирующим в среде Microsft office, таким как "Дело" от "Электронных офисных систем", LanDocs от "Ланит", Optima Workflow от Оптимы.
Заключение
И все-таки, почему при всем вышесказанном Lotus Notes достаточно популярен у IT-менеджеров и продолжает свою экспансию в крупные российские компании?
Видимо, основных резона два.
Во первых, конъюнктурно - имиджи вые соображения - типа "у нас все, как у лидеров западного бизнеса - вот и Lotus Notes стоит".
Во вторых, LN создает иллюзию быстрого решения. При относительно небольших трудозатратах можно получить видимый результат и решить слой самых простых задач. А то, что дальше развивать это решение буджет очень сложно - так к тому времени либо бизнес помрет, либо IT-менеджер поменяется...
Не стоит также сбрасывать со счетов активную маркетинговую политику IBM и ее партнеров.
Каковы перспективы этого продукта на рынке? Те, кто много дет эксплуатируют сотни и тысячи рабочих мест LN, скорее всего, не откажутся от него никогда - по крайней мере до следующего катаклизма уровня "проблемы 2000 года". Просто потому, что издержки перехода на что-то другое будут слишком велики.
Но мне кажется, что в современных условиях Lotus Notes уже уходит в те глубоководные впадины рынка, где живут лох-несские чудовища, IBM-овские мэйнфреймы и Кобол. Там Lotus будет жить вечно, но компаниям, выбирающим для себя решения сейчас, ставить на Lotus Notes видимо, не имеет большого смысла.
Во всяком случае, нужно четко понимать, что Lotus Notes - это не просто одина из используемых компанией систем. Это целый мир, в который нужно погружаться полностью, уходя при этом от мэйнстрима, которым сегодння, нравится это нам или нет, все-таки является компонентная архитектура на базе решений Microsoft.
Детально Евфрат не щупали, но по поврехностным впечатлениям, это некий базовый конструктор, типа Digital Design-овского, который теоретически можно заточить под что угодно, а практически - объем работы по затачиванию оказывается очень велик, и при этом возникают самые разные проблемы в разных местах.
Дело ведь в том, что у классического делопроизводственного процесса, где основной объем работы выполняют делопроизвоители ЗА и ОТ ИМЕНИ должностных лиц, имеются разные грфы доступа и др. возникают очень прихотливые разграничения прав доступа, не покрывающиеся стандартными схемами.
И еще есть много нюансов - кого, о чем и в каких случая информировать, в каком виде представлять информацию, как номера генерировать, в конце концев... И масса всякой такой прикладной логики, которую ЭОС оттачивал на своих 600 или сколько их там сегодня клиентах, и которые, собственно, и обеспечивают конкурентное преимущество.
А у Евфрата есть еще одна заморочка - собственная СУБД, которая в любом случае развивается медленнее, поддержана средствами разработки и интегрируется с чем бы то ни было очевидно, хуже, чем MS SQL или Oraclе или любимая вами DB2. Так что развитие Евфрата в связи с его проприетарной платформой в любом случае будет соревнованием Эллочки-людоедки с Вандербильдшей.>>>>
Да, и на ЭОС я тоже работаю. Но к обсуждению технологических особенностей и идеологии Лотуса это отношения особого не имеет (хотя имеет отношение к тому, что я вообще заинтересовался этой темой).
Сравнение функционала, ссылку на которое вы прислали, имеет весьма косвенное отношение к действительности, особенно в части дифирамбов LanDocs-у и Optime. Похоже, автор обзора ориентировался тут на принцип "Дороже - значит лучше".
Потому что обе эти системы по функционалу в части автоматизации делопроизводства заметно недотягивают до Дела. То есть плюсики у них стоят правильно. но вопрос в том функционале, который за этими плюсиками кроется, а он может отличаться очень сильно. Поэтому они и имеют почти на два порядка меньше внедрений, чем Дело.
А цена их расчитана на то, чтобы поставлять их скорее не как самостоятельные продукты на открытом рынке, где они не выдерживают конкуренции, а в комплексе с другими услугами крупного системного интегратора (которыми являются и Оптима, и Ланит), где расходы на них оказываются не очень заметны, и "оправдываются" суммарными откатами от проектов.>>>>
> В частности, до сих пор на Лотусе не создано ни одной системы документооборота, по функционалу сопоставимой с "Делом". С этого надо было начинать :) Сказали бы честно "Я работаю на компанию ЭОС. Мы конкурируем с решениями на платформе Лотус. Я считаю, что наша платформа лучше."
А вот и сравнение функционалов: http://www.cnews.ru/newcom/index.shtml?2003/05/27/144624 Дело выглядит прилично, но есть и недоработки :)>>>>
транзакции привинтить к какой-нибудь системе несложно. Вот только как-то забывется, для чего это делается в реляционных базах - чтобы сохранить целостность сущности, размазанной по куче таблиц
Ровно для того же это делается во всех других местах - начиная от старинных иерархических СУБД (в которых тоже были транзакции), заканчивая модерновыми журналируемыми файловыми системами и XML-хранилищами.
А идея о том, что в Лотусе, как т.н. "документо-ориентированном хранилище" удается обходиться без размазывания информации по разным документам, и поэтому транзакции и с...>>>>
Андрей, транзакции привинтить к какой-нибудь системе несложно. Вот только как-то забывется, для чего это делается в реляционных базах - чтобы сохранить целостность сущности, размазанной по куче таблиц. То есть, сначала была создана проблема сохранения целостности объектов, а потом придумано блестящее ее решение. Как в анекдоте "Если вы штатские такие умные, то почему строем не ходите?" Если такой умный, то почему без транзакций? > Что покупают - это по разному. Для профессионалов ИТ повторяю еще раз: покупают не двигатель - покупают машину. Любая СУБД - только двигатель для организации бизнес процессов. Шасси, подвеска, электрика, салон ... Все вместе это стоит куда больше, чем двигатель.>>>>
Ну тут уже как-бы непонятно, о чем спорить. Да, если сильно постараться, можно и церковь топором вырубить. И стоять будет. Никто не спорит.
Отсутствие транзакций - это плохо, наличие - хорошо. Тоже вроде никто не спорит.
Что покупают - это по разному. Кто покупает "чтобы ездило", кто 600-тый для понтов, кто - 200 лошадей и 100 км за 5 секунд, а кто - "новую русскую", чтобы на обслуживании сэкономить.
Рынок рассудит... Но делать свои прогнозы мне никто не мешает, так же как и вам.
Андрей, ну не является автомобиль надстройкой над карбюратором. ну что тут поделаешь. Может, для автомеханика является, но не для водителя и пассажиров. Машины-то они покупают, а механик только масло меняет.
Если Вам несложно, киньте в меня ссылочкой типа "SAP R3 - надстройка над Oracle" или "Фотошоп - надстройка над Windows". Боюсь, что будет сложно.
Люди покупают фотошоп или САП, а на какой оси и какой базе оно крутится - это им безразлично. Так что Лотус остается крутой штукой, которую используют ТОП100. Придется как-то с этим жить.
А насчет "нельзя хорошо сделать". Мы делаем ХОРОШО клиенту, чтобы он был доволен и у него шла РАБОТА. Практика - критерий истины. Если клиент работает хорошо, то и сделано было хорошо.
Мораль - на любом средстве что угодно можно сделать плохо, если руки кривые. Спорить с этим невозможно, да и не нужно.
Но не на любом средстве можно что угодно сделать хорошо... До последних версий с транзакциями и DB2 целый класс приложений (в том числе приближенные к реальности системы документооборота) на Лотусе хорошо сделать просто нельзя было в силу технологических ограничений.
Теперь можно. И слава богу....
Раньше всякие MS-овские прилады много чего не умели п и плохо интегрировались между собой. Теперь они умеют больше, и интегрируются лучше. А с .NET нам вообще счастье обещается...
И слава богу.
Но если раньше на вопрос "Что такое LN" следовал ответ "Эта такая крутая штука, которую используют ТОП100 мировых компаний для организации коллективной работы", то теперь правильный ответ будет: "Это такая надстройка над DB2, которую (и т.д.)"
Почувствуйте разницу...
А насчет возраста DB2 вы видимо. несколько загнули... И Ораклу, и Лотусу сейчас лет по 20-25... Сорок лет назад никакой DB2 еще и в проектах не было - это проект середины 70-тых...
Уважаемый Андрей! Я вижу, что курс теории реляционных баз данных оставил неизгладимый след в Вашей памяти. Наверное, преподаватель был хороший. Получается что главное для Вас - хороший, мощный движок, а остальное - мелочи, какие-то "интерфейсы". К сожалению, я регулярно убеждаюсь в обратном. Вот у Оракла отличный движок - а что толку? Сколько я наблюдал провалившихся проектов на Оракле. Да и Вы, видимо, тоже. Люди вроде взяли самое лучшее, что есть, а результат плачевный. Жизнь куда сложнее теории. Вроде несложно разработать "интерфейс к базе", да немног...>>>>
Никто ведь не спорит - для своего времени Лотус был просто революционной системой. И он прекрасно обеспечивает поддержку несложных офисных бизнес-процессов - для этого и был сделан.
Но отсутствие обычных (для современных БД, а не для тех времен, когда Лотус создавался) механизмов транзакций и ссылочной целостности приводило к проблемам со сложными приложениями.
Сейчас, после замены движка, эти проблемы пропали. Но и Лотус как нечто отдельное логически прекращает свое существование - он становится просто еще одним интерфейсом к DB2. И выбор корпоративного заказчика теперь будет не выбором между Лотусом и Микрософтом. а выбором между DB2 и MS SQL...
А интеграция с почтой чего-либо сейчас проблем в общем, не составляет... Так же как и любая другая интеграция на MS-овской платформе. В отличии, впрочем, от интеграции с Лотусом, у которого (по крайней мере было) много мелких несовместимостей - типа проприетарного RTF.
И в общем, этот тред можно закрывать, так как для анализа сравнительных достоинств и недостатков Лотуса как интерфейса к DB2 у меня нет никакой информации.>>>>
Сакральный мир был создан не от большой радости, а по причине "наличия отсутствия" иных "интегральных" средств. Согласен, интегрировать SQL с почтой, писать клиента на дельфях, а потом переустанавлвать на рабочих местах при замене версии, писать отдельного веб-клиента и веб-форумы на php или asp, прописывать механизм репликации - это очень гибко и познавательно, но слишком напоминает обработку паровоза напильником. В последние годы начали появляться технологии, кои предлагают "универсальное решение". Но это только начало, а работать нужно сегодня (и вчера ведь тоже работали и внедряли). Ну не вышел еще Юкон или Титаниум - это не повод брать в руки напильник. А Лотус ... В 4-ке появился веб-сервер, в 5-ке жава и апплеты, в 7ке движок ДБ2, в 7.5 будет, видимо, эклипс. Это открытая система.>>>>
Да, а так же из Delphi, .NET Studio и из всего остального... Тем самым Лотус как отдельный сакральный мир прекращает свое существование. И народ будет выбирать не между Лотусом и Документумом (или Делом), а между DB2 и SQL-сервером.
Другие - это какие? Я знаю только одно - Сфера студию. Хотя подключиться можно и из VBA, и из 1С, и из Oracle Forms. У них у всех разные преимущества.>>>>
Я в курсе, что такие планы были - см. И снова о Lotus Notes
Я только не в курсе - что, семерку уже выпустили?
Применительно к ней вообще все эти вопросы снимаются, остается один - какие преимущества имеет ли Лотус перед другими средствами разработки приложений на базе DB2 и WebSphere?>>>>
Да, действительно. Я обещал выложить резюме обсуждения.
Итак, когда задачу детализировали до "честной" постановки, требующей раскладывания всех объектов по отдельным документам, выяснилось. что
в смысле трудоемкости программирования форм и др. Lotus не даст никакого выигрыша по сравнению с современными средствами разработки на базе реляционных СУБД, а наоборот. создаст некоторые ограничения интерфейса.
для достижения приемлемого уровня надежности мой оппонент предложил архитектуру типа "закат солнца вручную" - создание рукотворной клиент-серверной модели, где вся обработка запросов будет локализрована в неком ядре, формы-интерфейсы будут формировать запросы к этому ядру и ставить их в очередь, а некий диспетчер будет следить за строгой очередностью исполнения запросов. Причем заметим, что из-за отсутствия транзакций при хорошей нагрузке последняя консрукция все равно будет время от времени разваливать целостность данных, хотя реже, чем без нее - практика имеется.
В общем, когда это все сформулировалось, мой оппонент обиделся, обозвал меня в непарламентских выражениях и ушел. Потом, правда, спустя год, извинился...
могу заметить, что в данном обсуждении упирают на нереляционность LN. Простите, а зачем это, здесь путь проторен - DECS (идет в составе Domino Enterprise), и соединятесь и делайте транзакции (в реляционных базах), а интерфейс и управление в LN. Не нужен в этом случае VB и MS вместе взятые. Выбор RDB - достаточно широк. ДЛя особых упражнений есть LSX Есть инересная деталь - в LN существует (и существовал) полнотекстовый поиск. Как прикажете искать в реляционной базе (и если она не одна и по всем полям). В Домино (более правильное название для серверной части, с определенной версии) возможен поиск по домену. То есть я могу искать по всем базам, на всех серверах домена Notes (удаленных в том числе), по включ. в область поиска базам - этим занимается сервер индексирования (им можно назначить любой из серверов Домино, на современном написанию статьи периоду) Индексирование ночью - это было сильное высказывание со стороны автора (специалисты статью явно не читали). О каком индексировании шла речь (о мощностях сервера - неплохо бы указывать харрактеристики) Это если коротко :)>>>>
По поводу заработной платы. Судя по адресу любимого Вами лотусовского сайта и проскакивающих украинизмов, можно предположить, что Вы уважаемый Г.А.В. имеете ПМЖ в Украине. А там зарплата в 300 баксов это знаете-ли очень даже ничего. Да и за 150 там очень еще поискать работу. Уважаемый нами А.А. описывал расценки труда программистов в РФ и скорее всего в пределах московской кольцевой.>>>>
У нас наблюдается явный прогресс, признаю. 1) Я решил задачу, которую Вы поставили, а не ту, которая подразумевалась. При решении любой задачи я стараюсь создать наипростейшее решение, которое будет и самым надежным. Но отступать от задания не в моей манере. Хотите усложнить задачу - я согласен. Только дайте точное описание того, что должно быть реализовано (не как). Иначе Вы снова на что-нибудь скажете, что это должно было быть, как само собой разумеещееся, а я упрощаю. Действительно, я придерживаюсь точки зрения, что Домино - система полнофункциональная. Еще раз повторю, что приведенно...>>>>
1) Я не выбрал единственно верный вариант. Я вам просто указываю на некоторые жизненные реалии - например, что подразделение сначала создается приказом, а потом уже туда нанимают сотрудников.
И что у подразделения (а тем более - у организации) есть свои СОБСТВЕННЫЕ атрибуты (полное/краткое название, код, начальник, телефоны, email, номер приказа о создании, и еще много чего), которые в вашей схеме хранения засунуть некуда, разве что дублировать их в каждом сотруднике, и что сотрудник может совмещать несколько должностей в разных подразделениях...
Приблизительно такой реакции я и опасался. Система естественно влияет, но не столько на мышление, сколько на реализацию задач в ней. В данном случае я вижу, что Вы выбрали для себя единственно верный вариант решения и никакие отклонения не возможны. 'Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.' - не совсем так: я реализую их как единое целое, а вот отображаться они будут по привычному, как вещи отдельные, самостоятельные. Можете мне нарисовать реалию, в которой в организации будет существовать подразделение без сотрудников? Штатная единица согласен...>>>>
Вот я примерно об этом и говорил. Используемая система влияет на стиль мышления. Вы пытаетесь Предметную область, содержащую множество понятий, отобразить одним.
Вы ведь не забывайте, что Подразделения - это самостоятельная сущность. У них есть свои атрибуты и иерархия. Кроме того, могут быть свежесозданные подразделения, где нет еще ни одного сотрудника.
Кроме того, Должности тоже могут жить без сотрудника. Есть такое понятие - Штатное расписание.>>>>
Во первЫх строках спасибо за мирное отношение, для меня это важно. Во вторых, я теперь немного по другому понял, почему Вы считаете систему Домино не способной на подобный подвиг :). Попробую описать, как бы я сам решал подобную задачу. Для начала один момент: я не являюсь специалистом никакой другой технологии (к собственному стыду) кроме Домино, по этому могу не знать о каких-то общепринятых понятиях или названиях, я буду оперировать терминами Домино. Итак, мы создаем форму карточки сотрудника с необходимыми нам пунктами: Организация, Подразделение, ФИО, Должность, Ставка, Notes...>>>>
Транзакция - это согласованное изменение некоторого множества данных, облажающее таким свойством, что оно либо выполняется до конца, либо от него не остается никаких следов.
В Лотусе изменение одного документа (записи) - транзакционно. Оно либо происходит, либо нет. Но согласованное изменение нескольких документов оформить как транзакцию нельзя (по крайней мере так было).
И если выполняемая технологическая операция требует, чтобы согласованным образом изменились несколько документов, то здесь возникают проблемы.
Поэтому системы на Лотусе стараются строить таким образом, чтобы таких ситуаций было поменьше, и транзакции сводились, по возможности к модификации единичных документов. И пока это получается - все хорошо.
Но вот вам классический реляционный пример - фрагмент какдровой системы. Имеются подразделения, сотрудники, и факты занятия определенным сотрудником определенных должностей в определенных подразделениях на полную/частичную ставку с некоторым окладом. Да, и возможно совмещение, естественно...
Причем смотреть на это нужно как в разрезе сотрудников (где он сейчас работает на каих должностях и с каким окладом), так и в разрезе подразделений. А так же переводить людей из одного подразделения в другое, менять должность и оклады и др.?
Давайте попробуем разобраться с этим конкретным примером. Я уверен, что при его "честной" реализации вы получите ту же самую, или большую, трудоемкость, чем на реляционных СУБД, и менее эффективную и надежную работу - чисто за счет архитектурных особенностей.
Если вы сумеете меня переубедить - отлично, вам зачтется...>>>>
Вы знаете Андрей, меня всегда несколько удивляли люди, делающие умный вид , скрывая свои мировые знания. Ну разве Вы были удовлетворены, когда Вам писали, что Ваша статья просто туфта? Никак не аргументируя, не проводя никаких паралелей? Фраза 'Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо' - является необоснованной. Дайте какое-то обоснование, пожалуйста, пример. А я Вам тогда расскажу, как все хорошо на самом деле можно построить. Пример: транзакции в описанном Вами виде. Принимаем за истину, что транзакции это автоматическое изменение ...>>>>
Спасибо Андрею за поптыку объективного разбора. На самом деле он полностью (за исключением уже замеченных и впоследствие исправленных фактических ошибок) подтверждает мои впечатления.
Как о позиционировании системы, так и об ее ограничениях.
Он еще раз демонстрирует, что Лотусисты не понимают, зачем нужны транзакции и ссылочная целостность. И тем самым хорошо характеризует область применимости системы.
Пока модель данных задачи у нас укладывается в ситуацию, что 1 содержательная сущность = 1 документ LN (или Domino, как вроде правильно говорить), и технологиченские операции у нас такие, что одна операция меняет один документ, то все хорошо, и LN дает фору любым реляционным СУБД.
Как только задача у нас перестает помещаться в такую модель данных, тут же становится все плохо, и чем дальше. тем хуже...
Говорят, кстати, что в 6-ке наконец сделали честные транзакции.>>>>
Несколько раз слышал об этой статье, слышал много мнений, все (не большинство) не лестные (возможно потому, что кручусь именно в кругу специалистов Лотуса). Но вот добрался до оригинала только сейчас, только через год(!). Понимаю, что как специалиста, меня это характеризирует не с лучшей стороны, но факт остается, так вышло. Сначала думал просто прочесть: итак много обсуждено, наговорено, статья-опровержение вон даже есть (к стати, ее еще мне предстоит прочесть, т.е. сейчас будет только мое мнение, незапятнанное противовесом). Но теперь решил и свое замечание оставить. Я полностью согласен...>>>>
Софтерра, как и Компьютерра, никогда не была сделана на CW. Нынешняя версия сайта сделана компанией РусАрт (ныне Индивид) на их движке Сайтистика.
Как раз коммуниверные форумы без проблем можно дотачивать как угодно, так как это не специальный модуль, а просто некоторая система шаблонов. И настройки там всегда были (см. кнопку Настройки рядом с Высказаться в моих форумах).
Если вам не хватает какого функционала у меня - пишите, добавим. А отутствие картинок и вообще дизайна у меня - момент концептуальный...>>>>
Похоже Softerra начинает переходить от Communiware к нормальным стандартным решениям. Форумы потеряли кустарный вид, появились иконки, настройки. Может, и Вам пора?>>>>
Однако, наблюдаются странности - 1. "невозможность открыть вложенный в письмо файл одним кликом - его нужно экспортировать на диск, и там уже открывать" - никогда с таким не встречался. Дважды кликаем на аттаче в нотусе и открываем нужный документ. Есди документ выполнен как OLE-вложение, то можем редактировать его на месте - в самом документе нотуса. 2. "репликация между крутыми серверами по выделенному оптоволокну шла часами" - а это из-за приверженности к дешевым решениям. Какой смысл ставить сервер в каждом из подразеделений, если существует возможность централиз...>>>>