Философия программирования на Лотус

Всем привет от новичка в Лотусе, но не новичка в программировании !
С Лотусом знаком уже полгода и только сейчас дошли руки до его программирования (до этого только админил). Причем задачи у меня на него наполеоновские, т.к. на мой взляд нет ничего более подходящего чем Лотус для написания CRM-систем.
Но как программист реляционных баз данных я столкнулся с рядом принципиальных вопросов на которые хотелось бы получить ответ у бывалых Лотусистов. Вот один из них - как в Лотусе красиво реализовать ввод нового документа (счет или накладную) ? Проблем несколько:
1. Уникальность номера документа в условиях оффлайновой работы менеджеров (дома, во время командировок) и последующая синхронизация с серверной БД Лотуса. Например, в офисе менеджер выписал счет №1, 2 и 3, а в командировке №4 и 5. Вопрос - как этим номерам не пересечься с номерами документов, которые выписывались все это время в офисе ? Префиксами и суффиксами или еще как-то ?
2. Оптимальный способ хранения данных формы:
а) Каждый документ имеет шапку в которой хранится информация о клиенте и собственных реквизитах фирмы, которые в свою очередь хранятся в других документах. Так вот, как лучше хранить наименование и реквизиты фирмы и контрагентов, с помощью ссылок на документы или готовыми значениями ? В реляционых СУБД все решалось через ключи и вся информация для печатных форм затем собиралась одним запросом, а тут для первого случая приходится кучу документов в базе лопатить, а для второго случая избыточнось данных иметь жуткую.
б) Вторая часть любого документа это табличная часть, которая содержит, как правило, список проданых или купленных товаров, услуг. Если я правильно понимаю, то эта табличная часть должна быть лотусовской вьюхой которая содержит этот список, а каждая строка списка это отдельный документ, причем дочерний по отношению к нашему счету или накладной. Если все в моих рассуждениях верно, то как создать эти дочернии документы при формировании нового документа, в то время как родитель еще не сохранен и его еще в базе нет ?

0

<!--QuoteBegin-Gir+8:12:2005, 20:29 -->
<span class="vbquote">(Gir @ 8:12:2005, 20:29 )</span><!--QuoteEBegin-->1. Уникальность номера документа в условиях оффлайновой работы менеджеров
[snapback]28189" rel="nofollow" target="_blank[/snapback]?[/quote]

Для последовательности 1,2,3...... 5 6 в распределенных системах с непостоянным досьупом нет решения

Вывод генерировать уникальный номер
1. Автоматом функция @Unique в поле
2. Генерировать самостоятельно на основе не привязанных к проверке данных
Пример № состояит из компонетн
"Дата время" "Пользователь"
вариант 08.12.2005 19:49 Иван Петров
8C51EJ ИПОВ

3. Генерировать сквозной с привязкой к пользователю
34-ИП


По 2а :
Храни минимум по агенту + ту же реляцию (Код агента)
При печати собирай

По 2б
Для заполнения сделай несколько полей и при первом переноси в документы(ответы)

0

1. С номером документа я так примерно и думал поступить.
2а По этому вопросу как я понял - правильнее хранить только ссылки на документы. Но что означает фраза "по агенту + ту же реляцию" ?
2б А эти рекомендации я к сожалению ваще не понял... :unsure:

А можно изложить советы более содержательно или дать ссылочки по данным вопросам ?

0

хранение таблицы можно не только ответами делать. На вскидку - под каждую колонку отвести многозначное поле, хранить строку целиком в многозначном поле а значения разделять хитрым знаком(например %% или %$% ) опять таки в нотусе есть у каждого документа свой ID и можно не ответными а обычными документами хранить, сохраняя в них ID(у ответных просто есть свой геморой) . Все способы имеют достоинства и недостатки.

0

Сперва полюбопытствую

Причем задачи у меня на него наполеоновские, т.к. на мой взляд нет ничего более подходящего чем Лотус для написания CRM-систем.

Q1: Не могли бы Вы рассказать что именно на платформе Domino вызывает восторг для построения CRM???
Q2: Или что наиболее важно для CRM и на Domino это можно реализовать в кратчайшие сроки с должным качеством?

