Здравствуйте, являюсь студентом. Есть нужда с проектировать приложение на Лотусе 8.5. Есть опыт и методика проектирования Реляционных БД. Но тут мой мир перевернулся, когда столкнулся с Лотусом.
БД как таковой нету, думал она похожа на Каше, с классами работать придется... Сейчас мне советуют делать БД реляционную и цепляться к Лотусу.
Но мне очень хочется сделать по нормальному, с внутренними ресурсами лотуса, и прямым проектированием...
Помогите советом, как проектировать БД в лотусе, и стоит ли заморачиваться?

Ознакомился, пригодилась только информация об Workplace Designer, но он не далек от Domino Designer. А по поводу проектирования так и не нашел не чего.

GarrickMaksimaL88Ознакомился, пригодилась только информация об Workplace Designer, но он не далек от Domino Designer. А по поводу проектирования так и не нашел не чего.
А в чём проблема-то? Там всё проще пареной репы. Просто многие впадают в ступор и панику от того что оно не реляционное. А на самом деле всё очень просто, главное "въехать". Рисуйте формы в дизайнере, затем представления (view) и всё готово. Ну и не забыть сделать кнопочку "Создать новый документ", а то с наполнением базы будут проблемы. В общем, главное начать, а там само попрёт. Хелп у Domino Designer достаточно информативный, с примерами, плюс "Ред Буки" всякие, например - Domino Designer 6: A Developer's Handbook

Спасибо. Но проблема не с реализацией.


Vincent VegaVincent Vega,

Может озвучить ваше ТЗ, возможно тогда сможем помочь более конкретными советами

ТЗ как раз так пишу (дипломная работа), пока что не могу определиться с СУБД. Т.е. если на Лотусе можно проектировать БД, обычно схема которую спрашивают для реляционных систем с меня это:
-IDEF0
-DFD
-ERD
-IDEF1X
-физическая модель БД
или UML для ООП.
Уклон на проектирование а не реализацию.

