Стратегии обработки финансового года в дизайне базы данных

Question

Под финансовым годом я подразумеваю все данные в базе данных (во всех таблицах), которые произошли в конкретном году. Допустим, мы создаем приложение, которое позволяет пользователю выбирать разные годы.

Какой способ реализации этого вы бы предпочли и почему:

1. Отдельные данные финансового года на основе нескольких отдельных экземпляров базы данных (например, при каждом начале финансового года вы можете создать новый экземпляр без данных)
2. Храните все в одной базе данных, но с логикой, которая автоматически отделяет записи разных лет.

Лично я «видел» оба метода и выбрал бы второй. Единственный аргумент, который я могу придумать для первого метода, - это иметь меньше записей в случае, если это действительно большие базы данных - но, тем не менее, вы можете «архивировать» старые записи, объединяя их в сводки или каким-либо другим способом. Что ты думаешь?

Answer 1

Нет необходимости в дублировании. Отметка времени может быть достаточно хорошей, но для заимствования из хранилища данных можно создать «измерение даты». Это таблица со строкой в ​​день и столбцом для атрибута даты. Некоторыми из этих столбцов могут быть финансовый год, финансовый квартал и т. Д. Затем вы добавляете DateKey в таблицу транзакций и присоединяете измерение даты при запросе.

Что-то вроде:

select sum(t.Total)
from Transactions as t
join dimDate as d on d.DateKey = t.DateKey
where d.FiscalYearQuarter = 'F2009-Q3';

Таблица измерений даты может выглядеть примерно так:

CREATE TABLE dimDate
  ( 
   DateKey int                      -- 20090814
  ,FullDate date                    -- 2009-8-14
  ,FullDateDescription varchar(50)  -- Friday August 14, 2009
  ,SQLDateStamp varchar(10)         -- 2009-08-14
  ,DayOfWeek varchar(10)            -- Friday
  ,DayNumberInWeek int              -- 6
  ,DayNumberInMonth int             -- 14
  ,DayNumberInYear int              -- 226

  -- many more here

  ,FiscalYear int                   -- 2009
  ,FiscalQuarter char(3)            -- FQ3
  ,FiscalHalf char(3)               -- FH2
  ,FiscalYearQuarter varchar(8)     -- F2009-Q3
  ,FiscalYearHalf varchar(8)        -- F2009-H2 
  );

Вы бы предварительно загрузили dimDate, из прошлого в прошлое, в будущее; Для 100 лет требуется 36,5 тыс. Строк - не так много для любой БД.

Answer 2

Отдельные данные финансового года на основе нескольких отдельных экземпляров базы данных (например, при каждом начале финансового года вы можете создать новый экземпляр без данных)

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

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

Храните все в одной базе данных, но с логикой, которая автоматически отделяет записи разных лет.

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

Answer 3

Существует третий альтернативный вариант.

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

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

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

Затем, сокращая все ваши данные, основанные на датах, по финансовым годам, финансовым кварталам или любым другим вопросам.объединение и группировка.Вы даже можете автоматизировать создание разных временных периодов для одних и тех же данных.

Я сделал это, и это работает.Это особенно хорошо в отчетных базах данных и хранилищах данных.

Answer 4

Каждый объект должен иметь свой финансовый год как часть метаданных / статических данных.

Исходя из этого, вы легко справляетесь с перерывами на финансовый год, и, как правило, базы данных могут обрабатывать ОЧЕНЬ БОЛЬШИЕ объемы данных, поэтому у вас не должно быть проблем.

Использование правильной индексации значительно повысит производительность ваших запросов, поэтому беспокоитесь о производительности, как только попадете в ловушку. А пока беспокойтесь о коде