• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Лукапы в Cfd поле

  • Автор темы lionk
  • Дата начала
L

lionk

есть база 500 000 доков.

документы тежолые (около 100 полей), с каждым доком работает несколько людей редактирую свои участки данных, но производственная необходимось (жеание начальника) обязывает всю информацию держать консолидировано в одной форме (шоб шеф открыл документик и в нём видно результаты работы всех подразделений).

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

Вариант решения
я могу разбить главную форму(и документ) на несколько форм(документов), основной и спец доки для подразделений(там содержатся нужныее только для них поля). Доки связать легко,
общую инфу в основном документе я могу показывать с помощю Computet For Display Field и лукапа в нём с последующим внятным форматированием информации.

но возникает вопрс:
после перепланировки я получу базу в 1 500 000 доков, и на форме будет окло 5 ти CFD полей с лукапами.

1. Как будет вести себя при открытии документ с таким количеством лукапов и доков в базе?
2. Не будет ли это более медленым (щас док открывается 3 секунды, и закрывается примерно также.), ваш прогноз, ну или пример если похожий механизм реализовон у вас.
3. Идет ли дощёт CFD поля если он скрыт?(искал но не нашол очень интересно)
 
M

morpheus

1. Ж№"а будет
2. Скорее всего будет
3. Скорее да ( пересчитываеться )
 
S

Sandr

Исползуйте для таких целей не лотус...
 
O

Omh

Ну не обязательно же юзать именно @DbLookup.
Можно @GetDocField.

Мне кажеться, что разбиение существующих доков на более мелкие и создание формы содержащей несколко UNID'ов и кучу Computed Text'ов с @GetDocField будет работать приемлимо.
Быть может даже хорошо.
Я даю идее добро :)

По вопросам
1. надо потестить: наплодить доков и создать форму с Computed Text'ами
2. думаю, будет приемлимо
3. пересчитывает
 
L

lionk

<!--QuoteBegin-Medevic+4:10:2007, 11:06 -->
<span class="vbquote">(Medevic @ 4:10:2007, 11:06 )</span><!--QuoteEBegin-->Какой смысл лукапов?
[snapback]80596" rel="nofollow" target="_blank[/snapback]​
[/quote]

ну лукапы я выбрал по тем же соображениям быстродействия
делаю представление с двумя колонками
1-я ключ
2-я сбор необходимой информации там 2 или 3 поля, то что нужно показать, я их полсле лукапа разобю и покажу как надо, таким обзом я работаю не со всем подлежащим документом а токо с нужными полями.
ведь в представление отбирается токо часть выбраная часть инфы или не?


<!--QuoteBegin-Omh+4:10:2007, 11:24 -->
<span class="vbquote">(Omh @ 4:10:2007, 11:24 )</span><!--QuoteEBegin-->Можно @GetDocField.
[snapback]80604" rel="nofollow" target="_blank[/snapback]​
[/quote]
а он нормально работает в больших базах?
чтото я к данной функции отношусь очень с обпаской, неужели зря?

<!--QuoteBegin-Morpheus+4:10:2007, 11:02 -->
<span class="vbquote">(Morpheus @ 4:10:2007, 11:02 )</span><!--QuoteEBegin-->1. Ж№"а будет
[snapback]80595" rel="nofollow" target="_blank[/snapback]​
[/quote]
серёзно?

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

Omh

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

Тебе надо откопировать реальную базу, утроить кол-во документов агентиком и за час соорудить форму с CFD полями. Пусть даже с hardcoded unid'ы и .т.д.
Тестовую форму. Потреяешь 3 часа, но будешь знать стоит ли.
 
R

redbestcat

Для: lionk

Вариант решения
я могу разбить главную форму(и документ) на несколько форм(документов), основной и спец доки для подразделений(там содержатся нужныее только для них поля). Доки связать легко,
общую инфу в основном документе я могу показывать с помощю Computet For Display Field и лукапа в нём с последующим внятным форматированием информации.

Раз решил разбивать - почему не оставить документ но сделать больше форм. Именно не документов - но форм. Для каждого подразделения документ отображается через его форму, для шефа - как и раньше, через старую.
 
O

Omh

Для: redbestcat
Молодцом, идея оччень неплоха!
Можно юзать например FormFormula у view, что бы не модифицировать доки.
 
L

lionk

Для: redbestcat

я тоже про это думал, но шеф тоже жалуется что медлно :)

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

и всёже как опция лукапы CFD поле заслуживает на жизнь или стоит на век отказатся от этой идеи.

и ещё, раз уж тут прозвуало, как ведёт себя @GetDocField в больших базах, ктото тестил?
 
R

redbestcat

Я думаю что лукапы будуть работать медленно. Если все же они - следует использовать кеш.

Есть ище одно решение, субьективно самое быстрое. Его приемлемость зависит от актуальности отчетов. Можно генерить специальные документы - отчеты для боса и обновлять их раз в день (реже\чаще). Там будут уже готовые значения и никаких вычислений при открытии происходить не будет.
 
I

IsAvailable

А может исключить открывание документа?
Скажем, встает работник подразделения во вьюхе на нужный док, нажимает "Внести данные" - открывается диалоговая форма с полями для заполнения для данного подразделения. При закрытии данные сохраняются в текущий документ.
Насколько сложные пересчеты на форме?
Если документ просто на чтение долго открывается, то какое-то открывание того же объема информации, но с вычислениями по любому дольше должно быть...

В общем, честно говоря - это просто моё предложение. ИМХО работать должно быстрее, чем извлечение данных в одну кучу из разных доков.
 
M

Mihal

<!--QuoteBegin-lionk+4:10:2007, 10:58 -->
<span class="vbquote">(lionk @ 4:10:2007, 10:58 )</span><!--QuoteEBegin-->документы тежолые (около 100 полей), с каждым доком работает несколько людей редактирую свои участки данных, но производственная необходимось (жеание начальника) обязывает всю информацию держать консолидировано в одной форме (шоб шеф открыл документик и в нём видно результаты работы всех подразделений).
[snapback]80593" rel="nofollow" target="_blank[/snapback]​
[/quote]

Дык, а вы держите информацию не консолидировано, а показываёте консолидировано B). Например, каждый раз сделать n разных документов. У каждой формы сверху - ссылки на другие документы. Визуально - как буд-то скачешь по закладкам одной формы. На самом же деле - нет.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!