IBM идет по верному пути, объединяя возможности LND и DB2. Если в итоге можно будет столь же легко (или почти столь же легко) создавать приложения на платформе LND + DB2, как на LND, то это только расширит сферу применения LND.

 

Как раз дело даже больше не в каналах, а в том, что бизнес-процессы меняются постоянно.

Не.. Если не рваные каналы: ведем ровно ОДНУ копию приложения на общедоступном сервере - и no problem! Централизация - универсальный подход (где каналы позволяют)

IBM идет по верному пути, объединяя возможности LND и DB2. Если в итоге можно будет столь же легко (или почти столь же легко) создавать приложения на платформе LND + DB2, как на LND, то это только расширит сферу применения LND.

Опасное заблуждение. Ты смотрел, что там получается? Эта связка (так, как оно делается) способна только дискредитировать Домину.
Данные Домины СУБД хранит в неструктурированных BLOBах. Так что SQL-запросом ты их от туда не достанешь
Что-бы запросы заработали, надо стапически расписывать маппинг объектов СУБД на Домино, т.е. структурировать доминошные данные. Т.о. основное преимущество модели данных LND (способность работать с неструктурированной информацией) девальвируется
Ну и??
1.Если уж разработчик сумел провернуть этап нормализации (структурирования) данных, но наф ему Домино?? СУБД будет уместнее
2.Чем эта интеграция принципиально отличается от DECS (там тоже статический маппинг)? Только привязкой к единственной СУБД (DB/2, причем НЕстандартной, spec.edition)?

 

Не.. Если не рваные каналы: ведем ровно ОДНУ копию приложения на общедоступном сервере - и no problem! Централизация - универсальный подход (где каналы позволяют)

Разве LND в этом случае плох? Можно работать и централизованно. Распределенный склад - это вообще немыслимо.

Опасное заблуждение. Ты смотрел, что там получается? Эта связка (так, как оно делается) способна только дискредитировать Домину.
Данные Домины СУБД хранит в неструктурированных BLOBах. Так что SQL-запросом ты их от туда не достанешь
Что-бы запросы заработали, надо стапически расписывать маппинг объектов СУБД на Домино, т.е. структурировать доминошные данные. Т.о. основное преимущество модели данных LND (способность работать с неструктурированной информацией) девальвируется
Ну и??
1.Если уж разработчик сумел провернуть этап нормализации (структурирования) данных, но наф ему Домино?? СУБД будет уместнее
2.Чем эта интеграция принципиально отличается от DECS (там тоже статический маппинг)? Только привязкой к единственной СУБД (DB/2, причем НЕстандартной, spec.edition)?

1. Прототипирование на LND, использование LND, когда нужно быстро подстраиваться под изменяющиеся бизнес-процессы. Когда всё устаканилось, переход на РСУБД, но сохранение прежнего UI, так как привыкли уже все и нет смысла переучивать, писать новые инструкции.

2. DECS - говно. Работает только в одну сторону, в сторону РСУБД. Вообще это не гибкий инструмент.

3. IBM® Lotus® Domino(tm) Designer includes two types of design elements to assist you in managing data contained in DB2 enabled IBM® Lotus® Notes® databases:

• A DB2 Access view (DAV) is a shared resource that lets you define a DB2 view of Notes data. DAVs enable you to leverage the data that is stored in DB2. While the DAV actually exists in DB2, it is accessible by both Domino and non-Domino applications.
• Query view - another type of NSF view, this view is populated by using the SQL language queries. If you want to create a query view based on data in a Notes database that resides in DB2, you must first have defined and populated a DAV.

A Notes database typically includes many different types of notes. When you enable a Domino server for DB2, Domino stores its Notes data in DB2. A DB2 database consists of multiple tables that are composed of columns and rows. Data in DB2 databases is accessed and manipulated through Structured Query Language (SQL) statements.

Once the DAV is created, any subsequent changes made to the Notes data will immediately be visible in DB2. Any changes to the notes made using SQL will immediately be visible in Notes (you may need to refresh the Notes view to see change in the Notes client).

Так что речь похоже не про BLOBы, раз: "A DB2 Access view (DAV) is a shared resource that lets you define a DB2 view of Notes data" Вот, кстати: "The DAV makes the data available directly by SQL. Third-party applications that use Open Database Connectivity (ODBC) can read the data."
А созданные в DB2 таблицы, видимо, тогда можно и связать между собой. Сам не пробовал пока что. Может кто уже изучал на практике? Поделитесь опытом, пожалуйста.

 

