Назад | Перейти на главную страницу

Проектирование базы данных SQL Server для процесса архивирования

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

В текущем дизайне MS Access мы загружаем данные ежедневно, которые затем обрабатываются в пользовательском интерфейсе. Поскольку размер Access ограничен 2 ГБ, мы делаем следующее.

  1. Утренний импорт - сначала удаляются данные предыдущего дня, затем загружаются новые.
  2. В течение дня пользователи обрабатывают данные
  3. В конце дня мы делаем снимок базы данных (в основном прямые копии базы данных Access, которые хранятся для пользователей, чтобы они могли вернуться во времени для исследования)

В новой версии всем данным, вставленным в каждую таблицу, будет назначена бизнес-дата, которая является датой добавления в таблицу. Затем во внешнем интерфейсе пользовательский интерфейс будет выполнять поиск по дате, чтобы получить записи за этот день.

Прямо сейчас мы думаем о следующем:

  1. Создайте 2 базы данных - одну на текущий день, а затем архив. Данные, которые обычно удаляются ежедневно, будут перемещаться в БД архива каждое утро. Для интерфейса нам нужно будет UNION 2 базы данных для получения окончательного набора результатов
  2. Создайте 2 схемы в одной базе данных. Один для текущего, а затем для архива. Снова нам придется union данные, но они будут в той же базе данных
  3. просто оставьте данные в таблицах текущего дня, нам не понадобится объединение данных для поиска пользовательского интерфейса.

Позвольте мне добавить, что мы должны хранить данные, загруженные в базу данных, как минимум за 6 лет, поэтому размеры таблиц будут довольно большими.

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

У каждого есть свои плюсы и минусы, и есть вариант, который вы не рассматривали. Вот некоторые общие комментарии, надеюсь, это поможет.

  1. Создать 2 базы данных
    • Обслуживание становится немного более сложным: две базы данных нужно синхронизировать, две базы данных для управления резервными копиями, проверки производительности и т. Д.
    • Внешний доступ становится немного сложнее, когда вам нужно ОБЪЕДИНЯТЬ данные. Я бы рекомендовал настроить View, чтобы справиться с этим, вместо того, чтобы кодировать логику в вашем интерфейсе.
    • Операции обслуживания более гибкие: резервное копирование, переиндексация, блокировки таблиц и т. Д. Могут происходить независимо в двух базах данных, и вы потенциально можете разделить их на разные хранилища для повышения производительности.
  2. Создать 2 схемы
    • Я не вижу в этом подходе плюсов, которых нет в двух других вариантах.
    • Минус этого подхода в том, что вы усложняете доступ, но не получаете любой(?) дополнительное обслуживание или гибкость производительности взамен.
  3. Сохраняйте единую БД, простую схему:
    • Это имеет преимущество простоты. Вероятно, это лучший способ пойти, если вы не знаете, что вам нужно в долгосрочной перспективе, и если у вас нет большого опыта с точки зрения обслуживания, проектирования SQL Server и т. Д.
    • Главный риск заключается в том, что вы получите слишком много данных в одном месте, но это, вероятно, можно компенсировать правильной индексацией - чтобы база данных стала по-настоящему неуправляемой, вам, вероятно, придется потратиться на сотни гигабайт.
    • Если вы обнаружите, что вам нужно разделить вещи по соображениям производительности позже, вы всегда можете реализовать вариант 1 или вариант 4 (или даже 2, я думаю) позже - с представлением вы можете «скрыть» реализацию детали из вашего внешнего интерфейса и, возможно, даже из ваших процессов ETL (хотя вы, вероятно, этого не захотите)
  4. дополнительная опция Разбиение на несколько файловых групп
    • Вы можете хранить свои данные в одной базе данных, но при этом получаете преимущества хранения данных в разных файлах, возможно, в разных местах.
    • Это, вероятно, лучший способ справиться с «заменой» и «заменой» очень больших наборов данных (возможно, что-то на будущее)
    • Вам все равно нужно создать представление для консолидации базовых данных.
    • Это по-прежнему довольно сложно, и вы не захотите делать легкомысленно - вероятно, вы бы занялись этим, если бы обнаружили, что начали обрабатывать необоснованно большие объемы данных на ежедневной основе.

Случайная ссылка на разбиение, которая выглядит неплохо (извините, не выполнил тщательный поиск справочных материалов, и у них нет под рукой): http://www.sqlservercentral.com/articles/partition/64740/

Вы можете предоставить пользователям «текущие» данные с помощью представлений (date-math). Единая база данных.