• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

View Formula @texttotime("today") ?

  • Автор темы Akupaka
  • Дата начала
A

Akupaka

Всем привет!

Имеется приложение с большим объемом данных. Данные условно группируются по годам. Необходимо оптимизировать представления, чтобы быстрее работали, занимали меньше места.
На данный момент, за Н-лет, в базе имеется около 3 млн документов. Прирост около 700-900 тыс в год. Сейчас в представлениях отображены все имеющиеся данные.
Наиболее оптимальным вариантом оптимизации представлений принято разделить данные по годам, а именно, в оперативных представлениях отображать данные по текущему году, а какой-то отдельный вид - все года.
Было рассмотрено несколько вариантов, наиболее привлекательным мне кажется использовать @TextToTime("Today").
Формула отбора периода в общем случае примет вид: @Year(docdate) = @Year(@TextToTime("Today")).

По проведенным исследованиям, замечена одна проблема - вид необходимо принудительно перестроить в случае изменения года, иначе год "не меняется".
Зато все остальные операции, похоже, срабатвают интереснее в сравнении с представлением без такого фильтра: индекс значительно меньше, обновление индекса при изменении док-тов быстрее, построение индекса с нуля быстрее.

Но меня волнует не упустил ли я чего? Если кто имеет что-то интересное сказать, прошу не стесняться :)
К стати, сильно волнует вопрос о перестроении индексов на локальных репликах. Если кому известно готовое решение, буду благодарен.
 
30.05.2006
1 345
12
BIT
0
..
Было рассмотрено несколько вариантов, наиболее привлекательным мне кажется использовать @TextToTime("Today").
Формула отбора периода в общем случае примет вид: @Year(docdate) = @Year(@TextToTime("Today")).

По проведенным исследованиям, замечена одна проблема - вид необходимо принудительно перестроить в случае изменения года, иначе год "не меняется".
IMHO лучше написать

SELECT @Year(docdate)=2011

и раз в год менять эту формулу
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Не проще ли агентом раз в год менять формулу отбора?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
"не было печали - купила баба порося" :)
700 тыс доков - у мя мосх вкипит, яб такую вьюшку дажеб не открывал ;)
зачем такое представление нужно, визуально, да и невизуально - сомнительное использование
такой объем обычно нужен как исходное для анализа, вот на него инужно ориентироваться
результаты анализа обычно вывваливают в к-л удобоваримую форму (или как промежут вариант, для др. систем)
у меня больше 100 строк вызывает рвотные позывы :) - невозможно смотреть на подобные простыни (да и не нужно)
 
A

Akupaka

Constantin A Chervonenko,
а чем это лучше? Возникает необходимость в механизме изменения формулы отбора (скорее всего серверный агент).
При этом, запускать агент можно лишь на одном сервере, а на остальных до репликации будет неактуальная инфа.
При утере связи с сервером источником "дизайна" приложение теряет критичную функциональность.
В остальном представление функционирует так же как и с @TextToTime("Today"), т.е. пока год не меняется - все работает одинаково.
Единственный жирный плюс - при смене дизайна, индекс автоматически перестроится. Но, как мне кажется, минусов больше.

Medevic
мне кажется, что не проще. Придется хранить переменную в нотес.ини, причем как на сервере, так и локально (используются локальные реплики). Менять ее вовремя - это опять-таки проблема, если на серверах еще можно автоматизировать, то как быть локально? Кроме того, та же проблема с принудительным перестроением индексов.
В остальном представление функционирует так же как и с @TextToTime("Today").

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

зы: не мала баба клопоту - купила порося ;)
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Какую переменную? Я имел в виду серверный агент. Причем запускать можно на каждом сервере.
Тогда лучший вариант - раскидать по папкам.
 
A

Akupaka

Какую переменную?
Ой, виноват :) Я че-то прочел твой вариант как вариант с переменной окружения.
Твой вариант тот же, что и Константина, комментарий к нему соответствунно и к тебе относится.

По папкам чем лучше? Как в таком случае индексы строятся? Я с ними как-то не работал :)
 