Разве LND в этом случае плох? Можно работать и централизованно. Распределенный склад - это вообще немыслимо.

Конечно плох. Транзакции нет; взаимных исключений нет; ссылочной целостности нет; правил декларативной целостности нет .. etc
Это все неотъемлимые св-ва приличной СУБД, невозможные в распределенной среде. Если уж централизация - так использовать её по максимуму

1. Прототипирование на LND, использование LND, когда нужно быстро подстраиваться под изменяющиеся бизнес-процессы. Когда всё устаканилось, переход на РСУБД, но сохранение прежнего UI, так как привыкли уже все и нет смысла переучивать, писать новые инструкции.

Это - да. LND - как всякой бочке затычка. Успешно использую. Только без перехода на СУБД. Зачем, раз всё работает??

2. DECS - говно. Работает только в одну сторону, в сторону РСУБД. Вообще это не гибкий инструмент.

Блин... Придираешься к словам.. В ПРИНЦИПЕ то что?! Ну, скажи "гибрид LEI и DECS". Сила LND в том, что ДО разработки не надо нормализовать данные. А СУБД-прикладуха без этого этапа - самоубийство

Так что речь похоже не про BLOBы, раз: "A DB2 Access view (DAV) is a shared resource that lets you define a DB2 view of Notes data" ...
А созданные в DB2 таблицы, видимо, тогда можно и связать между собой. Сам не пробовал пока что. Может кто уже изучал на практике? Поделитесь опытом, пожалуйста.

Читаешь не между, а мимо строк. Я о том-же: специально ОТ РУКИ созданная структура, статически задающая маппинг объектов LND и DB2, столь-же негибкая, как и DECS. Причем объекты LND хранятся таки в СУБДшных BLOBах (там их 3)

 

Конечно плох. Транзакции нет; взаимных исключений нет; ссылочной целостности нет; правил декларативной целостности нет .. etc

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

Читаешь не между, а мимо строк. Я о том-же: специально ОТ РУКИ созданная структура, статически задающая маппинг объектов LND и DB2, столь-же негибкая, как и DECS. Причем объекты LND хранятся таки в СУБДшных BLOBах (там их 3)

Не согласен. В nsf тоже есть свой маппинг - полей и айтемов. Другое дело, что новый айтем добавить менее геморройно, чем в РСУБД в таблице новую колонку. А ЯВНЫЕ связи между таблицами можно задавать, а можно и не задавать. На каком-то этапе развития системы можно и не задавать.
Уверен, что BLOB-ах? Это давно очень такая информация была, но потом много менялось в планах IBM. Где-то есть в документации по 8-ке такая информация? Или ты сам на практике проверял? Тогда что такое DAV? Как DAV связан с BLOB? "A DB2 Access view (DAV) is a shared resource that lets you define a DB2 view of Notes data. DAVs enable you to leverage the data that is stored in DB2. While the DAV actually exists in DB2, it is accessible by both Domino and non-Domino applications."
Что DB2 сама из BLOB в DAV транслирует данные? Сомневаюсь... А вот эта фраза как раз свидетельствует о том, что не в BLOB-ах данные хранятся: "Once the DAV is created, any subsequent changes made to the Notes data will immediately be visible in DB2. Any changes to the notes made using SQL will immediately be visible in Notes (you may need to refresh the Notes view to see change in the Notes client)"

 

