Разрешите поделиться некоторыми впечатлениями на тему об идеологии и методах разработки в Лотусе. Тема очень обширная, так что будет удачей хотя бы пунктиром наметить основные соображения. Сразу хочется оговориться, что, несмотря на подзаголовок, хотелось бы не провоцировать споры, а лишь высказать собственную точку зрения и пригласить Вас поделиться своей.

Во-первых, складывается (давно сложилось) впечатление, что люди, приходя в Лотус из традиционной разработки (C, Pascal, etc.), подсознательно не желают отказываться от своих умений и привычек, сопротивляясь новой среде с непохожей идеологией. Благо Лотус предоставляет им нишу под названием Lotus Script. Честно скажу, что лучшего объяснения "засилью" скрипта не представляю. Доводы о мощи скрипта по сравнению с формулами и т.п. , хоть и верны, но не слишком убеждают. Почему же в таком случае не С++ и Notes API? Потому, что для каждой работы есть свой инструмент: на мух -- с мухобойкой, на медведя -- с ружьишком, ну a на танк уже с С++... Это рассуждение плавно подводит нас к вопросу о том, какой же инструмент есть в Лотусе и для какой же работы он (инструмент, да и сам Лотус) предназначен? А это уже вопрос второй, имеющий явственный схоластически-философский оттенок...

Во-вторых, невооруженным глазом видно, как народ, воспитанный на классических языках программирования и впитавший сызмальства идею реляционной базы данных (Что, бывают другие!?), отчаянно пытается сделать на Лотусе то, и так, как он к тому привык и знает... Что греха таить, 10 лет назад, начиная работать с Лотусом (принимаю поздравления по поводу юбилея), около полугода переживал болезненный период ломки стереотипов и "врастания" в Лотус, его, в широком смысле слова, инструментарий и идеологию. С тех времен осталась формула "если это тяжело и никак не получается сделать -- это не Лотус". То есть, нужно искать "ассимметричный ответ", который легко решит вопрос другим образом, естественным для Лотуса. Это и есть (была) главная проблема: должно быть именно так, а иначе я не представляю и вообще, по-другому не бывает, потому, что не может быть никогда. Для признания существования этой проблемы нужны серьезные усилия. Лично мне помог такой случай: наряду с Лотусом, мы, как ярые новообращенные, поставили себе Lotus Suite взамен MS Office. Что тут началось! Даже не представлял, что редактирование текста может быть иным! Если Вы тоже "даже не представляете" -- попробуйте, не пожалеете. Именно то, что нужно для ломки стереотипов...

В-третьих, мне очень понравилась фраза какого-то зарубежного разработчика "За что я люблю Лотус? Представьте, приходит ко мне пользователь и говорит, что ему нужно не так, а эдак... И стоит над душой, возле меня, сложив руки, смотрит, пока я ему это не сделаю!" Представьте и вы: в какой иной среде, для какого продукта такое возможно?! Лотус сам по себе -- сплошная RAD. И не даром Лотус говорит о методологии "протоциклирования". Кстати, раньше было гораздо интереснее документацию к новым релизам читать: всегда было там что нибудь "воспитательное" про идеологию, методологию, правильное применение... И не даром у Лотуса, если не устарели цифры, что помнятся, второе место в мире по установочной базе после MS Office. Лотус, он гораздо ближе к офису, чем к монолитному высокоспециализированному приложению, целиком наваянному на ЯВУ. Соответственно, и способы решения одной и той же задачи для Лотуса и такого приложения -- разные. Но, как упоминалось, многие программисты пытаются работать на Лотусе, стремясь получить то самое монолитное приложение с высокоспецифичными и тесными взаимосвязями внутри своего проекта. Не всегда это правильно.

Наконец, авторы Лотуса сами говорят, что пользователи постоянно изобретают такие ему применения, какие им и в голову не приходили. Интересно, что все такие применения в своей реализации напоминают "шанхай": множество простых по дизайну баз с простыми, но обширными взаимосвязями, когда центр тяжести лежит не в изобретательной разработке конкретной базы с ее специфичным функционалом, а в реализации концепции простых, но множественных баз нацеленных на обеспечение сохранения разнородной информации, установлении базовых связей и обеспечения ее доступности.

Вот.

По скриптам не согласен. У скриптов есть один ЖИРНЕЙШИЙ плюс: логику приложения можно сосредоточить в одном месте. Вот только ради этого. Например, мне нужно пред сохранением проверить форму на коректность заполнения. Да, есть такая штука как Input Validation. Но есть один недостаток: с первого взгляда я не вижу какие поля проверяются, какие нет. Мне надо "проклацать" каждое поле.

