Добрый день.
Есть некая головная организация (ГО) с большим количеством филиалов (40 штук на данный момент). ГО может просматривать текущее состояние (и смотреть прошедшие года) выбранного филиала, составлять отчеты и т.д. Филиал в течение года засерает заполняет БД до невозможности, но самое главное, что данные об 5-летки должны храниться еще 3 года, причем в любую секунду к ним могут обратиться. Все действия строго фиксируются (кто и что посмотрел, кто записал и т.д.).
Через год, некоторые таблицы сменят имя (было logs, стало backup_logs_2010).

Затрудняюсь в выборе правильного решения.


up
Записей в год минимум 100 млн.
Каждый год БД для одного филиала будет вырастать на 10 дополнительных таблиц.

Это сообщение отредактировал(а) MoLeX - 22.6.2010, 07:11

Если задача не подразумевает вывода отчетности по более чем одному филиалу - для каждого филиала своя БД.

Без указания СУБД опрос имхо некорректен.

Akina, я не даром в MySQL создал, могу еще версию сказать - 5.0

Добавлено через 1 минуту и 50 секунд

пока, что нет

1) Отдельная БД в каждом подразделении (включая, кстати, и головное). При этом гарантировать полное соответствие структур и за счёт префиксов имён таблиц уникальность имён во всём пространстве этих БД.
2) Специальная БД в головном, куда любым механизмом (да хоть через бэкап-рестор) дублируются данные из всех БД для получения сводных данных по всей организации. Она же используется и для архивных (не архивирование! хранение) целей.

  


думаю этого не потребуется, скрипты будут на РНР, а он позволяет создавать подключения к N-ому количеству БД.



И какой тип таблиц лучше использовать? Я склоняюсь к использованию MyISAM, хотя некоторые заявляют о необходимости InnoDB!

Ответ на этот вопрос зависит от требований к целостности и согласованности данных, а так же требований мастабируемости многопользовательского доступа.

Ну вот опять - всё вручную. Ты что, всерьёз полагаешь, у тебя получится лучше, чем у сервера БД? одна БД, MERGE Storage Engine - нормальное и вполне эффективное решение. И потом - групповая обработка вряд ли когда будет требоваться, судя по описанию, на сиюминутном состоянии, а для обработки архивного среза на определённую дату имхо разумнее статическая архивная БД. Дополнительное дисковое пространство намного дешевле дополнительной производительности.

нет.


не знал об этом. Весьма эффектно  

Добавлено через 53 секунды

в конце года будет

В итоге остановился вот на такой структуре:
- Головная БД. Содержит в себе справочники, логически объединены таблицы (MERGE aka MRG_ISAM. Спасибо Akina)
- БД для каждого филиала

Для справочников, логов, переписки тип таблиц MyISAM; для других InnoDB.

Добавлено через 6 минут и 38 секунд
up.
Для бэкапов подумывал об типе ARCHIVE, но отказался