Теперь по Вашим вопросам

1. Уникальность номера документа в условиях оффлайновой работы

Мне больше всего нравятся префиксы в зависимости от пользователя

2. Оптимальный способ хранения данных формы:

а) (Документ.Поле ----- Другой документ. Много полей)

Я пришел к выводу, что нужно ориентироваться не на ключи-счетчики (1,2,3), а на конкретные данные (Иванов, Петорв, Сидоров). Нужно хранить именно ЗНАЧЕНИЯ, чтобы документ без тех других документов можно было юзать.
Ссылки лучше использовать в интерфейсе как способ быстрого открытия связанного документа, если же нужно программно найти документ, то лучше выполнить поиск!!! тут уже зависит от того как спроектируешь базу, а проектировать ее нужно не по ID, как в реляционках, а по именно Естественным Ключевым ЗНАЧЕНИЯМ.
Например:
Поле содержит: Иванов, МАРКЕТИНГ
Вот и нужно искать Иванов + МАРКЕТИНГ
Тут конечно все скажут, а где уникальность и т.д. Но есть же и табельные коды и номера контрагентов. Нужно задействовать именно естественные ключи, а не лотусовские универсальные ИД.
Замечу: иногда можно и UNID, но только если совсем нельзя.

И вообще, Лотус следует использовать не изолированно (большая ошибка), а в сочетании с другими серверами. Например, кто сказал, что нельзя использовать DOMINO+MSSQL? Или ФОРМА+ACTIVEX??? (Про WEB я пока молчу :()

б) Вторая часть любого документа это табличная часть, которая содержит, как правило, список проданых или купленных товаров, услуг.

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

Слово ДОЛЖНА не совсем корректно. Если нужен форум, то используй.
Сейчас я от EmbededView отказался бы, не зря его раньше не было.
Проблемы нарушения целостности, если начинать строить дочерние отношения, выливаются в дикое программирование, а CopyPaste чего стоит!!!!

Совет: Если нужна таблица, то:
1. Расположи на форме в Multivalue полях (попрограммить прийдется, но ...)
2. В боле сложных вариантах (строк много или аналитика намечается) слудет думать про связку ФОРМА+ГРИД<---->РСУБД.

Еще я советую проектировать интерфейс в Лотусе не по принципам Windows-приложений, а как на Web-сайте. Ну вот скажите, как Вы будете выводить таблицу на WEB-форме? Явно данные кто-то получит, сформирует HTML и выдаст вам на экран. У лотуса Web-направленность. И управление похожее, нечего ждать горячих клавишь для полей, все как в инете+мелкиедобавки.

Вот!

Просьба на мои вопросы тоже ответить :(

0

Почему именно Лотус для CRM-решения ?
Требования к CRM-системе у каждой организации могут быть различными, но когда эти требования максимальны, то Лотус это наиболее правильный выбор.
И вот почему:
1. Т.к. CRM это инструмент для работы менеджера, а современные менеджеры это люди с ноутбуками и разъезжающие на авто или находящиеся в бесконечных командировках, то они должны всегда иметь под рукой всю свою клиентскую информационную базу, и уметь обслужить клиента где-угодно и когда-угодно (заполнить карточку клиента, заключить договор, выписать счет ...). После приезда в офис все сделанные наработки конечно же должны оказаться в центральной базе корпорации.
С помощью Лотуса и его репликаций это требование можно выполнить довольно просто (мне так кажется, по крайней мере ).
2. Любая уважающая себя CRM-система должна влючать в себя почтовый клиент, что позволит менеджеру:
а) производить массовые рассылки
б) не переключаться между программами (почтовиком и информационной базой) и работать в едином информационном пространстве
в) к любому документу приаттачивать файлы или добавлять ссылки на другие документы (например, к счету приаттачить или Экселевский файл заявки на отгрузку, который прислал клиент по почте, или факс в виде tiff-файла, который пришел на факс-сервер от того же клиента)
3. Органайзерские возможности Лотуса тоже можно принять во внимание
4. Современный CRM должен допускать возможность клиенту самому участвовать в бизнес-процессах компании (collaboration). При этом я себе представляю как клиент на веб-сайте сам готовит какие-нибудь заявки, на основании которых менеджеры выписывают счета, которые в свою очередь становятся видны данному клиенту, затем ему становится виден статус счета об оплате и т.д и т.п... Т.е. клиент становится в курсе всех событий которые происходят в компании с его фирмой и заказами. Думаю, что качество обслуживания клиента от этого только улучшается, да и сам клиент меньше морочит голову людям.
Web-направленность Лотуса огромный плюс в данном контексте.
5. Все что было сказано выше может шокировать отделы безопастности многих организаций, но Лотус на мой взляд имеет все необходимые средства, чтобы обеспечить надежную сохранность и защищенность данных. Файлы баз данных - криптуются, документы тоже, механизм раздачи прав на документы существует, для веб-клиентов есть SSL сертификаты, существует поддержка smartcard.