Я сейчас почитал про DAV в 7-ке (http://www.ibm.com/developerworks/lotus/library/domino7-db2/index.html?S_TACT=105AGX13&S_CMP=EDU), похоже, что DAV - это третий вариант хранения данных в LND приложениях. Только он не взамен BLOB, а параллельно с ним существует. Domino, видимо, обновляет одновременно и BLOB и DAV Table, а если через SQL обновить DAV Table, то Domino отвечает за синхронизацию с BLOB. Видимо так.

Most Domino content consists of messaging and collaboration data unsuitable for relational storage and manipulation. So, application developers can now select only the data/fields that they need for relational processing. After a DAV is defined in Domino Designer, you can create a corresponding DB2 view that will be populated with Domino data from the specified fields. Once that is done, all your SQL applications, such as Crystal Reports, can now operate on Domino data through this DB2 view (see figure 1). In addition, the Domino server will be responsible for maintaining the data integrity on any updates through both Domino and DB2, with Domino security features enabled.

То есть, как мы видим, обреляционивание LND возможно. Нужно ещё смотреть, как реально работает (например, можно ли создать документ через DAV используя SQL выражение). Но вектор развития задан. Возможно, что в 9-ке будет опция, что BLOB вообще не использовать для выбранных баз данных, а только DAV. Также вполне разумным был бы вариант хранения в BLOB только неструктурированной (незамаппинной) части документа, а в DAV замаппиной. Вот это была бы истинная универсальность! Собственно такое разделение частично сделано уже, осталось только убрать из BLOB структурированную часть.

 

Кто-нибудь может тут выложить IBM® DB2 Universal Database™ Enterprise Server Edition, version 9.1 или 9.5?

 

Вот... Всем чудес хочется.. Однако "Чудес не бывает! Бывают чудотворцы"(с)

Ну, подумайте головой
Есть документы теговой структуры:
1:<Имя поля11><Тип><Значение11>;<Имя поля12><Тип><Значение12>;..<Имя поля1N><Тип><Значение1N>
2:<Имя поля21><Тип><Значение21>;<Имя поля22><Тип><Значение22>;..<Имя поля2N><Тип><Значение2N>
..
Причем и Имя поля11 не равно Имя поля21, и 1N!=2N, а если нечаянно совпадут, то Типы м.б. разные. Как такую хрень затолкать в таблицу??
Способа всего два:
или так весь док-т в одно поле и положить:
UNID | Body(CLOB)
--------------------------------------------------------------------------------------------------------------------------------
1: | "<Имя поля11><Тип><Значение11>;<Имя поля12><Тип><Значение12>;..<Имя поля1N><Тип><Значение1N>"
...

или ВСЕ теги на отдельные рекорды раздраконить:
UNID | ItemName | ItemValue
1: | Имя поля11 | Значение11
1: | Имя поля12 | Значение12
...
1: | Имя поля1N | Значение1N
2: | Имя поля21 | Значение21
2: | Имя поля22 | Значение22
...
2: | Имя поля2N | Значение2N

Второй способ - это т.н. "триплетная схема", которой почти столько-же лет, сколько самим СУБД. Гибкость у неё абсолютная, транзакция есть (правда ссылочная и декларативная целостность смысла не имеет), SQL-запросы в принципе строятся. Недостатки: избыточность еще больше, чем у LND (т.е. еще более рыхлое хранение) и - жуткие тормоза (наблюдаю на реальной системе).

Первый - это то, что сделала IBM, только BLOB/CLOB-ов оказалось более одного (3 - как сказал докладчик на одном IBMовском мероприятии). Транзакция там возможна, а SQL-запрос к чему прилепить? К UNID-у (тем более там скорее NoteID)? Если ЗАРАНЕЕ статически не за-декларировать (вот они - DAVы!) какие теги и какие типы данных будут в этих CLOB-контейнерах, хрен SQL сработает. Хренотень собственно и получается.

Гораздо грамотнее сделать, как в последней DB2 (НЕ спец.Домино едишен!): там вводится новый тип данных - XML и под него расширяется язык запросов. XML - более общая схема, чем теговая (теги - частный случай XML). LND-шная гибкость отдыхает! И что остается от преимуществ LND? Прототипирование/неструктурированные данные - есть (причем по мере "устаканивания" задачи данные можно постепенно выводить из XML в "обычные" поля). Виртуальная машина? На то есть JAVA, на которой теперь пишутся и триггеры, и хранимые процедуры. Козырем LND остается только работа в распределенной среде... ну и всеобщая интегрированность (все протоколы, все сервисы, все сервера - в одном флаконе. Хотя именно за эту эклектику и невзлюбило Домину руководство IBM)

 

Козырем LND является то, что в LND всё есть и всё слаженно работает в достаточной степени. Полноценное приложение лепится быстро и модифицируется тоже быстро. Ты попробуй с DB2 поработай. Я попробовал. Работать через GUI не стоит, полный глюк. К тому же шаблонов-то в DB2 и нету... Вот наработал ты что-то в тестовой базе, а потом все тоже самое повторяй в рабочей - полный бред. Что же это за среда разработки без шаблонов???????? В итоге, народ делает как, чтобы избежать глюкавого GUI и не делать дважды одно и то же, пишут скрипты и ими обновляют же потом и рабочие базы данных. Стоит заметить что DB2 - это только РСУБД, а нужен ещё сервер приложений и клиент. Вот, а попробуй теперь каждый элемент отдельно сделать и потом ещё это всё вместе скрестить. Трудоемкость гораздо выше чем в случае с LND.

 

1.Козырем LND является то, что в LND всё есть и всё слаженно работает в достаточной степени.
..
2.Работать c DB2 через GUI не стоит, полный глюк.
..
3.Стоит заметить что DB2 - это только РСУБД, а нужен ещё сервер приложений и клиент.

1.Я так и сказал. Но с т.зрения теоретиков, "коробочных" разработчиков и маркетологов(?) - это недостаток. а).Универсальный инструмент в каждом конкретном применении хуже специализированного
б)."Начинать программировать без предварительного анализа и структурирования данных?? Шо за фигня!" - а у нас в LND это образ жизни (вытекающий из пп.. моего 1-го поста)
в).Если в этом "одном флаконе" есть, то как впарить замечательные специализированные инструменты?