На ibm в статье прочитал "Так вот, ни по организации данных, не по средствам поддержания взаимосвязей между объектами, система Lotus Domino совершенно не реляционная. Вероятно наиболее точное определение её может звучать как документарная." ( http://www.ibm.com/developerworks/ru/library/ls0609-moskvin/index.html) Текст выдернут из контекста, но, как я понимаю, она даже не объектная.
Проектировать нечего, тупо вбиваешь в формы первичные документы, а на представлениях потом делаешь что тебе надо, не какой запарки с нормализациями и наследованиями нету.

p.s. Разрабатываемая система, должна выполнять задачу так называемую инвентаризацию (средств вычислительной техники и активного сетевого оборудования. Столы и стулья и прочее не трогаем) , на деле, каждый квартал, по отчетам/актам/заявкам о списсаной/поставкам нового/ремонте техники вносится корректировки в итоговый отчет, который система тоже должна выводить.
Хочу на лотусе, ибо лотус внедрен на предприятии, правда ЭЦП не внедрены. Помимо этого пользователи должны уметь со своих рабочих мест, делать заявки о не работающем оборудовании и т.п. Отчетность для пользователей с правами, и ещё что нибудь. Тут либо довольно избитый вариант для меня MySQL + PHP , но хочется на лотусе, ибо он внедрен, и подкрутить к системе служебные записки, и попытаться внедрить ЭЦП для внутреннего документооборота. Но для этого мне нужно новую схему проектирования...

MasterZivЭто не так и плохо, как может показаться.
Например, интегрировать почту лотусову с WEB-интерфейсом на чём угодно.
Я думаю, это будет проще.

Хм. Т.е если прикрутить РСУБД к Лотусу , а интерфейсы и веб приложение сделать в XPAGES это будет на уровне?
Или лучше php+mySQL , и уже тут крутить базами лотуса (данные пользователей почты и т.п), лучше выгружать их (базы лотуса) в мускл, сделать синхронизацию, или не дублировать базы лотуса в базу мускла?
*(не вникал пока что в их (xpages) разработку и функционал, но насколько понимаю, это просто новая технология которая позволяет сделать более красивый и функциональный интерфейс. Который будет доступен через клиент Лотус нотес, и прямой ссылкой из браузера?)
___________
GarrickА вот для подведения всяких итоговых результов, сбора статистики, сведения балансов и пр. вычислительной ерунды Lotus Notes как раз и не годится. Сами понимаете никаке SELECT FROM... WHERE тут не прокатят. Сбор данных будет трудным, долгим и утомительным. Другое дело полнотекстовый поиск... оболочку для ситемы типа "Гарант" или "Консультант+" можно написать за пару часов.

Ещё не сталкивался с проблемами которые нельзя реализовать с помощью запросов, хоть мои системы, их и системами не назвать, максимум 20 таблиц, нормализованных до 3НФ Бойса -Кодда. Самый трудный запрос с которым сталкивался это перекрестный + left join (если не ошибаюсь).
А зачем писать оболочки, если эти системы уже есть и внедрены повсеместно? В каких случаях нужно делать подобное?
"Сбор данных будет трудным, долгим и утомительным. Другое дело полнотекстовый поиск... " расскажите поподробней пожалуйста.
_________
GarrickВсё правильно, примерно так это всё и выглядит. Создаёшь в дизанере форм форму твоего документа (заявки), примерно как HTML верстка (таблицы для красоты и вякое такое). Создаёшь представление, как ты хочешь, что бы эти документы (заявки) отображались списком. Чаще всего несколько разных представлений. И в принципе всё. Но дальше самое интересное - заявка должна пойти по этапу. Делаешь кнопки "Согласовано", "Не согласовано", при нажатии на кнопку документ меняет статус (любое поле в документе, отображающее его статус) и отправляется e-mail следующему участнику процесса с просьбой согласовать документ и ссылкой на него. При достижении последнего статуса автору отправляется e-mail, что всё готово. Соответствующий же e-mail отправляется автору если кто-то нажмёт кнопку "Не согласовано". В реальных системах, конечно, всё более закручено и заморочено + ещё права доступа всякие. Это, собственно, и называется электронный документооборот. Никаких схем баз данных, UML и пр. в Лотусе обычно не рисуют - нет смысла, а вот Workflow и BPM схемы сплошь и рядом.
В моём понятие, проектирование, должно помогать разработки БД, предшествовать созданию её реализации. Чтобы можно было спокойно ориентироваться по базе, и подключать к этому сторонних людей, прочитавших документацию (это самое проектирование). Я написал " Проектировать нечего, тупо вбиваешь в формы первичные документы, а на представлениях потом делаешь что тебе надо, не какой запарки с нормализациями и наследованиями нету." Просто мне нужна новая методика для проектирования на лотусе приложений, если такое вообще есть, и надеюсь то я порю не чушь (" Но для этого мне нужно новую схему проектирования...")
На сколько я понял Workflow ( http://ru.wikipedia.org/wiki/Windows_Workflow_Foundation) , это попытка стандартизации применения диаграмм UML?
p.s. В Лотусе вроде есть встроенный функционал согласования, наподобие конференции.

В Lotus Domino 7 предоставлена возможность использования DB2 в качестве хранилища данных. Данная функциональная возможность позволяет вам использовать обе базы данных (DB2 и Domino), получая доступ и просматривая данные, хранящиеся в обоих форматах. Это дает возможность использовать лучшее из DB2 и Domino в вашей среде. Пользователи Notes получают доступ к возможностям DB2, таким как реляционные структуры и виды, основанные на языке SQL (System Query Language). Пользователи DB2 могут воспользоваться возможностями Domino, такими как репликация и защита.
( http://www.ibm.com/developerworks/ru/library/domino7-db2/)
Пока копаюсь дальше, но сикуль то есть в лотусе! Чтож так пугать...

На сколько я понял. Данные из Лотуса дублируются в БД db2, и при изменении синхронизируются, т.е база растет не хило. База по сути является одной табличкой, компонентом DAV (DB2 Access View). В моей системе надо сделать отчет по итогом инвентаризации, т.е мне надо будет хранить в этом DAV абсолютно всю инфу для отчета?
По сути эта статья для версии 7 лотус, может быть в 8 лотусе как то более продумали "реляционное управление Domino-данными", помимо возможности скл запросов, путем не хилого увеличения размера хранимой информации?

p.s
"
Прежде чем поместить какие-либо Domino-данные в DB2 Query View в Lotus Notes Client, вы должны создать DAV . В DAV в качестве записей должны быть созданы те же поля, которые будут отображаться в столбцах вида. DAV используют много места, поскольку каждый DAV дублирует данные в базе данных, поэтому рекомендуется иметь один (или очень мало) DAV, содержащий все необходимые поля для различных Query View.
"

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


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

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

________
GarrickMasterZivТолько вот как он отчёты будет делать...

Э-э-э-э-э! Товарищ про проектирование интересовался. Про отчёты это другая тема.

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