А если я повешу на QuerySave в скрипте? Сразу всё видно. Мало того, я проверку могу вообще сделать настраиваемой снаружи. Сделать много маленьких документиков с реквизитами "Название формы", "Название поля", "Формула проверки" и мааленький флажок "вкл/выкл" и проверять на основании этих документиков. Скриптом, ессно. Что получу? Казалось бы лишний гемморой. Но! Раз помучившись (при том не сильно, мин. 20 с перекуром и красивостями) в дальнейшем с лёгкостью и непринуждённостью истинного иллюзиониста смогу добавлять новые проверки и отключать уже имеющиеся. При этом влёт и на любую форму. А при наличии у заказчика лотусоида "средней паршивости" с меня вообще эта проблема слазит. Ещё потратив децл времени и один флажок в настроечный документ я смогу реализовать предупреждение, что де "некоторые поля не заполнены, в принципе они необязательные, но желательные, будем продолжать?". И у меня всё перед глазами. Не надо по полям формы прыгать аки сайгак.

Если мне понравится - я с лёгкостью перенесу эту делу в другое приложение (чё там, вьюха+сабформа+форма). А сделать такое формулами? Отож... Так что скрипты мощнее формул. Именно из-за того что формулами нельзя логику сосредоточить в одном месте.
------------------------------------------------------------------------------------------------------------------------------------------------------------------

Про реляционку согласен! Лотус есть лотус. Вернее, вначале был документ, и документ был лотус, во! Но бухгалтерские системы - это не документ, это нечто страшное .


P.S. О методах разработки напишу потом . Муза ушла.

Опа, что я вижу, это же ПИАР в пользу одного только лотуса!!!!

А сабо в лотусе на форме табличку прокручиваемую вывести, берущую данные из другой базы лотусиной, и потом установить эту конфигруацию баз заказчику? )))

запросто: Embedded view, или вычисляемое поле с @DbLookup и формулами, обрабатывающими полученный список.

Дык, а что ожидалось? Что мы тут Oracle начнём расхваливать? Для этого другие разделы форума есть . Вот щас пойду к шефу и скажу: "Шеф, лотус - фуфло, я так больше не могу, я увольняюсь." .

я устал... я ухожу

А я с Вами согласен У самого много лет используется типовая форма со скриптами на событиях, которая проверяет поля. Это тот самый случай, когда скрипты демонстрируют свою силу и применимость. Но это не тот случай, когда скрипты _всегда_и_везде_, где в них нет на деле ни малейшей нужды. Кстати, скрипты в Лотусе -- весьма локальная вещь. Поэтому логику приложения в _целом_ на них повесить очень трудно, если возможно. Логика приложения смещена в сторону взаимодействия крупных элементов дизайна.

Ээээ.... Я так глобально мыслить не умею . Что такое "крупный элемент дизайна"? Мне бы примерчик...

Для: Fossil Code
красиво излагаете... жаль нема у меня музы

А когда я начинаю глобально мыслить, и, не дай бог выскажу свои глобальные мысли в присутствии босса, обычно слышу в ответ неодобрительное: "Ну, это все лирика. Философия всякая. Ты по делу давай!" Ну прямо, как в анекдоте, когда капитан о курсе ответил <норд-норд-ост>, а в ответ получил совет не выпендриваться и показать пальцем

А крупные элементы дизайна -- это формы, виды, агенты, базы. Насколько могу судить, логика работы приложений в основном формулируются именно в терминах функционала этих элементов.



Дело наживное... Несколько лет журналистики, переводов, технического писательства -- и дело в шляпе. Как говорится, после первых пяти языков программирования все остальные кажутся одинаковыми.

Так всё вышеперечисленное обплетается скриптами (окромя колонок и формул отбора, ессно). Естественно, если речь вести о функционале, а не об интерфейсе вцелом (компьютед-тексты, например, к функционалу имеют незначительное отношение, а вот к интирфейсу - прямое).

Хе-хе, а вот и нет!!!!
Первое правило в шахматах - не есть пешку противника сразу

1. Не сможете через Embedded view, так как он при создании жестко хранит ID реплики и перенастроить незя когда заказчику притащите

2. второе ИЛИ ВЫЧИСЛЯЕМОЕ ПОЛЕ не дает прокручиваемой таблицы плюс организчения на размер выводимой информации табличного вида.

Так что воспевать лотусину нужно осторожно.
Принципы традиционного программирования во многом сохраняются и в лотусе.
Принципы построения реляционной модели во многих задачах сохраняются и в лотусе!!!

Можно. Через DXL . Правда, нужны права дизайнера. Но при установке это не суть проблема, а очень даже логично.


А кто воспевает? ГДЕ тут было воспевание? Если есть принципы реляционной модели, которые сохраняются и в лотусе - то это означает, что это просто общие принципы, а не реляционные .

Ну-ну!!!! Знаем, пробовали
Приаттачте пример базы, где это работает.
Если Вы имеете в виду интертрастовский пример, то он херит дизайн предсталвения как мама дорогая.