2.Ну-ка, ну-ка.. у DB2 есть свой GUI? Не знал..

3.Согласен. Но как тогда с твоим п.2? GUI(=клиент) - он есть, или его нет?

 

Трудоемкость гораздо выше чем в случае с LND.

Вообще-то с этого нужно было начинать. Все упирается в трудоемкость, а не в возможность. Лотус никогда не был уникальным, а с появлением явы он даже перестал быть самым универсальным эффективным инструментом. Но вот как раз то за, что ИБМ и невзлюбило LND и есть его козырь, - универсальность, простота и скорость разработки. А то что XML+Java+ какой-нить РСУБД может легко заткнуть лотус по возможностям давно всем известно. Просто LND это уже не просто инструмен, это своя культура и идеология. Продукт имеет огромную историю и множетсво адептов по всему миру.
Да и на с чет XML. Все данные домино хранятся в Domino XML (DXL). И при желание всегда можно работать напрямую с XML. Примечательно, что большинство новых классов в 8ке касается в основном работе XML.

 

1.Все упирается в трудоемкость, а не в возможность.
2.Лотус никогда не был уникальным..
3.Все данные домино хранятся в Domino XML (DXL). И при желание всегда можно работать напрямую с XML

1. Двумя руками - "за"
2.Был. Сейчас - да, уникальность растерял (точнее конкуренты подтянулись). Одна репликация, пожалуй, осталась
3.Наверное всё-ж не хранятся, а однозначно представляются/преобразуются. Но не суть...

 

1.Я так и сказал. Но с т.зрения теоретиков, "коробочных" разработчиков и маркетологов(?) - это недостаток. а).Универсальный инструмент в каждом конкретном применении хуже специализированного
б)."Начинать программировать без предварительного анализа и структурирования данных?? Шо за фигня!" - а у нас в LND это образ жизни (вытекающий из пп.. моего 1-го поста)
в).Если в этом "одном флаконе" есть, то как впарить замечательные специализированные инструменты?

2.Ну-ка, ну-ка.. у DB2 есть свой GUI? Не знал..

3.Согласен. Но как тогда с твоим п.2? GUI(=клиент) - он есть, или его нет?

1. б) даже при прототипировании анализ делается (но процесс итерационный), без анализа только кошки спариваются и то, наверное, кошара к себе кота просто так не допустит, свой анализ проведет.
2. Имею в виду графическую среду DB2, где можно лепить базы данных, щелкая мышкой. Можно ещё использовать Visio или ERWin, но, насколько помню, как шаблон эти средства тоже не особо прокатывали, то ли что-то глючило, то ли не все можно было там сохранять и переносить (возможно триггеры или ещё что-то).

 

Универсальный инструмент в каждом конкретном применении хуже специализированного

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

Но реальность жестока и чаще всего мы видим ХАОС бизнес процессов, и с этим хаосом идеально справляется только LND. Но это не значит что на LND не возможно создавать специализированные системы. Если бизнес "устаканился", и есть развернутая инфраструктура LND, то нет необходимости все ломать. Добро пожаловать в интертрас или в другую компанию предлогающую готовые решения "под ключ" и можете купить себе то, что нужно. Или заказать систему под себя индивидуально.

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

 

