Назад |
Перейти на главную страницу
Проектирование базы данных SQL Server для процесса архивирования
В настоящее время я работаю над большим проектом по перемещению приложения MS Access на сервер SQL. Наша команда обсуждала лучший способ разработать часть новой базы данных, поэтому я решил, что обращусь за обратной связью.
В текущем дизайне MS Access мы загружаем данные ежедневно, которые затем обрабатываются в пользовательском интерфейсе. Поскольку размер Access ограничен 2 ГБ, мы делаем следующее.
- Утренний импорт - сначала удаляются данные предыдущего дня, затем загружаются новые.
- В течение дня пользователи обрабатывают данные
- В конце дня мы делаем снимок базы данных (в основном прямые копии базы данных Access, которые хранятся для пользователей, чтобы они могли вернуться во времени для исследования)
В новой версии всем данным, вставленным в каждую таблицу, будет назначена бизнес-дата, которая является датой добавления в таблицу. Затем во внешнем интерфейсе пользовательский интерфейс будет выполнять поиск по дате, чтобы получить записи за этот день.
Прямо сейчас мы думаем о следующем:
- Создайте 2 базы данных - одну на текущий день, а затем архив. Данные, которые обычно удаляются ежедневно, будут перемещаться в БД архива каждое утро. Для интерфейса нам нужно будет
UNION
2 базы данных для получения окончательного набора результатов - Создайте 2 схемы в одной базе данных. Один для текущего, а затем для архива. Снова нам придется
union
данные, но они будут в той же базе данных - просто оставьте данные в таблицах текущего дня, нам не понадобится объединение данных для поиска пользовательского интерфейса.
Позвольте мне добавить, что мы должны хранить данные, загруженные в базу данных, как минимум за 6 лет, поэтому размеры таблиц будут довольно большими.
Я просто пытаюсь найти лучший подход к такого рода проблемам. Я уверен, что мы не единственные в подобной ситуации. Я открыт для любых предложений, мыслей о том, как нам действовать дальше.
У каждого есть свои плюсы и минусы, и есть вариант, который вы не рассматривали. Вот некоторые общие комментарии, надеюсь, это поможет.
- Создать 2 базы данных
- Обслуживание становится немного более сложным: две базы данных нужно синхронизировать, две базы данных для управления резервными копиями, проверки производительности и т. Д.
- Внешний доступ становится немного сложнее, когда вам нужно ОБЪЕДИНЯТЬ данные. Я бы рекомендовал настроить View, чтобы справиться с этим, вместо того, чтобы кодировать логику в вашем интерфейсе.
- Операции обслуживания более гибкие: резервное копирование, переиндексация, блокировки таблиц и т. Д. Могут происходить независимо в двух базах данных, и вы потенциально можете разделить их на разные хранилища для повышения производительности.
- Создать 2 схемы
- Я не вижу в этом подходе плюсов, которых нет в двух других вариантах.
- Минус этого подхода в том, что вы усложняете доступ, но не получаете любой(?) дополнительное обслуживание или гибкость производительности взамен.
- Сохраняйте единую БД, простую схему:
- Это имеет преимущество простоты. Вероятно, это лучший способ пойти, если вы не знаете, что вам нужно в долгосрочной перспективе, и если у вас нет большого опыта с точки зрения обслуживания, проектирования SQL Server и т. Д.
- Главный риск заключается в том, что вы получите слишком много данных в одном месте, но это, вероятно, можно компенсировать правильной индексацией - чтобы база данных стала по-настоящему неуправляемой, вам, вероятно, придется потратиться на сотни гигабайт.
- Если вы обнаружите, что вам нужно разделить вещи по соображениям производительности позже, вы всегда можете реализовать вариант 1 или вариант 4 (или даже 2, я думаю) позже - с представлением вы можете «скрыть» реализацию детали из вашего внешнего интерфейса и, возможно, даже из ваших процессов ETL (хотя вы, вероятно, этого не захотите)
- дополнительная опция Разбиение на несколько файловых групп
- Вы можете хранить свои данные в одной базе данных, но при этом получаете преимущества хранения данных в разных файлах, возможно, в разных местах.
- Это, вероятно, лучший способ справиться с «заменой» и «заменой» очень больших наборов данных (возможно, что-то на будущее)
- Вам все равно нужно создать представление для консолидации базовых данных.
- Это по-прежнему довольно сложно, и вы не захотите делать легкомысленно - вероятно, вы бы занялись этим, если бы обнаружили, что начали обрабатывать необоснованно большие объемы данных на ежедневной основе.
Случайная ссылка на разбиение, которая выглядит неплохо (извините, не выполнил тщательный поиск справочных материалов, и у них нет под рукой): http://www.sqlservercentral.com/articles/partition/64740/
Вы можете предоставить пользователям «текущие» данные с помощью представлений (date-math). Единая база данных.