View Formula @texttotime("today") ?

[Akupaka]

Всем привет!

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

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

Но меня волнует не упустил ли я чего? Если кто имеет что-то интересное сказать, прошу не стесняться
К стати, сильно волнует вопрос о перестроении индексов на локальных репликах. Если кому известно готовое решение, буду благодарен.

 

[Constantin A Chervonenko]

..
Было рассмотрено несколько вариантов, наиболее привлекательным мне кажется использовать @TextToTime("Today").
Формула отбора периода в общем случае примет вид: @Year(docdate) = @Year(@TextToTime("Today")).

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

IMHO лучше написать

SELECT @Year(docdate)=2011

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

 

[Medevic]

Не проще ли агентом раз в год менять формулу отбора?

 

[lmike]

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

 

[Akupaka]

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

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

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

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

 

[Medevic]

Какую переменную? Я имел в виду серверный агент. Причем запускать можно на каждом сервере.
Тогда лучший вариант - раскидать по папкам.

 

[Akupaka]

Какую переменную?

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

По папкам чем лучше? Как в таком случае индексы строятся? Я с ними как-то не работал

 

[Constantin A Chervonenko]

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

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

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

 

[Xalet]

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

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

 

[Akupaka]

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

До этого я тож догадался. Как вид локально перестроить?

Добавлено:

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

Тем, что научить кого-то запустить ребилд легче, чем поменять дизайн вида. Т.е. организационно этот вариант проще.

 

[Medevic]

По папкам чем лучше? Как в таком случае индексы строятся? Я с ними как-то не работал

Тем, что не надо делать ни ребилд, ни изменение формулы, т.к. у папок нет формулы отбора. Кинул один раз в папку и забыл.

 

[Akupaka]

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

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

 

[Medevic]

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

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

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

 

[Xalet]

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

 

[Akupaka]

Да, доступ на добавление в папку должен быть

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

Вообще надо базу поделить. Сделать архивную и рабочую

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

 

[Medevic]

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

Как он это сделает и почему не сможет сделать так с представлением?

 

[Akupaka]

Как он это сделает

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

 

[Xalet]

IMHO лучше написать

SELECT @Year(docdate)=2011

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

 

[Medevic]

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

А, это хз.

 

[Akupaka]

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

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