Допольнительно по DXL меня поражает тот факт, что если просто распарсить дизайн вьюхи и засунуть обратно без единого изменения - ПОЛЗЕТ ДИЗАЙН!!!!!
Гуано это, а не метод.

Они не просто сохраняются, они ТРЕБУЮТ ОФИГЕННОГО, СОВСЕМ НЕ RAD программирования.

Выскажусь и я о наболевшем.
Как справедливо отметил топикстартер, пересаживаться на Лотус после традиционных средств разработки и СУБД довольно тяжко: "реляционное" наследие дает о себе знать постоянно. В этом свете особенно неприятно отсутствие толковой литературы, описывающей, как именно стоит создавать базы данных в Лотус. Т.е. не формочки-вьюшки клепать, а именно создавать модель данных, удовлетворяющую как требованиям заказчика, так и особенностям Лотуса. Единственное, что я для себя уяснил пока - стремиться к нормализации в любом ее проявлении как правило не имеет смысла, проблем будет больше, чем пользы.
Механизмов, автоматически поддерживающих целостность данных, тоже нет по сути, все приходится делать руками (у меня вон пара агентов бегают временами по базе, синхронизируя содержимое различных документов). Транзакций нет, блокировок (в R5 по крайней мере) тоже нет.
Если рассматривать Лотус как среду разработки, то тут тоже многое крайне непривычно. Формулы хороши, но ограничены в своих возможностях (как, например, на формулах перебрать ответы на документ без создания доп. вьюх?), да и отлаживать их нельзя (хотя у меня LS-отладчик временами в формулы "залетает", выдавая какой-то LS-код ). Насчет LS я уже поворчал в соседней теме.
Но больше всего, конечно, мешает жить ограниченность средств построения UI. Ну ладно, допустим, я еще смогу пережить отсутствие возможности обработывать события различных компонентов, кроме Click для кнопок, но вот простой таблички на форме мне зачастую весьма и весьма не хватает. Да, можно воспользоваться embedded view, только вот взаимодействовать с ним никак нельзя (риторический вопрос: как получить выбранный в emb. view документ? ), да и вообще, иногда нужно отобразить какие-то агрегированные данные (количества документов определенных типов, минимумы-максимумы какие-нибудь), а view этого не умеют.
Понимаю конечно, что многие мои проблемы обусловлены недостаточным пониманием идеологии Лотус, а также непониманием нынешнего заказчика того простого факта, что Лотус для его задачи подходит крайне неважно, но тем не менее, после перехода на Лотус ощущаю одни сплошные ограничения
Есть вещи, конечно, которые нравятся. Прежде всего, это возможность очень гибкой работы с данными: можно свободно менять структуры данных, добавлять/удалять поля, и все при сохранении работоспособности системы (при наличии прямых рук, ессно). В реляционных СУБД это было бы куда сложнее. Возможность быстро дорабатывать систему на месте тоже весьма приятна, хотя частые доработки по запросу пользователей, которым чего-то не хватает, не одобряю. Таким макаром легко довести систему до состояния, когда никто толком не будет знать, что в ней творится и как устроено (не голословное утверждение, есть у меня один пример перед глазами).
Вот, вроде высказался, аж полегчало

Согласен.... сам долго не мог понят шо оно такое


А в чем собственно проблема?

да... нехватало раньше, приходилось руками докручивать


>Понимаю конечно, что многие мои проблемы обусловлены недостаточным пониманием идеологии Лотус
Но! Ведь попробовав раз - ем и сейчас )))

Наверное, в шахматах так оно и есть. Не играю, к сожалению, в шахматы. Но мой папа любил говаривать "Лучше геройски пукнуть..." -- видимо, гены сказываются .

А насчет показа таблички в форме, который "не смогу" сделать, правильный ответ (не геройский) таков, что я бы вообще не стал этого делать! Цена вопроса играет роль: вынь да положь табличку в форме потому, что "надо так и не иначе"? Чтобы предоставить соотв. информацию не обязательно "вставлять в форму" динамическую табличку. Можно генерировать по запросу статический документ, куда инф. и пропишется табличном виде. А то и без таблички -- видом, фолдером, а то и полнотекстовым поиском. Право слово, не стал бы "упираться", поискал бы содержательно такое же, а интерфейно -- иное, решение.

Принципы программирования одни и те же в Лотусе и везде. Способы осознания и постановки задач программисту, методы и приемы их решения программистом, сильно зависят от применяемого инструментария и в этом Лотус заметно отличается.

Лотусе -- не реляционная база. Принципов построения реляционной модели в Лотусе просто нет! То что Вы называете так -- часть общих принципов построения баз данных, безотносительных к ярлыкам, которые на них навешены.

1. Я требую примера чиста реляционного принципа, справедливого для Лотуса!
2. Примерчик будет как только у мя руки освободятся да желание возникнет.

