Версия для печати темы

Автор: Fossil Code 29:11:2006, 10:56

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

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

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

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

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

Вот.

Автор: Mihal 29:11:2006, 13:43

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

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

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

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


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

Автор: GROMILA 29:11:2006, 14:29

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

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

Автор: Fossil Code 29:11:2006, 14:42

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

Автор: Mihal 29:11:2006, 14:50

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

Автор: Morpheus 29:11:2006, 14:58

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

Автор: Fossil Code 29:11:2006, 15:00

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

Автор: Mihal 29:11:2006, 15:14

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

Автор: Morpheus 29:11:2006, 15:19

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

Автор: Fossil Code 29:11:2006, 15:27

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

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



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

Автор: Mihal 29:11:2006, 15:47

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

Автор: GROMILA 29:11:2006, 16:01

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

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

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

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

Автор: Mihal 29:11:2006, 16:08

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


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

Автор: GROMILA 29:11:2006, 16:45

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

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

Автор: GROMILA 29:11:2006, 16:58

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

Автор: LuMee 29:11:2006, 20:27

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

Автор: Morpheus 30:11:2006, 07:16

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


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

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


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

Автор: Fossil Code 30:11:2006, 07:26

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

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

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

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

Автор: Mihal 30:11:2006, 07:34

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

Автор: Constantin A Chervonenko 30:11:2006, 08:21

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

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

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

Автор: GROMILA 30:11:2006, 08:41

Для: Constantin A Chervonenko

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

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

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

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

Автор: Fossil Code 30:11:2006, 09:00

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

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

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

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

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

Автор: LuMee 30:11:2006, 10:00

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

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

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

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

Автор: Morpheus 30:11:2006, 10:14

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

Автор: LuMee 30:11:2006, 13:09

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

Автор: Constantin A Chervonenko 30:11:2006, 13:26

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

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

Автор: Mihal 30:11:2006, 13:48

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

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

Автор: Constantin A Chervonenko 30:11:2006, 13:56

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

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

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

Автор: Elena Nefedova 30:11:2006, 15:19

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

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

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

Автор: GROMILA 30:11:2006, 15:40

Пожалуйста.

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

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

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

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

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

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

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

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

Автор: Elena Nefedova 30:11:2006, 15:40

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

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

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



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

Автор: Mihal 30:11:2006, 15:48

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

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

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

Автор: Elena Nefedova 30:11:2006, 15:58

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

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

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

Автор: Fossil Code 1:12:2006, 07:34

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

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

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

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

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

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

Автор: Elena Nefedova 1:12:2006, 08:32

Для: Fossil Code

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

Автор: Fossil Code 1:12:2006, 08:49

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

Автор: GROMILA 1:12:2006, 09:13

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

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

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

Автор: Elena Nefedova 1:12:2006, 09:28

Для: GROMILA

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

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

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

Автор: GROMILA 1:12:2006, 10:58

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

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

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

Автор: Morpheus 1:12:2006, 11:01

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


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

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

Автор: GROMILA 1:12:2006, 11:36

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

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




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

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

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

вот.

Автор: Mihal 1:12:2006, 12:04

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

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

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

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

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

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


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

Автор: Elena Nefedova 1:12:2006, 12:28

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

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

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

Автор: GROMILA 1:12:2006, 12:33

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

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

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

Автор: Morpheus 1:12:2006, 12:41

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

Автор: Elena Nefedova 1:12:2006, 12:44

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

Автор: Mihal 1:12:2006, 12:45

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

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

Автор: Morpheus 1:12:2006, 13:11

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

Автор: Elena Nefedova 1:12:2006, 13:16

Для: Morpheus

Автор: GROMILA 1:12:2006, 13:33

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


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



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

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

Автор: Mihal 1:12:2006, 13:39

Не сложилось . Простите, а сколько пользователей с базой работают?

Автор: GROMILA 1:12:2006, 13:41

