-
15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby
За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.
На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.
Запись на курс до 25 апреля. Получить промодоступ ...
Импорт | экспорт
- Автор темы magistr
- Дата начала
LEI, мало того что стоит денег, по сути своей является тем же DECS (на нём и работает), но с более продвинутой возможностью настоек. Не думаю, что его результат обмена данными с СУБД будет сильно отличатся от того, что вы сейчас имеете. В агенте можно реализовать любой более гибкий алгоритм, например, использовать какой-то особый формат хранения файлов, который поддерживает ваша СУБД, MIME кодирование/декодирование на лету или файловое хранилище где-то в сети, а в СУБД и Lotus Notes передавать только ссылки на эти файлы и т.д. и т.п.
вот с этого места поподробней - это как, какая форма, нотус не хранит никаких форм...
он отображает доки по форме (кот. тоже док)
Есть БД .nsf в ней есть views на которой создаю Forms где сохраняю текст и вложения. На этой вьюшке получается много форм с вложениями и текстом. Теперь требуется - вложения и текст положить в СУБД, чтобы notes "смотрел" в СУБД и показывал в Field (ах) на форме то что лежит в полях СУБД. Это позволяет сделать DECS, но у меня получается хранить только текст, "Attachments" не передаётся в СУБД из Rich Text поля, передаются каракули закодированные, а обратно из СУБД читается уже как текст эти самые каракули :dead:.
Уважаемый @lmike, прошу прощения, что так непонятно объясняю
.
Уважаемый @lmike, прошу прощения, что так непонятно объясняю
."стесняюсь спросить" - чем
дело в том, что пользование нотусов, с т.з. БД, "мало" отличается от др. key-value БД, а то с чем сталкивает пользователь - всего-лишь интерфейс...
Если т.з. программирования, xPages - это JSF, есть всякие бины, кот. могут подключаться к чему-угодно, построено все как OSGi
Ссылка скрыта от гостей
, штатно включен ExtLib (в кот. все это есть)
это, мягко-говоря, не соответствует действительности...
это как сказать: что эксель - смотрит в БД через браузер
Представьте что есть МСАксесс - как получить отображение из др. СУБД?! - вот и получите рецепт для нотуса
а так... - согласен с @garrick, вопрос звучит странно и судя по хотелкам - инструмент и подход явно выбраны без осознания
Последнее редактирование модератором:
Вот некоторые из самых известных: Visual Studio, Builder C++ - эти IDE достаточно мощные и самодостаточные на мой взгляд (хотя к Builder C++ прикручивается куча надстроек). Лотусовый дизайнер - это что-то из другого мира (только плиз не спрашивайте почему, я уже к нему привыкаю и не вижу недостатков, но по началу я "плакал"
)Это можно в учебнике написать (в любом приложении интерфейс - это пользовательская часть)
Благодарю, надо испробовать (но для моих целей не подходит).
Думаю иначе, есть в DECS такое понятие как "Virtual Fields" так вот, клиент Lotus как раз смотрит в СУБД через эти поля (другими словами, в лотусовом документе пусто, он не наполнен и по сути просто есть место где эти данные на форме отображаются) - т.е. клиент - всётаки браузер.
Уважаемый garrick, на в вопрос
У меня тоже был такой вопрос, я в Lotus Notes как в продукте гиганта IBM не сомневаюсь (в функционале) но столкнулись с ограничением БД лотуса по размеру (настроен DAOS) база пухнет. Решили посмотреть в сторону СУБД без такого ограничения (по размеру). А что если хранить данные не в лотусовой БД, но в СУБД (и не важно ссылки хранить в СУБД или сами файлы и текст). Главное, что БД Lotus не будет больше увеличиваться.
- вот такую историю мне поведали... (да... и это всё требуется настроить без программирования с помощью DECS)
Как я понял, всего-то требуется организовать передачу файла из лотусового поля Rich Text в СУБД и получить его обратно из СУБД в лотусовое поле Rich Text.
1. Максимальный размер файла базы данных Lotus Notes - 64GB. При настроенном DAOS это будет не один миллион документов в базе.
2. Если база "пухнет" следует рассмотреть возможность "порезать" её на архивы, например "Документы за 2013 год", "Документы за 2014 год" и т.п. Конечно возникает некоторое неудобство, т.к. придётся работать с несколькими базами, но такой подход часто практикуется, особенно когда документы имеют какой-то жизненный цикл. Например, обработка запроса клиента - обрабатывается, обрабатывается и опа! всё сделали!, клиент счастлив, значит можно этот уже обработанный документ переместить из боевой базы в "архив" для истории. Так же можно "вырезать" из основной базы какие-нибудь справочники или разные типы документов и разместить их в отдельных базах, если, конечно, они соответствующего объёма.
3. Если уж очень хочется СУБД, то есть родная интеграция Lotus Notes с DB2 (сам не пользовался, но думаю кто-нибудь из местных подскажет если что).
4. Ну, и самый последний вариант - вообще отказаться от Lotus Notes, взять какой-нибудь PHP, Python, Groovy и т.п. и создать на нём web-интерфейс для СУБД. И тут надо помнить, что некоторые СУБД, хранящие базу в одном файле, также имеют ограничение на размер файла в файловой системе.
Ведь я правильно понял, вы хотите оставить Lotus Notes в качестве front-end приложения (GUI), а все данные переместить в СУБД? Тут не DECS, ни LEI не помогут, т.к. они предназначены для интеграции Lotus Notes с СУБД - обмен данными, но никак не перемещение их полностью в СУБД. Такую задачу наверное можно было бы решить, как тут уже говорили в XPages, но в классическом клиенте Lotus Notes... разве что из спортивного интереса попытаться сделать, но промышленная эксплуатация такого решения маловероятна.
2. Если база "пухнет" следует рассмотреть возможность "порезать" её на архивы, например "Документы за 2013 год", "Документы за 2014 год" и т.п. Конечно возникает некоторое неудобство, т.к. придётся работать с несколькими базами, но такой подход часто практикуется, особенно когда документы имеют какой-то жизненный цикл. Например, обработка запроса клиента - обрабатывается, обрабатывается и опа! всё сделали!, клиент счастлив, значит можно этот уже обработанный документ переместить из боевой базы в "архив" для истории. Так же можно "вырезать" из основной базы какие-нибудь справочники или разные типы документов и разместить их в отдельных базах, если, конечно, они соответствующего объёма.
3. Если уж очень хочется СУБД, то есть родная интеграция Lotus Notes с DB2 (сам не пользовался, но думаю кто-нибудь из местных подскажет если что).
Ссылка скрыта от гостей
4. Ну, и самый последний вариант - вообще отказаться от Lotus Notes, взять какой-нибудь PHP, Python, Groovy и т.п. и создать на нём web-интерфейс для СУБД. И тут надо помнить, что некоторые СУБД, хранящие базу в одном файле, также имеют ограничение на размер файла в файловой системе.
Ведь я правильно понял, вы хотите оставить Lotus Notes в качестве front-end приложения (GUI), а все данные переместить в СУБД? Тут не DECS, ни LEI не помогут, т.к. они предназначены для интеграции Lotus Notes с СУБД - обмен данными, но никак не перемещение их полностью в СУБД. Такую задачу наверное можно было бы решить, как тут уже говорили в XPages, но в классическом клиенте Lotus Notes... разве что из спортивного интереса попытаться сделать, но промышленная эксплуатация такого решения маловероятна.
Последнее редактирование модератором:
Простите за вторжение в столь увлекательную дискуссию)
Если я правильно понял ваши цели, вам нужен некий интерфейс и вы хотите уйти от ограничения размера базы в лотусе.
Оставим за кадром, почему именно лотус, ибо реализация реляционки на лотусе ммм.....это скажем так забавно.
Как выше уже говорили, по факту у вас выход использование xpage и данные из любой реляционки.
Никаких проблем с этим нет. Использовать дополнительно LEI в данном случае лишнее, как мне кажется.
Нативно вы можете отображать и работать с данными из субд,так что не понятно зачем плодить сложности?
Ради изучения, натянуто но можно. Продакшен? Как сказал @garrick врядли.
Писать непосредственно для клиента без xpage ? Месье, это извращение чесслово.
Далее, ДАОС. У него есть каталог конечно, тоже база nfs. Тоже с ограничением в 64Гига. А теперь посчитаем, уважаемые кроты) Текущий размер почтовых баз у меня окель 4Tb. Размер базы каталога даоса 2Гб.
И чтобы дойти до ограничения базы даоса........ну у меня такого массива нет. Даже данных столько нет.
Другой вопрос, что лотус не реляционка а то бывали случаи ))))
Вообще не понимаю о каких ограничениях по размеру идёт речь при включенном DAOS. У базы есть Logical Size и Physical Size. Logical может пухнуть сколько влезет, хоть за 64Гб пусть переваливает. Для Physical чисто технически сложновато будет достигнуть предела.
Использование реляционки, как хранение файлов вложений, а Notes для UI - это, как уже сказали, сомнительное решение.
Использование реляционки, как хранение файлов вложений, а Notes для UI - это, как уже сказали, сомнительное решение.
опять вы "о своем"...
домина для документооборота и если у вас именно такая задача - альтернативы очень сомнительны...
база пухнет за счет индексов, обещали это "исправить"
(ждемс)РСУБД - это лепить фронт (если документооборот) и объектную стр-ру БД - ну если у вас есть спецы по решению подобных масштабных задач - тогда и домина была бы не нужна
для отчетов - дык выгружайте, вот только РТФ тут непонятно упомянуты - к реляциям никакого отношения они не имеют
про ДАОС уже сказали
озвучьте уже нам эти страшные цифры и размеры индексов
не надо так делать!
[DOUBLEPOST=1446800350,1446800301][/DOUBLEPOST]
закапывайте
- это решение уже трупОбучение наступательной кибербезопасности в игровой форме. Начать игру!