0

И вообще, Лотус следует использовать не изолированно (большая ошибка), а в сочетании с другими серверами. Например, кто сказал, что нельзя использовать DOMINO+MSSQL?

Я прекрасно понимаю, что в серьезных приложениях без реляционных баз данных скорее всего не обойтись, но как же тогда организовать рабочее место для оффлайновой работы ? Чисто Лотусовская апликуха прекрасно будет работать как в офисе так и вне его, а благодаря репликации все замечательно потом синхронизируется. Но как только мы сюда подмешаем еще и какой-нибудь MSSQL, то организация мобильно-оффлайнового рабочего места значительно усложняется !!! Это ж прийдется на клиенте устанавливать еще один сервер - сервер базы данных, да и настраивать еще одну репликацию... Вижу, что тут попахивает уже использованием DB2... Или я не прав ?

0

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

Эх, сладкое слово репликация, воспетое многими. А Вы точно знаете какие возможности по синхронизации данных предоставит лотус Вам?????
Советую сделать мелкий прототип и провести испытание нужной Вам конфигурации + восстановление после сбоя (помнить о CopyPaste).

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

Ну, надо просто не бояться, и все получится! Сервер на клиенте не прийдется устанавливать, есть же Десктоповские релизы. Причем нужно четко представлять какие сущности Вы хотите хранить в РСУБД, а какие в Domino.
Дальше продолжать не стану, а то меня начнут обвинять, что Лотус мне не нравится.

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

Спасибо что удовлетворили мое любопытство.
Если у Вас есть ТЗ на вашу систему, то можем обсудить.

0

Ну раз без реляционок никак не обойтись, то, пожалуй, действительно лучше всего реализовать приложение как чистое Web-решение (и свести все к обычному IE). При таком раскладе менеджеры тоже смогут получать доступ к информации, выполнять свои обязанности и обслуживать клиентов повсюду, где имеется Интернет конечно (хотя с помощью GPRS инет можно иметь практически всегда, правда качество пока ...).
Классно, конечно, что ИБМы DB2 к Лотусу прикрутили, но если я правильно понимаю, то нет особой разницы как с данными работать из скриптов - с DB2 или MSSQL ? Или все-таки проще ?

Если у Вас есть ТЗ на вашу систему, то можем обсудить.

У меня тоже проскакивала мысля об OpenSource проекте под знаменами которого можно было бы разработать довольно приличную систему. Думаю, что если перед нами стоят общие задачи, то можно объединить усилия...

0

Ну есть же еще такое понятие как стоимость лицензий на СУБД и стоимость владения (TCO) всем этим хозяйством - думаю что все будет значительно дороже моноплатформы.

насчет CRM - так там вроде и нет миллионов записей - зачем огород городить. Хотя может мы по разному понимаем состав системы... В наших проектах (согласен что клиенты средние по величине) 10-100 тысяч актуальных записей в CRM со скоростью обновления до 100 документов в день. Это вполне тянут однопроцессорные сервера

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

Ну раз без реляционок никак не обойтись, то, пожалуй, действительно лучше всего реализовать приложение как чистое Web-решение (и свести все к обычному IE).