О! Повторю свой любимый пассаж (формулировка намеренно парадоксальная, но доказывается почти как теорема): Механизмы репликации и транзакции на системном уровне не совместимы.
Т.е.:
- СУБД поддерживают механизмы целостности данных, но не имеют (и не могут иметь!) встроенного механизма репликации.
- LND поддерживает репликацию, но не имеет (и не может иметь!) встроенного механизма транзакций.

Тем не менее, репликация в СУБД (как и транзакция в LN) возможна, НО только на уровне отдельного приложения, с учетом конкретной задачи/структуры данных/workflow

А это из другой оперы, из мультиплатформности, переносимости, обратной совместимости и т.п.. Как в Java: много-ли интерфейсных бантиков вы можете навешать на апплет, если SWING не включена в состав VM? Т.е. условно в Lotus-VM есть AWT, но (еще?) нет swing

Для: Constantin A Chervonenko

Здравствуйте, Константин. Во многом учился на Ваших форумовских ответах, но вот неоднократно встречающееся мнение по поводу невозможности репликации в реляционных СУБД не совсем понимаю.

Репликация в РСУБД (Oracle и MSSqlServer) настраивается и поддерживается подобно репликации в Lotus.
Только, на мой взгляд, более гибкая по своим возможностям.
Можно даже вмешаться на программном уровне в этот процесс!!!!!
Можно устроить слияние одновременно измененнных данных, например.

И вот по-моему два Ваших высказывания противоречат друг другу:




А в Lotus разве не на уровне приложения (базы)?
Поясните боле подробно в чем разница-то?

Совершенно все именно так! Это наши общие "грабли", по которым еще ходить и ходить, к сожалению. Особенно требования заказчика к тому, что он хочет видеть: не столько содержательно, сколько интерфейсно. Помню был жуткий скандал, как мы с бухгалтером орали друг на друга... Просто ей поставили ей в ексцелл пару табличек, имевших элементарный, нужный ей функционал... Камнем преткновения была позиция: "Поставьте мне нормальную программу! Вот такую!!!" -- и показывает типичную клипперовскую менюшку...

Не претендуя на многое, хотел бы высказаться по поводу подхода, который себя, похоже оправдывает. Этот подход начинается немного в стороне от привычной реляционщикам и не Лотусовым программистам работы с массивами информации в неких специально изобретенных (в зависимости от инструментария) формах и форматах, скрытых от конечного пользователя. Подход "интерфейс отдельно -- данные отдельно" для Лотуса срабатывает со скрипом, поэтому при первоначальном анализе задачи изучается бумажная реализация процесса, входящие и исходящие документы, которые считаются не столько носителями нужной информации, сколько основными единицами, с которыми предстоит работать. И пользователи очень хорошо принимают объяснение, что "эти документы, что у вас сейчас на столе, будут в точно таком же виде у вас в компьютере, и технология вашей работы не изменится, разве что станет быстрее и легче их искать, а еще появится целый ряд автоматизированных для вас операций..."

И это правильно, товарищи. Скажем, если воспроизводить технологию работы с бумагой, то Лотус хорошо соблюдает принцип "карте -- место" и не апдейтит автоматом доки при изменении в справочники. И в этом смысле он хорошо обеспечивает целостность данных! Очевидный недостаток оборачивается несомненным достоинством. Несложно обеспечить, за счет видов и поиска, легкий доступ к документам. А вот когда речь заходит о выполнении массовой обработки -- лучше выгрузиться в реляционку или вообще в пакетную софтинку... (Сам Iris говорит об использовании Лотуса в роли фронт-енда к корпоративным реляциям.) А когда речь о бантиках и форматировании, скажем, для печати -- выгружаться в Word или таблицы. Чтобы в Лотусе оставалась в основном логика документарного воплощения "бизнес-процесса". Хорошо иметь распределенный набор баз "первички", между которыми и происходит документарное движение, а в дополнение к ним -- консолидирующие базы, которые и служат базой для проведения массовых расчетов, если нужно.

В том же ключе: ну очень трудно, если вообще возможно (у меня ни разу толком не вышло) сделать для Лотуса последовательную нумерацию документов в распределенных базах. Соль в том, что делать этого не следует в принципе, но убедить клиента в качестве идентификатора документа использовать код unid или notesid не всегда, к сожалению, удается, как ни ссылайся на примеры из каталогов импортных производителей...

Вот, примерно так боремся.

Ну как в чем... Есть форма, на ней лежит emb. view, в котором выбран документ. На форме еще есть кнопка, по нажатии которой мне нужно этот выбранный документ достать и обработать. Долгие часы и дни поисков по конференциям привели меня к выводу, что такое можно сделать только длинными и ненадежными кружными путями, работоспособность коих в общем-то никем не гарантирована.