30.05.2006
1 345
12
BIT
0
а чем это лучше? Возникает необходимость в механизме изменения формулы отбора (скорее всего серверный агент).
При этом, запускать агент можно лишь на одном сервере, а на остальных до репликации будет неактуальная инфа.
При утере связи с сервером источником "дизайна" приложение теряет критичную функциональность.
В остальном представление функционирует так же как и с @TextToTime("Today"), т.е. пока год не меняется - все работает одинаково.
Единственный жирный плюс - при смене дизайна, индекс автоматически перестроится. Но, как мне кажется, минусов больше.
Вот!! При смене года НА ВСЕХ серверах придётся запускать Rebuild (агентом?). Иначе во вьюшке останутся немодифицированные прошлогодние док-ты. И чем это лучше смены дизайна?

PS: говорят в 8-ке профайл можно юзать не только в ф-ле колонки (сам посмотреть так и не удосужился)
 
X

Xalet

Придется хранить переменную в нотес.ини, причем как на сервере, так и локально (используются локальные реплики). Менять ее вовремя - это опять-таки проблема, если на серверах еще можно автоматизировать, то как быть локально?

На открытие базы повесить.
 
A

Akupaka

На открытие базы повесить.
До этого я тож догадался. Как вид локально перестроить? :)

Добавлено:
Вот!! При смене года НА ВСЕХ серверах придётся запускать Rebuild (агентом?). Иначе во вьюшке останутся немодифицированные прошлогодние док-ты. И чем это лучше смены дизайна?
Тем, что научить кого-то запустить ребилд легче, чем поменять дизайн вида. Т.е. организационно этот вариант проще.
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
По папкам чем лучше? Как в таком случае индексы строятся? Я с ними как-то не работал :)
Тем, что не надо делать ни ребилд, ни изменение формулы, т.к. у папок нет формулы отбора. Кинул один раз в папку и забыл.
 
A

Akupaka

Medevic ,
а как ты предлагаешь тогда сопровождать данные, для каждого года своя папка или одна папка для текущего года, а в ночь на 1-е полностью ее перестраивать?
к стати, папка как-то зависит от представления на основе которого она сделана? или только при создании копия дизайна производится и все?

Добавлено: каким образом регулировать доступ? Т.е. необходимо, чтобы документ появлялся в папке сразу при создании, значит всем пользователям будет доступ на управление папкой.
Переносить добавление/удаление документа из папки на сервер? Опять-таки, как быть с локальными репликами в таком случае?
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Medevic ,
а как ты предлагаешь тогда сопровождать данные, для каждого года своя папка или одна папка для текущего года, а в ночь на 1-е полностью ее перестраивать?
к стати, папка как-то зависит от представления на основе которого она сделана? или только при создании копия дизайна производится и все?

Добавлено: каким образом регулировать доступ? Т.е. необходимо, чтобы документ появлялся в папке сразу при создании, значит всем пользователям будет доступ на управление папкой.
Переносить добавление/удаление документа из папки на сервер? Опять-таки, как быть с локальными репликами в таком случае?
Для каждого года своя папка.
Никак. Только дизайн копируется.
Да, доступ на добавление в папку должен быть. Драгэндроп можно запретить.
 
X

Xalet

Вообще надо базу поделить. Сделать архивную и рабочую. В рабочей документы только текущего года. ИМХО, если так можно, то так правильнее.
 
A

Akupaka

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

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

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Но, если дать доступ пользователю, то он сможет случайно/умышленно изменить эту папку, ладно, если добавит документы из другого периода, хуже, если удалит из текущего, тогда все будут видеть неккоретную информацию.
Как он это сделает и почему не сможет сделать так с представлением?
 
A

Akupaka

Как он это сделает
А операции поместить/удалить из папки не доступны всегда для пользователя? Только, если дизайнер вынес их на уровень действий?
зы: в представлении нет таких операций, а удаление из БД запрограммировано
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
А операции поместить/удалить из папки не доступны всегда для пользователя? Только, если дизайнер вынес их на уровень действий?
зы: в представлении нет таких операций, а удаление из БД запрограммировано
А, это хз. :)
 
A

Akupaka

Medevic ,
ну ты даешь! Ты ж у нас гуру папок! Должен знать такие мелочи :)

Добавлено: Проверил. Эти действия доступны в любом приложении, в меню Действия.
 
Мы в соцсетях:

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