Ну, скажем так, в правильном направлении мыслите, но мне лично только WEB не нравится. Вы выиграете для интернет-пользователей, но проиграете для Intranet-пользователей. Я заметил, что многие Web-системы требуют присутствия на локале своих компонентов, совсем чистеньким IE дело не обойдется.
Применение Лотуса вполне эффективно, но не при работе с реляционными сущностями! Нужны требования!
Ну, попробую выделить три хотения бизнеса:
1. Куплен WEB-хостинг, скажем под Winodws, и директор в интернет-кафе дрючит CRM-менеджеров :huh:
Domino автоматом отпадает!!! И сразу открывается море возможностей, где очень легко заблудиться. Я бы выбрал VStudio2005.NET
2. Куплен сервер и по выделенке высунут в Internet и директор дрючит CRM-менеджеров только через NoteBook
Domino в принципе можно применять, но я почему-то быстродействующих и красивых сайтов на Domino не бачыу (видел)
3. Есть разветвленная сеть и директор дрючит CRM-менеджеров только из кабинета
Domino+РСУБД=IMHO
За какую из этих возможностей директор заплатит вам деньги????

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

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

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

Лотусу - Лотусово, а Реляционову - Реляционное.
Моноплатформа ограничит много чего.

0

Отмечу что ТСО включает и стоимость сопровождения системы за время ее жизни. ИМНО ТСО у Open Source пока выше чем у многих небесплатных платформ именно за счет высокой стоимости поддержки и трудностей связанных с отсутствием гарантированной поддержки производителя.

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

На самом деле, сравнивать Домино с реляционными СУБД для построения CRM - это все равно что сравнивать чай с кофе для распития за ужином, например. Это глупо и не нужно совсем, потому что эти платформы заняли свои ниши на рынке, который формировался десятки лет под воздействием объективных экономических законов, под влиянием потребностей бизнеса, обе из этих платформ решают свои задачи вполне приемлемо, что доказывается многомиллионной армией пользователей обеих платформ по всему миру.

VZH
По поводу Предсказуемости и ТСО продолжать не буду, свой взгляд я уже изложил, и истина где-то между Domino и Реляционкой B).
Ответьте на вопросы GIR-a с Вашей точки зрения, а то мы отклоняемся от темы!!!

Nor Привет!!!
Я не сравниваю Domino и РСУБД, перечитай мои постинги, а то пойду по циклу ;)
Тебя тоже прошу ответить по существу вопросов GIR-a.

0

<!--QuoteBegin-nor+15:01:2006, 21:24 -->
<span class="vbquote">(nor @ 15:01:2006, 21:24 )</span><!--QuoteEBegin-->На самом деле, сравнивать Домино с реляционными СУБД для построения CRM - это все равно что сравнивать чай с кофе для распития за ужином, например. Это глупо и не нужно совсем, потому что эти платформы заняли свои ниши на рынке, который формировался десятки лет под воздействием объективных экономических законов, под влиянием потребностей бизнеса, обе из этих платформ решают свои задачи вполне приемлемо, что доказывается многомиллионной армией пользователей обеих платформ по всему миру.
[snapback]29338" rel="nofollow" target="_blank[/snapback]?[/quote]

Сравнение касалось вариантов Lotus и Lotus+RDB при создании 1 приложения класса CRM. Я выступаю за чистый продукт. Воспользовавшись Вашей аллегорией - я за кофе, вместо "кофечая".

<!--QuoteBegin-GROMILA+17:01:2006, 06:37 -->
<span class="vbquote">(GROMILA @ 17:01:2006, 06:37 )</span><!--QuoteEBegin-->VZH
Ответьте на вопросы GIR-a с Вашей точки зрения, а то мы отклоняемся от темы!!!
[snapback]29395" rel="nofollow" target="_blank[/snapback]?[/quote]

1. Уникальность номера документа в условиях оффлайновой работы менеджеров (дома, во время командировок) и последующая синхронизация с серверной БД Лотуса. Например, в офисе менеджер выписал счет №1, 2 и 3, а в командировке №4 и 5. Вопрос - как этим номерам не пересечься с номерами документов, которые выписывались все это время в офисе ? Префиксами и суффиксами или еще как-то ?

неплохой вариант (мы уже используем лет 5) - номер основаный на 2 параметрах: абревиатуры от имени и времени создания.

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

