Почему 1.000 субформ в БД будет плохой идеей?

Question

Разминка

Я пытаюсь найти хороший способ реализации пользовательских форм документов.

Это инструмент для запроса доступа к приложениям; Каждое приложение захочет задать свои конкретные вопросы. Дело в том, что у нас есть один (обычный) пользователь, который должен заполнять и отправлять документы на основе шаблонов, и другой (супер) пользователь, который должен иметь возможность определять, что должен содержать каждый шаблон.

Одним из вариантов реализации было бы использование формы (с базовыми обязательными компонентами), и эта форма динамически включала бы подчиненную форму, соответствующую конкретной задаче. Суть в том, что мы могли бы (= будем!) Легко получить много сотен различных субформ!

(NB. Эти подчиненные формы будут поддерживаться в автоматическом режиме, но это другая тема , которая может рассматриваться вне рамок этого вопроса.)

Вопрос

Общеизвестно, что наличие большого количества представлений в базе данных Notes - это плохо. Но пытался ли кто-нибудь увеличить число форм или субформ и испытал ли он какой-либо опыт в отношении производительности?

Answer 1

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

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

Причина, по которой представления являются проблемой, состоит в основном из их индексов. Каждое представление поддерживает индекс для всех документов, которые содержатся внутри. Затем для каждой сортировки столбца в этом представлении размер индекса удваивается. Реальная проблема становится одним из обслуживания и ресурсов. Чем больше у вас просмотров, тем больше у Notes работы по перестроению индексов и тем больше ресурсов (диска и памяти) требуется для перестроения.