Совет по проектированию баз данных - Годовые данные

Question

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

В этом примере существуют две таблицы - CareerField и курс. Эти таблицы могут быть определены как многие для многих. В области карьеры может быть много курсов, и курс может принадлежать во многих областях карьеры (подумайте о базовом классе, таком как английский для любой степени).

Скажите в 2012 году место карьеры, называемое Плотничество, с курсом, называемым Basic Woodworking. В 2013 году поле карьеры называется «Плотничество и дизайн» и имеет курс «Основополагающая древесина».

Область карьеры не нова - просто переименована, но я должен хранить данные за все прошлые годы (в течение последних лет) для исторических целей. Поэтому я не могу просто переименовать столярную запись в «Плотницкие работы и дизайн».

По существу, я должен создать новый год на основе всех данных курса за предыдущий год, тогда изменения нового года будут происходить, если курсы будут удалены, переименованы поля профессии и т. Д. Интерфейс интерфейса будет иметь возможность создать новый год - все табличные данные скопированы для 2013 года из существующих данных (с использованием того, который был выбран в предыдущем году для переноса данных). Существует вероятность добавления новых полей, которые не относятся к предыдущим годам.

Какова наилучшая практика для чего-то подобного? Я использовал более высокое программное обеспечение ERP (например, Datatel), которое бы упало на новую таблицу за каждый год. Это кажется избыточным и плохой практикой, но опять же, я только разрабатываю базы данных менее двух лет.

Я ищу совет, как обращаться с таким сценарием. Реальное решение будет содержать в настоящее время около 16 таблиц, поэтому каждая таблица будет дублироваться в приведенном выше примере.

Спасибо за ввод.

Answer 1

Я бы использовал таблицы, которые вы указали в текущем году, и иметь те же таблицы в структуре (другое имя), которые хранят историческую информацию. Когда год закрыт, вы передаете информацию за текущий год в исторические таблицы. Если вам нужно добавить некоторые поля в существующую таблицу, вам придется применить эти изменения к обоим (таблица «Исторический» и «Текущий год») Исторические таблицы должны быть прочитаны только, и ваше приложение будет иметь доступ к «текущему году», таблицы для чтения/записи/обновления и истории для извлечения отчетов.

Answer 2

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

Так что если вы знаете, что он будет всегда год и никогда к семестру, создайте таблицу под названием AcademicYear, которая включает в себя AcademicYearID, который может быть фактическим годом в качестве ПК (используйте автоинкремент, если вы можете сломать вещи меньше, чем летних периодов и называть его AcademicPeriod вместо года) и StartDate (требуется и использовать тип данных даты) и EndDate (не требуется, но все же тип данных даты). Теперь добавьте академическийYearID в каждую родительскую таблицу, которую вы хотите разделить на год. Таким образом, ваш CareerField добавит к нему AcademicYearID, и ваш курс добавит его только в том случае, если вы захотите запросить учебный год, не пройдя через таблицу CareerField.

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

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

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