лотус домино приниципиально избыточная система - не надо этого боятся - все часто требуемые и редко обновляемые поля рекомендую разместить в зависимых документах.

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

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

<!--QuoteBegin-VZH+17:01:2006, 17:36 -->
<span class="vbquote">(VZH @ 17:01:2006, 17:36 )</span><!--QuoteEBegin-->неплохой вариант (мы уже используем лет 5) - номер основаный на 2 параметрах: абревиатуры от имени и времени создания.
[snapback]29432" rel="nofollow" target="_blank[/snapback]?[/quote]

@Unique без параметров в поле

<!--QuoteBegin-VZH+17:01:2006, 17:36 -->
<span class="vbquote">(VZH @ 17:01:2006, 17:36 )</span><!--QuoteEBegin-->В реляционых СУБД все решалось через ключи и вся информация для печатных форм затем собиралась одним запросом
[snapback]29432" rel="nofollow" target="_blank[/snapback]?[/quote]
Для избыточных показателей тоже можно использовать реляцию

По опыту скажу что варианты симбиозов оправданы только в тройном сожительстве

Lotus<->РСУБД<-> АРМ
гдк АРМ системы использующие списки или заточенные под определеные хранилиша к примеру системы Биллинга, Банкоские системы управления счетами клиентов

РСУБД - "продвигает"(улутшает) нотес только при условиях:
- большого количества записей от 1 000 000
- наличия кодов обработки и аналитики для данных (т.е. уже написано или есть подсистема)
- ограничения на платформу хранения данных (т.е. выбрали Оракл и все хоть застрелись)


<!--QuoteBegin-GROMILA+14:01:2006, 00:08 -->
<span class="vbquote">(GROMILA @ 14:01:2006, 00:08 )</span><!--QuoteEBegin-->но я почему-то быстродействующих и красивых сайтов на Domino не бачыу
[snapback]29296" rel="nofollow" target="_blank[/snapback]?[/quote]

Если взять соотношения сайтов(плохих и хороших) на домино и не на домино, то лотус выигрывает.
Сори за метафору но я "тоже мало видел красивых девушек, которые хорошо водят КРАЗы"

**По просторам СНГ и Балтии я нособирал около 1000 сайтов и все!

Могу высказать только свое мнение по сему поводу
"Самая короткая дорога , та которую знаеш" "Самый лутший автомобиль тот, который едет"

0

Ну в принципе можно сказать, что ответы на свои вопросы я получил. Конечно кое-какие детали по реализации мне пока не ясны, но это уже предмет других тем на форуме. Что же касается обсуждения на тему чистый Лотус или Лотус + Реляция, то при всей моей симпатии к реляционым СУБД мне кажется, что первое решение все же предпочтительнее. Так вот недавно скачал CRM от iEnterprises (www.ienterprises.com) и пришел к выводу, что при разработке можно обойтись одним Лотусом и при этом получить на выходе очень даже интересный продукт.
И еще одно. Раз уж тема у нас философская, то хотелось бы узнать мнение общественности и на чем лучше реализовать CRM проект ? Мне почему-то кажется, что идеальным было бы сделать все на Яве, а не на Лотус скрипте и языке формул, тем более, что я где-то читал, что ИБМы собираются от от них отказываться (хотя и очень не скоро). Таким образом интерфейс пользователя и в Notes и на вебе будет единообразным, более функциональным и приятным.

И ваще, братцы, если перед кем-то стоит подобная задача, то давайте объединим наши усилия - "Гуртом и батьку бить легче"!

0

<!--QuoteBegin-Gir+17:01:2006, 20:04 -->
<span class="vbquote">(Gir @ 17:01:2006, 20:04 )</span><!--QuoteEBegin-->И ваще, братцы, если перед кем-то стоит подобная задача, то давайте объединим наши усилия![/quote]
Подобные задачи стоят в той или иной степени у многих.
Порыв мне нравится, но нужно ТЗ, иначе даже и обсуждать нечего.
Причем ТЗ нужно от Вас, GIR.
Коллективное написательство ТЗ я слабо представляю.

Далее народу будет либо интересно, либо нет.
Если интересно, то дадут Вам парочку консультаций.

А дальше видно будет

0