Таблица поиска DATE (1990/01/01: 2041/12/31) - PullRequest
Новая
       25

Таблица поиска DATE (1990/01/01: 2041/12/31)

1 голос
/ 11 апреля 2010

Я использую основную таблицу ДАТЫ для поиска дат и других значений, чтобы контролировать несколько событий, интервалов и расчетов в моем приложении. В нем есть строки для каждого дня, начиная с 01.01.1990 по 31.12.2041.

Один из примеров того, как я использую эту справочную таблицу:

  1. Клиент заложил товар на: ЯНВ-31-2010
  2. Клиент возвращается в период с 3 мая по 10 мая, чтобы сделать ставку на интерес, чтобы избежать потери товара.
  3. Если он выплачивает проценты за 1 месяц, работник вводит «1» и приложение ищет пешку
    дата (JAN-31-2010) в основной таблице даты и помещает FEB-28-2010 в соответствующие проценты дата pymt. FEB-28 возвращается, потому что FEB-31 не существует! Если 2010 год был високосным, это возвратил бы 29 февраля.
  4. Если клиент платит 2 месяца, возвращается МАР-31-2010. 3 месяца, 30 апреля ... Если клиент выплачивает более 3 месяцев или другой период, не охватываемый таблицей поиска дат, Сотрудник вручную вводит соответствующую дату.

Вот как выглядит таблица поиска даты: 

{ Copyright 1990:2010, Frank Computer, Inc. }

{ DBDATE=YMD4- (correctly sorted for faster lookup) }

CREATE TABLE     datemast 
(
 dm_lookup       DATE,    {lookup col used for obtaining values below}
 dm_workday      CHAR(2), {NULL=Normal Working Date,}
                          {NW=National Holiday(Working Date),}
                          {NN=National Holiday(Non-Working Date),}
                          {NH=National Holiday(Half-Day Working Date),}
                          {CN=Company Proclamated(Non-Working Date),}
                          {CH=Company Proclamated(Half-Day Working Date)}

 {several other columns omitted}

 dm_description CHAR(30), {NULL, holiday description or any comments}
 dm_day_num     SMALLINT, {number of elapsed days since begining of year}
 dm_days_left   SMALLINT, (number of remaining days until end of year}

 dm_plus1_mth   DATE,     {plus 1 month from lookup date}
 dm_plus2_mth   DATE,     {plus 2 months from lookup date}
 dm_plus3_mth   DATE,     {plus 3 months from lookup date}
 dm_fy_begins   DATE,     {fiscal year begins on for lookup date}
 dm_fy_ends     DATE,     {fiscal year ends on for lookup date}
 dm_qtr_begins  DATE,     {quarter begins on for lookup date}
 dm_qtr_ends    DATE,     {quarter ends on for lookup date}
 dm_mth_begins  DATE,     {month begins on for lookup date}
 dm_mth_ends    DATE,     {month ends on for lookup date}
 dm_wk_begins   DATE,     {week begins on for lookup date}
 dm_wk_ends     DATE,     {week ends on for lookup date}

 {several other columns omitted}
)
IN "S:\PAWNSHOP.DBS\DATEMAST";

Есть ли лучший способ сделать это или это крутой метод?

Ответы [ 4 ]

2 голосов
/ 11 апреля 2010

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

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

1 голос
/ 11 апреля 2010

Отличный способ генерации набора строк в Oracle - использовать функцию иерархического запроса, connect by. Я опубликовал пример такого использования в другой теме .

Это дает большую гибкость без издержек PL / SQL конвейерной функции.

1 голос
/ 11 апреля 2010

Это зависит от того, какую базу данных вы используете. SQL Server ужасно поддерживает временные данные, и я почти всегда использую таблицу фактов дат. Но базы данных, такие как Oracle, Postgres и DB2, имеют действительно хорошую поддержку, и обычно более эффективно вычислять даты на лету для приложений OLTP.

Например, в Oracle есть функция last_day () для получения последнего дня месяца и функция add_months () для добавления месяцев. Обычно в Oracle я использую конвейерную функцию, которая принимает даты начала и окончания и возвращает вложенную таблицу дат.

0 голосов
/ 24 июня 2010

ОК, поэтому я протестировал свое приложение, используя 31 день / месяц для расчета процентных ставок, и ломбарды им довольны!Местный закон молится следующим образом: от пешки или последней инт.pymt.дата до 5 истекших дней, 5% от основной суммы, от 6 до 10 дней = 10%, от 11 до 15 дней = 15% и от 16 дней до 1 "месяца" = 20%.

Таким образом, таблица процентовтеперь определяется следующим образом: 

NUMBER OF ELAPSED DAYS SINCE
PAWN DATE OR LAST INTEREST PYMT

 FROM     TO  ACUMULATED
  DAY    DAY    INTEREST
-----   ----  ----------
    0      5       5.00%
    6     10      10.00%
   11     15      15.00%
   16     31      20.00%
   32     36      25.00%
   37     41      30.00%
   42     46      35.00%
   47     62      40.00%

   [... until day 90 (forfeiture allowed)]
   from day 91 to 999, daily prorate based on 20%/month.

Произошло ли что-то плохое в Великобритании на MAR-13 или SEP-1752?

...