Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

в продолжение темы http://www.lplm.ru/phpBB2/viewtopic.php?p=2190#2190
у нас сейчас около 260 тыс. записей об объектах (object_reference) и более 4 млн записей об атрибутах (attrib_value).
проблем в принципе не замечаем. но уже стараемся оптимизировать структуру данных, а то не ровен час...
одно время кстати была проблема, некоторые операции (особенно удаление объекта из проекта) выполнялись неадекватно долго. но кто-то (то ли Теххелп, то ли кто-то с форума) посоветовал обновлять статистику. сейчас эта работа постоянно активна на сервере и та проблема, снявшись сразу же, больше не возникала.
но про размеры БД и оптимизацию данных мы сейчас думаем практически постоянно...

И...? Просто думаете или какие-то решения приходят? Или просто продумываете минимизацию в процессе разработки нового функционала?

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

Указанные размеры БД проблемными не являются (если я правильно понял, речь идет о Sybase), особенно, если нет необходимости в выборке больших наборов данных.
По моему опыту, основная проблема производительности при росте размера БД, выборка атрибутов. Боремся написанием хранимых процедур на основе динамического SQL для БД Sybase, но это именно для сложных выборок типа ведомости материалов. Выборки малого объема пока проблем не вызывали.

у нас MS SQL Server..
я не говорю, что проблема уже на уровне сервера БД, вовсе нет (а ксати, когда проблемы должны начаться на MS SQL??). здесь вопрос в другом. чем больше записей в таблицах - тем медленнее работают запросы. или это не так?
просто мне кажется, что это является причиной снижения производительности (не единственной, конечно), вот мы и боремся с этим всеми возможными силами.
другой момент. иногда есть реальная возможность отказаться от обращений к таблицам с правами (ведь включать в вид только те объекты, которые в любом случае доступны на просмотр абсолютно всем). и если делать отчеты по ЭТИМ видам, то работать они будут быстрее.
или нет?

Если обращаться напрямую к таблицам или к видам в которых не учитываются права, естественно, запросы будут работать заметно быстрее.

Anderyt

кто-то (то ли Теххелп, то ли кто-то с форума) посоветовал обновлять статистику. сейчас эта работа постоянно активна на сервере и та проблема, снявшись сразу же, больше не возникала.

А что конкретно имелось в виду под статистикой? Какую работу вы запускали на сервере?

(говорю про MS SQL Server) был настроен Database Maintenance Plan, в котором была поставлена галочка Update the statistics used by the query optimizer (80%).
работа была создана автоматом, настроили запуск раз в неделю.. в таком режиме уже работаем чуть больше года

Anderyt писал(а):(говорю про MS SQL Server) был настроен Database Maintenance Plan, в котором была поставлена галочка Update the statistics used by the query optimizer (80%).
работа была создана автоматом, настроили запуск раз в неделю.. в таком режиме уже работаем чуть больше года

Спасибо) Правда, у нас Sybase ASA, но посмотрим в этом направлении, ибо проблема с тормозами точь-в-точь как у вас: неправдоподобно долгие операции и особенно удаление из проекта

В Sybase ASA это делается всего одним оператором DROP OPTIMIZER STATISTICS
Зато в Sybase SQL Anywhere 10 обрубать статистику надо на каждую таблицу отдельно, да к тому же требуется монопольная блокировка таблицы (а проблемы-то с оптимизатором возникают не реже)