Думаю, для меня лично Лотус останется просто интересным опытом в жизни - по окончании проекта вряд ли еще к нему вернусь.. Или вернусь, но только если Лотус дадут свежий (6.5 хотя бы) - 5ка слишком жестко портит мою хрупкую нервную систему

Обычно да, такое допустимо, но не всегда. И потом, хочется сделать приложение еще и удобным для пользователя, чтобы нужные данные/функции были по возможности под рукой, а не требовали для доступа к себе длительных странствий по всевозможным вьюхам и папкам.

Если уж на то пошло, то в "зрелых" версиях Java даже в AWT возможностей поболе будет. Про Swing вообще речь не идет - нет смысла сравнивать... А ведь уже вполне можно было бы сделать, сколько лет-то Лотусу
Несколько напрягает жесткая связь между данными и их представлением: документу строго соответсвует форма, элементу ввода на форме - поле документа (либо не можешь редактировать, либо потом придется выковыривать поле из сохраненного документа, если оно там не нужно), группу документов можно отобразить только в виде вью (или папки - суть, то же самое). Понятно, что по-другому не сделать в рамках самой концепции Лотуса, но все равно неприятно.

можно... длинными и окольными ..

Об чем и я... вроде бы даже по вашему совету делал в свое время такое с помощью JavaScript и фреймов. Сначала получилось, а потом в один прекрасный день перестало работать, причем не только в текущей версии, но и старой, которую я незадолго до прекрасного дня убрал в архив абсолютно рабочей В чем был прикол, гадаю до сих пор...

Так и знал, что к словам придираться будут. С Жабой не сравниваю, только аналогии провожу. Вы можете произвольно расширять java-vm? А если уж сравнивать, то поскольку жаба моложе, над ней не висит такой огромный груз обратной совместимости. Которой она, впрочем, не особо и заморачивается (аппликухи 1.1.8 под 1.3.х не идут!). M$-way

Глупости. Особенно - документ=форма. Да и item != field. Это издержки книжек типа ".. за 40 минут" и творений Линдт+Керн