На мой взгляд самая достойная система на Oracle - DWARF, разработки БГУИР (МРТИ)
Она местами имеет плохенькие иконки, но функции ПОРАЖАЮТ своей продуманностью и быстродействием!!! Подобного на лотусе никогда не достигнуть!!!
И тодже работает в аэропортах

Автор: Mihal 1:12:2006, 13:44

Отнють не голословное утверждение .

Автор: Fossil Code 1:12:2006, 13:45

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

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

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

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

Сказанное, считаю, опровергает Вашу реплику, о непригодности Лотуса "в крупных формах". Не думаю, чтобы Вы оценивали IBM, как "мелкую фирму эпохи Аллы Пугачевой", а ведь Лотус там -- корпоративный стандарт.

Автор: GROMILA 1:12:2006, 13:46

Всего тысенца, а цо? одновременно не знаю, надо полюбопытствовать.
Почему с базой? с базами

Автор: Morpheus 1:12:2006, 13:48

Ложь, л@#;жь и провокация.. прошу простить за мой франзуский

поверте.. вовсе НЕТ. по крайней мере в Киеве, да и в Украине в целом... а прицеп ВВам и в Оракле и в 1с втулят...
Грамотные решения на лотусе, тотже БР(канечно доведённый до ума, год работ и всё такое) предприятия берут... Вы должны знать такую фирму как It и её дочурку Aplana и ещё куча фирм с другими лотусиными решениями в Киеве , в Украине, России.. и всё это вовсе не потому что лотус берёт ктото по наследству..

Автор: Mihal 1:12:2006, 13:56

Да просто если Вы будете мыслить реляционно и делать заменители транзакций, то у вас во-первых, всё будет медленно работать, во-вторых, начнут вылазить со всех сторон конфликты сохранения.

Автор: Elena Nefedova 1:12:2006, 13:57

Все разговоры об "историческом наследии" не имеют под собой никаких оснований.
Ну вот у вас историческое наследие - MS Access. А объемы выросли немеряно.
Ну и что вы будете делать? - будете менять систему. На что - другой вопрос.
А лотус менять в этом случае просто не нужно.


ЗЫ: такое впечатление, что из постов читается по паре строк. Я лишь говорила о том, что может или не может купить небольшая фирма при соответствующих обстоятельствах! а не о том, кто сколько купил или украл софта...

Автор: GROMILA 1:12:2006, 14:00

Для: Fossil Code

У меня не неприязнь к лотусу, а неприязнь к тем, кто его хвалит, прямо или косвенно!!!!
Ибо это расцениваю как дезинформацию.

Автор: Fossil Code 1:12:2006, 14:04

Ох, кто про Фому, а кто - про Ерему... Ну нельзя применить реляционный подход в Лотусе, потому, что там нет реляций! Вы применили в Лотусе то, чему научились в РДБ, а это уже другой вопрос.

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

Автор: Elena Nefedova 1:12:2006, 14:08

Все-таки Михал был прав про молоток и отвертку...

Наша компания - не смейтесь - продает ПО, написанное на Oracle!!!
Тут есть реально крутые ораклоиды!

НО! - весь внутрикорпоративный ДО, включая и подготовку поставок для клиентов, у нас на лотусе.
Еще есть вопросы?

Автор: Morpheus 1:12:2006, 14:10

Для: GROMILA - аналагична, без обид. Просто интереснейшая ветка получилась Приятно почитать подескутировать. Но вот это дискусия превращаеться в обсуждения вроде nVidia VS ATI
Pentium VS AMD и т.д. Вы я так понимаю больше приверженец РСУБД, это видно из

посему Вы и будете считать Лотус не подходящим и т.д.

Всем желаю отлично отдохнуть на выхадных

Автор: Fossil Code 1:12:2006, 14:11

Уж если это не неприязнь, и даже не откровенное отвращение, к Лотусу, да еще перенесенные на тех, кто Лотусом доволен и осмеливается открыто обсуждать его достоинства...

...Тогда я совершенно не понимаю ни русского языка, ни людей. Ни в малейшей степени.

Автор: GROMILA 1:12:2006, 14:19