Обслуживание баз программы

[VLadimirM Профиль]

Добрый день! Программу купили, очень нравится, пытаемся разобраться с нюансами.
1.Не нашел ничего в описании про обслуживание баз.
2.Каковы должны быть действия в конце года, если мы хотим в новом году начать нумерацию заявок с номера 1 и базу прошлого года перенести в архив, но с возможностью его использования, если понадобится? Естественно, в базе нового
года все остальное(справочники, пользователи и т.п.), кроме самих заявок, должно сохраниться.
3.Как правильно организовать резервирование баз в процессе работы?

[Администратор]

Здравствуйте!

1. Делайте периодический бэкап основных файлов базы (4 файла fdb). Этого достаточно.
2. Нумерация не может быть сброшена. При переносе в архив заявок, переносятся только они, т.е. справочники и т.п. сохраняются. Архивные заявки можно только просматривать в программе, если, например, нужно поднять информацию о старой заявке.
3. Просто копируйте основные файлы базы периодически. Для этого не обязательно останавливать СУБД Firebird, поэтому неважно какими средствами вы это будете делать.

[VLadimirM Профиль]

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

Хотелось бы тогда уточнить идеологию программы, если возможно. При использовании в течении нескольких лет, количество заявок в крупной организации может достигать десятков тысяч с учетом заявок перенесенных в архив. Не будет ли программа тормозить? На какое количество заявок она рассчитана, если подразумевается сквозная нумерация? Мне кажется заявка с номером 100253 как-то неадекватно смотрится, потому что непонятно за какой период накоплено такое количество. Ведь номер заявки в течении года косвенно отражает статистику поступивших в текущем году, или я неправ?
На мой взгляд, было бы логично архивировать базу текущего года, начинать нумерацию заявок в новом году с 1 и иметь возможность подгрузки баз прошлых лет. Базы прошлых лет должны храниться в отдельных файлах, тогда снимается нагрузка на базы текущего года.

[Администратор]

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

[VLadimirM Профиль]

Я, к сожалению, не специалист в проектировании баз данных, но по дилетантски представляю, что в базе содержатся таблицы с различными данными: пользователи, справочники, заявки и т.п. Пусть они связаны в текущем году с ключевым полем номер заявки. Что мешает в конце года перенести базу в архив, а в базу нового года перенести все таблицы справочников , разорвав их связь с ключевым полем номер и обнулив его?
В базе нового года ключ можно восстановить и при формировании новых заявок, начнут заново образовываться связи. Мне кажется это было бы логичным, хотя, конечно, я не знаю, как это можно реализовать практически. Т.е. по сути, хотелось бы, чтобы была предусмотрена некая операция "реорганизация", которой можно было бы пользоваться по желанию, т.к., наверное, не всем нужны такие заморочки, о которых идет речь. В результате реорганизации формировался бы архив за период, например, за год, а основная база была готова к введению новых заявок с первого номера. И работа с архивами стала бы более логичной: год - файл базы, который можно было бы подключить по запросу. В текущей реализации, насколько я понял, в архивную базу будут попадать заявки за все года и соответственно база будет тяжелой для работы.
Спасибо за ответы.

[Администратор]

Концепция с архивацией уже готова, изменять её мы пока не планируем. По сбросу счетчика нумерации думаю сделать можно в будущих обновлениях.