Ууууу... Форма и документ - не одно и то же. Документ - то, что храниться в базе, форма - элемент дизайна (хранящийся в базе в виде документа, кстати ). Да, документ может создаваться по форме. может отображаться по форме. Но я могу создать докмент по одной форме, потом отредактировать по другой, потом ещё раз открыть по третей. Поле и итем - тоже не одно и то же. Итем - то, из чего состоит документ. Поле - элемент формы (хранящийся в базе в виде итема . Да, когда документ открывается по форме, то его итемы раскидываются по полям .

Вот такая вот загагулина...

Репликация чего? Таблицы или базы данных?? И что такое "база данных"? Для разных приложений БДой будет разный набор таблиц.
Или (как в последених Ораклях) - репликация журнала транзакций? Да, это интереснее. Но:
пусть 1й клиент модифицировал запись "А"; 2-й - запись "Б" одной и той-же таблицы. Конфликта нет, строчки отреплицировали друг-другу и 3-му клиенту. А с его точки зрения (его прикладухи) эти записи взаимосвязаны! Он ничего не делал, но данные разрушены;
или пусть 1й модифицировал "А" с учетом того, что "Б" неизменна (а 2й - наоборот). Приехали.. Конфликт обеспечен, причем механизма его обнаружения и отображения НЕТ

Я о том и говорю: зная все взаимосвязи прикладных данных, размазанных по десяткам таблиц (нормализация-ж!), вы часто (не всегда) можете запрограммировать правила синхронизации с учетом выявления и разрешения конфликтов. Т.е. напишете свой репликатор для конкретного приложения. Для другого набора таблиц он будет непригоден.

Как раз потому, что в LN база=приложение, а одна сущность=один документ (с неизбежной избыточностью), и возможен общесистемный репликатор. Но попробуйте только нормализовать данные LN (размазать сущность между базами и документами) - чему он ужасно сопротивляется, как репликация и развалится (будет крошить ваши сущности).

Это почему же у вас вычисляемое поле не дает прокручиваемой таблицы? Оно что - от моего чем-то принципиально отличается?
Или я что-то упустила, и имелось в виду поле с конкретными параметрами?

Что внедрение вида из другой базы пока оставляет желать лучшего - согласна.

И что там про пешку - таки вы уверены, что задача неразрешима? Я иначе думаю.

Пожалуйста.

с точки зрения по соотношению занимаемых должностей:
Представление1: ФДолжность, ОргДолжность, ФИО, ФАтрибуты

Логическая модель базы данных
Сотрудник может занимать несколько организационный должностей и обладать несколкими функциональными должностями. Сотрудников - боле 1000.

Сущность: Функциональная должность (ряд атрибутов)
Сущность: Организационная должность (ряд атрибутов)
Сущность: Сотрудник (ФИО, список орг должностей, список функц должностей)

Руководству в оперативном режиме следует выводить информацию в двух разрезах:
1. По функц должностям
ФДолжность, ОргДолжность, ФИО, ФАтрибуты, ОргАтрибуты

2. По орг должностям
ОргДолжность, ФИО, ОргАтрибуты

Физическая модель базы данных в РСУБД
4 Таблицы: ФДолжности, ОДолжности, Сотрудники, Отношение MxN ФОСотрудники
и SQL запросами разруливаем вывод на экран
При удалении ФДолжности или Переименовании ничего прогать не нужно

Физическая модель базы данных в Lotus

ваш ход, коллега

Теперь немного про "наболевшее"

1. Тот, кто жалуется на "нереляционность" и описывает ужасы лотуса, видимо, привык к транзакционной обработке данных некоторыми РСУБД вроде Oracle.
А кто попробовал использовать реляционную базу без транзакций (что было распространено для MySQL), тот уже ни на что не жалуется.

2. О языках. Ну вот нету в LS каких-то возможностей. В формулах нету других, в JS - третьих...
Их на то 5 языков и встроено, чтоб программеры утюгом гвозди не забивали.
Уважаемые коллеги! изучайте разные языки - это облегчит жизнь, не говоря уж об украшении вашего резюме



PS: я ничего не имею против Oracle или других РСУБД

Брррр. К чему тут мой ход? Вы сказали, что реляционные принципы справедливы и для Лотуса. Я несогласился (причём категорически). Попросил пример. Вы пытаетесь меня втянуть в придумывание примера . Ай, нечестно .

Но если уж на то пошло, то в вашем примере для Лотуса всё будет совсем не так, как для реляционки. В общем, реляционный принцип "несколько" не подходит.

И у меня такое чувство, что вы пытаетесь доказать, что Лотус хуже реляционки . Если да, то это не относится обсуждаемой в этой ветке теме . Откройте новую. Там и поспорим что лучше, молоток или отвёртка .

Я не хочу лезть поперед Михала в пекло и предлагать свой вариант приложения в лотусе.

Хочу только уточнить - если должность реально переименовали , то что у человека в трудовой книжке будет написано? Отдел кадров предыдущее название замазкой замажет? или все-таки напишет "переведен с должности дворника на должность менеджера метлы"?
И лотус это замечательно зафиксирует.

PS: "Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам..."

В нескольких последних ответах заметно повышенное внимание к нескольким особым аспектам разработки в Лотусе, что вызывает желание заменить ранее намеченный пунктир тонкой, но сплошной линией Так, сказать, обозреть с высоты воробьиного полета.

Понравилась реплика госпожи Нефедовой о mySQL... Разрешите напомнить, что есть "реляционность": это всего лишь wrapper, оболочка, предоставляющая доступ к данным в терминах теории множеств, с использованием элегантных математически строгих операций этой теории. Поэтому те, кто привык к реляциям, на деле привык именно к упомянутой абстрактной модели данных. Как ни удивительно ( ), существуют и другие модели данных! В частности, ISAM, индексно-последовательный доступ к данным, родившийся во времена оно, когда компьютеры были большими. Если приподнять реляционное одеяло, то мы увидим голые ISAM-файлы.

К чему это? Да просто до мощных, промышленных RDB, все базы данных программировались, как ИСАМы. А это совсем другая методология и другая абстрактная модель данных! И другой набор операций над данными. И, нужно сказать, ИСАМ требует больше труда и изобретательности, хотя, в принципе, его возможности шире. Нужно опредилить состав записей, наборы ключей, по которым они будут индексированы, т.е. без четкого уяснения семантических и формальных (синтаксических) взаимосвязей результат определенно будет плачевным. В отличие от реляций, где простая (может быть автоматизирована, спасибо мат. модели) процедура нормализации практически гарантирует качество реализации БД. Все понятно: низкоуровневое средство (ИСАМ) по определению мощнее, но требует для достижения мощного результата больше труда и мастерства, чем качественно реализованная высокоуровневая оболочка. (Другой пример: ассемблер по сравнению с языками высокого уровня). И вот: тот, кому приходилось писать базы данных на обычных языках в файловой системе с помощью разных, поддерживаемых на уровне ОС методов доступа к файлам (в т.ч. ИСАМ), тот уже вообще ни на что никогда не жалуется!

Уважаемые, Лотус реализует ISAM-идеологию доступа к данным! Виды с категориями, отсортированные по первым нескольким столбцам, getDocumentByKey... Еще вопросы будут?

Второе. В документации к современным Лотусам этого нет, но в старых релизах очень хорошо прописывалась идеология работы пользователя. Это сейчас Лотус начал постепенно сползать неизвестно куда, но и теперь его насквозь пронизывает идеология "Офиса". То есть предполагается, что пользователь так же свободно создает свои базы, формы, виды, как и работает с электронными таблицами! И совершенно естественно, что для рядового пользователя не предусмотрены мощные хитромудрые средства, которыми нашпигованы т.н. профессиональные движки СУБД. Наверное это обстоятельство является определяющим по отношению к функционалу, доступному разработчику, и хорошо характеризует модель БД, принятую в Лотусе. Наряду с этим, Лотус реализовал системные сервисы, которые можно-таки считать образцом для подражания иных СУБД. Например, "родные" RTF поля выглядят чужеродными и неорганичными в реляционках. А чего вы хотели? Они не укладываются в мат. модель! Другой пример -- Лотус первая в мире СУБД, реализовавшая технологию клиент-сервер. Ну и так далее.

Словом, модель данных Лотуса простая, но низкоуровневая, а интерфейс пользователя и разработчика рассчитан на RAD режим эксплуатации, в стиле настольной автоматизации "своими руками", поэтому сравнительно беден и не удовлетворяет гуру, привыкшего месяцами "копаться" в навороченных "бэкэндах", совершая ему одному заметное шаманство. Как говорилось: "приходит пользователь и стоит над душой, пока я ему это не сделаю..." Но, Лотус в то же время работает на движке, который реализовывал и реализует потрясающие по силе и новаторству технологии, которые служат образцом в индустрии. Вот такая оценка ситуации.

Для: Fossil Code

Видно, что вы проанализировали множество различной информации.
Не накидаете ли ссылочек в тему?
Особенно по моделям данных.

Как ни жаль, ссылками помочь не смогу . Просто все, о чем говорил, является результатом не столько недавнего систематического изучения, сколько многолетнего результата более или менее бессистемного самообразования по ходу работы, и уже залегает на уровне подсознательных пережитков палеолита

Это был лишь пример реляционного подхода, который необходимо будет прогать в Lotus с довольно большими затратами времени на разработку и тестирование.

В данной конкретной задаче работа с Функциональной Должностью совсем не требует записи в трудовую, а нужна лишь в рабочих целях для разделения пересекающихся и часто меняющихся контуров ответственности.

Что касается трудовой, то там фиксируется именно организационная должность (штатная), и данные операции действительно нужно будет где-то в доп таблицах истории перемещений сотрудника фиксировать и проблем в реализации на РСУБД нет совсем.
Это лишь операция, которую нужно будет программить как в РСУБД, так и в Lotus (легче чуток)!!!
Но с РСУБД появится возможность применения средств построения отчетов как бонус

Для: GROMILA

На самом деле каждый стремится разрабатывать на том, на чем умеет.
А приходится - на чем имеет.

Так что вопрос хуже/лучше - он тупиковый изначально.
В любой среде минусы компенсируются плюсами. Иначе - кому нужна такая среда?

Я вас уверяю, что реальных проблем при реализации приведенного примера в лотусе гораздо меньше, чем вы описываете

Вот все теряют нити почему-то.
Я говорил не о проблемах, а о трудоемкости решения на Лотус довольно примитивных задач, которые в РСУБД решаются очень просто.
И тот факт, что в Лотусе можно быстро состряпать форму и кинуть туда поле не есть преимущество, так как скорее всего форму, представления и код прийдется быстро, но постоянно переделывать и тестировать на бедных пользователях.

Из моего опыта следует, что сделать надежную систему на C#+MSSQL будет гораздо быстрее, чем на Lotus!!!! и пусть не пугает работа со ссылками и графикой, все это решаемо!!!

И если IBM не почешется в сторону GUI и языка запросов в предсталвениях, Lotus так и останется ископаемым животным, дожившим до наших дней с дореляционного периода развития баз данных.

Надёжную систему чего ? может документооборота или деловодства?


брэд... он так и остаеться ископаемым и ископаеться дальше... вот уж скоро новый выйдет.... откопают из зазакромов.

Нет, имхо Лотус харош и исчо дого будет , так как многие задачи он делат луше других

Ну Вы же требовали пример. Вот и пример, который отражает, что прийдется в Лотусе писать код, аналогичный старым триггерам обновлений, коорые уже поддерживаются автоматом в РСУБД.

А если можете решить по-другому, то буду рад поучиться.




Еще как относится!!! Чел написал первое сообщение в откровенно пиарном стиле.
Это мне напомнило хвалебные статьи Лотусу, которые я читал в интернете прежде, чем начать его использовать и влип. Причем хвалят косвенно, применяя речевые обороты и т.п.

Вот почитает такое какой-нить новенький разработчик и подумает: авось привыкну, авось ломку пройду и будет мне счастье.

Мне болше всего нравится откровенная фраза на одном из форумов по лотус (дословно не помню):
"для тех, кто вынужден работать с этой корявкой, и кому нужна помощь"

вот.

Да, мне придётся строить что-то вроде тригеров. Но при чём тут общий реляционный подход?! Ведь я не буду заниматья нормализацией данных. Сущности у мя будут СОВСЕМ другими. Да, я буду писать "синхронизатор" данных. Ну, в реляционке это можно повесить на тригер. Но где ОБЩИЙ подход я не вижу в упор.

А теперь, раз уж на то пошло... Раз уж начинаем меряться этим самым...

Простая задача. Сделать одбласть для приаттачивания файла. За сколько я это сделаю на лотусе. А на реляционке? Мало того, файл бы неплохо и назад получить . Да ещё что б с кодировками какой лаже не произошло.

Опять же сокрытие информации. На Лотусе это делается влёт и нашару. Через Ридерс/Авторс поля. А в реляционке?

Та же репликация. В Лотусе она делается нараз и без дополнительных затрат. Пришёл на работу с ноутбуком, среплицировал базу на локал, пришёл домой, кнопки потыкал, вернулся на работу и среплицировал назад. И это влёт. Без дополнительных настроек и мУченья админов.

Есть прекрасная аналогия. Молоток и отвёртка. Молотком можно одуренно забивать гвозди. Но вот вкручивать саморезы не выйдет. Хотя, конечно, молотком можно вбить саморез. Но держать он будет оч. шатко. А отвёрткой прекрасно вкручиваются саморезы! Но оч. плохо вбиваются гвозди.


P.S. Может, вы просто не умеете на нём готовить, а? Может всё дело в том, что мыслите таблицами-запросами-транзакциями, а?

Для: GROMILA
Сочувствую, что не сложилось нормально разрабатывать в лотусе.

Я работала с Oracle + MS Access, потому что такая пара была стандартом на старом месте работы
Теперь работаю с Lotus, потому что это стандарт на новом месте.
Ей-богу, принципиальная разница лишь в уровне владения программным средством!

Кстати, из практики известно, что небольшая (не компьютерная) фирма не возьмет Oracle, даже если есть специалисты - она возьмет либо Access, либо MySQL. А вот если есть специалисты по лотусу, то может закупить лотус, так как это "не только ценный мех, но и 3-4 килограмма диетического мяса..."
А теперь представьте, что фирма развивается...
Вот то-то и оно-то!

Да ладно, браза, мы же одной крови

Я отдаю должное серверу Domino, репликации, почте и нотус-полям на формах
Иначе вообще каюк мне был бы, и Lotus не был бы распространен именно как
средненький (middleware) сервер

Только вот именно этих возможностей совершенно не достатчно для организации ДО на крупном предприятии или предприятиях!!!! Нужно применять и РСУБД обязательно, если нет, то будет тяжело.
Вот именно сейчас я и мучаюсь без РСУБД

Для: GROMILA
Почему не достаточно для ДО?
неправда, более чем.. вот для полной автоматизации предприятия, согласен , лотуса может не хватить, нужны будут РСУБД... но для ДО нормально, хватит.
Старая моя раота железная дорога, стоит лотус... везде и в большом количестве ))) и великолепна ... ДО летает и только на лотусе. Другие задачи отдельно, на РСУБД