Но реальность жестока и чаще всего мы видим ХАОС бизнес процессов, и с этим хаосом идеально справляется только LND.

Это никакой не хаос, а разнообразие. Никаких стандартных бизнес процессов не бывает - всё индивидуально. Вот уж где IT-шникам бы пора поучиться тоже, ведь если с таким подходом начать руководить компанией, то можно всё дело мгновенно завалить. Уникальность бизнес процессов позволяет компании выживать. Если их тяжело скопировать конкурентам, то это огромный плюс! Также их уникальность может выражаться и в уникальности конечного продукта для потребителя, что позволяет компании занять на рынке свою нишу и жить спокойно.

 

1. б) даже при прототипировании анализ делается (но процесс итерационный), без анализа только кошки спариваются и то, наверное, кошара к себе кота просто так не допустит, свой анализ проведет.
2. Имею в виду графическую среду DB2, где можно лепить базы данных, щелкая мышкой. Можно ещё использовать Visio или ERWin, но, насколько помню, как шаблон эти средства тоже не особо прокатывали, то ли что-то глючило, то ли не все можно было там сохранять и переносить (возможно триггеры или ещё что-то).

1. .. про Фому, .. про Ерему. Растекаешься
2.А.. Про это? "GUI" Оракла тоже никто не использует (SQL Navigator и тот лучше). Отстойная, значит, СУБД этот Oracle!

 

Хаос или разнообразие - неважно, это одно и тоже. Суть в том, что со времён античной философии мир научились представлять в объектах их состояниях и способах взаимодействиях с другими объектами. Иными словами в объектно ориентированной методологии можно представить и хаос и порядок. Можно даже сказать что любая РСУБД - частный случай ООСУБД. В LND нет ничего такого чего невозможно было бы реализовать на РСУБД, в то время как LND умеет делать вещи недоступные РСУБД. Все что мы не можем сделать в LND упиратся в отсутствие доступных инструментов, а не в невозможности реализовать это на LND. Реализовать транзакции, взаимные исключения, ссылочную целостность и прочие особенности РСУБД возможно, просто реальность показала, что необходимость этих инструментов в LND намного меньше если вообще её нет. РСУБД и ООСУБД это не только различные подходы к решению одних и тех же задач, это иной способ воприятия задач. В ООСУБД задача воспринимается такой какая она есть в терминах абстраций объектов, а в РСУБД это скорее подстраивание реальности под реляционную теорию. А недостающие инструменты со временем появятся, если они действительно будут необходимы.

 

1. .. про Фому, .. про Ерему. Растекаешься
2.А.. Про это? "GUI" Оракла тоже никто не использует (SQL Navigator и тот лучше). Отстойная, значит, СУБД этот Oracle!

Ответить нечего, так как уже все было сказано выше, в частности, что шаблоны в LND - это очень удобная вещь сокращающая ненужные затраты сил и уменьшающая количество ошибок до нуля при переносе изменений. В других средах, ИМХО, всё в этом плане сложнее и менее удобно. Если, конечно, ты хочешь иметь БОЛЬШОЙ геморрой, то разрабатывай систему на Oracle, когда требуется потом вносить много изменений в оперативном режиме.

 

Реализовать транзакции, взаимные исключения, ссылочную целостность и прочие особенности РСУБД возможно, просто реальность показала, что необходимость этих инструментов в LND намного меньше если вообще её нет.

В транзакциях особо нет. Зависит от системы. Если вероятность сбоя в момент внесения связанных изменений в разные документы очень мала, то транзакции ничего особо в этой ситуации не дали бы. У нас работает многие годы система и без проблем. В банковских системах, где совершается очень большое число транзакций (если клиентов много), там вероятность подобного сбоя выше и последствия могут быть хуже. Но, замечу, что поддержка транзакций тоже не дает 100% гарантии. Журнал транзакций может ведь тоже навернуться... Например, насколько я понимаю и знаю, 1С в самом простом варианте (базы данных в папке с общим доступом) идет без журнала транзакций...
А вот по ссылочной целостности я иногда скучаю... Но это реализуемо, я делал, даже через тот же DECS её можно очень легко реализовать. И проверку уникальности кода тоже.

 

Но это реализуемо, я делал, даже через тот же DECS её можно очень легко реализовать. И проверку уникальности кода тоже.

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