Быстродействие

В первую очередь критична производительность процессора и объём оперативной памяти. Для маленькой базы они у вас достаточные.

Для поддержания оптимального быстродействия базу данных нужно периодически обслуживать. Т.е.:
- не хранить в рабочей базе подробные протоколы всех действий пользователей за все времена, периодически удалять историю сеансов и событий;
- периодически выполнять пересчёт статистики базы;
- чистить хотя бы иногда log SQL.

Что касается обновления и удаления - это ОЧЕНЬ сильно зависит от режима. в некоторых режимах (например, Номенклатура) обновление - это элементарная операция и тормозить не будет даже на огромном объёме записей. А есть, например, режим Новые задания, где при обновлении автоматически пересчитывается текущая доступность всех постов, пересчитывается на лету для каждого задания на экране возможность или невозможность включения его в сменное задание соответствующего поста в заданную дату, с учётом производительности этого поста и его текущего плана, квалификации исполнителей и прочих нюансов. Тут, конечно, обновление займёт некоторое время. Хотя всё зависит от количества заданий.
То же и по удалению. В некоторых случаях нажатие на кнопку Удалить = изменение одной-двух записей в базе данных. А в других - это изменение тысяч и десятков тысяч записей. Скорость, конечно, будет разная. Смотреть имеет смысл каждый случай отдельно. Где-то должно мгновенно работать. А где-то (как при очистке базы от "старых" заданий, например, и несколько десятков минут - это нормально).

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

И ещё один момент. Скоро выйдет новая версия VOGBIT, которая будет поддерживать MS SQL 2012. Использование современных ОС и переход на SQL 2012 тоже даст некоторое ускорение, т.к. будут более оптимально использоваться ресурсы современных многоядерных процессоров.

Понятно. Ну тут цепочка не короткая. Поэтому и обновление занимает, видимо, какое-то время.
Будет время, посмотрим именно такую конструкцию, как она себя ведёт.

Кстати, вы, если не секрет, для чего так делаете? В приложении к какой практической задаче эта конкретная конструкция окон (с передвижением по компонентам) вам нужна?

Понятно.
Ну это нештатный случай всё-таки.
В будущем мы планируем добавить более дружелюбный специальный редактор для созданных заданий. Чтобы можно было корректировать вручную созданные и удалять если надо ненужные. давно собираемся, пока не успели просто.

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

Планируется.
Но не в ближайшей версии уже. Может в следующей.

В ближайшей планируется сделать специальную утилиту для администратора для наиболее типичных случаев "массового" удаления. Например для чистки/удаления карты заказа, которая была создана неправильно или только в целях какой-то проверки или расчёта.

В VOGBIT меню Администрирование, кнопка Сеансы, выделить, "Удалить".
Не забудьте резервную копию базы сделать предварительно.

Да

база данных SQL состоит из 2-х файлов: данные и лог. Есть процедуры сжатия файлов в самом SQL. Почитайте документацию по MS SQL по вопросу сжатия базы. Или погуглите.

Но это с точки зрения производительности наименее критично, если сравнивать с остальными параметрами.

Намного важнее:
- чистить журнал событий.
- чистить старые задания по давно выполненным заказам.
- запускать после всего этого и вообще периодически пересчёт статистики.

Если есть заинтересованность, можем выставить счёт на поддержку за июнь и посмотреть вашу базу. Например, проверить что расчёт вообще работает и сколько времени займёт. Нужна только будет копия базы, чтобы с ней поработать.

Здравствуйте. Напомните пожалуйста как чистить журнал событий?

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

Некоторые сеансы не удаляются - это нормально?

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