Для: GROMILA
Все равно не убедили.
Вот один московский аэропорт (а может, и не один) живет на лотусе, а у них около 5000 пользователей, занимающихся самыми разными задачами, притом распределенные домены и проч. и проч...
Есть банки - вся система межфилиальных платежей на лотусе, по всей стране!
Да, они ругаются на писанные лотусистами системы. Но если б вы только слышали, каким матом ругаются на писанные ораклоидами!!! (не вру - сама много раз слышала )

Для полной автоматизации предприятия Лотуса может не хватить. Да. Но! Для полной автоматизации предприятия и РСУБД может не хватить .

А для ДО лотуса вполне хватит.

Ох согласен с Вами Елена... ох пропихиваеться щас в Киеве одна @# фирма оракловую систему ДО.... как грицца ужос н@#х....

Для: Morpheus

Почему же не сложилось, сложилось.
Я применил реляционный подход в лотусе и все стало на свои места, только попрогать пришлось, обидно, что все нужно руками программить: и триггеры и транзакции, чтобы не откатить, а все же завершить корректно операцию.
А тащусь от маршрутизации, которая действительно чисто лотусовская.


Согласен, еще плюс 1С стыренную !!!!



Это голословно!!!!
По моему опыту многие используют Echange + Outlook чисто для локальной и внешней почты, плюс задачи юзают, вот и весь ДО.
Фирмы торговые более крупные еще прикупают 1С8 + SQLServer (большинство проблем решают + ДО)
Мелкота дальше Access и Excel носа не суеть, ну и Outlook для интернета.

Lotus прикупают либо исторически (по наследству) либо по взаимовыгодной договоренности с прицепом