Какова наилучшая практика представления временных интервалов в хранилище данных?

в целом я согласен с ответом Дэвида (проголосовал), поэтому я не буду повторять эту информацию. Далее:

вы действительно имели в виду полуоткрыто ([StartDate, EndDate])

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

• для меня, полуоткрытый (Дата начала)
• EndDate является производным от следующей строки.
• рекомендуется
• это не обычное использование, потому что (a) общие разработчики не знают в эти дни и (b) они слишком ленивы или не знают, как кодировать необходимый простой подзапрос
• он основан на опыте, в больших банковских базах данных

см. это для деталей:

ссылка на последние очень похожие вопросы и данные Модель

ответы на комментарии

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

1. да. Абсолютно. Любой здравомыслящий человек (который не изучает информатику из wiki) должен сомневаться в этом. Это просто противоречит законам физики.

2. можете ли вы понять, что многие люди, не понимая нормализации или баз данных (вам нужно 5NF), производят Ненормализованные медленные кучи данных, и их знаменитое оправдание (написанное "гуру") " денормализовано для спектакль" ? Теперь вы знаете, что это экскременты.

3. те же самые люди, не понимая нормализации или datawarehouses (вам нужно 6NF), (a) создайте скопировать базы данных и (b) всевозможные странные и замечательные структуры для "улучшения" запросов, включая (c) еще большее дублирование. И угадайте, какое у них оправдание ? "denormalized for performance".

   • это преступно, и "гуру" не лучше, они подтверждают он.

   • ложная информация не становится более правдивой, повторяя ее, и Бог знает, что они повторяют ее до бесконечности .

4. простая истина (недостаточно сложная для людей, которые оправдывают datawarehouses с (1) (2) (3) ), это 6NF, выполненный правильно, и хранилище данных. Я предоставляю как базу данных, так и хранилище данных из одних и тех же данных со скоростью хранилища. Нет второй системы; нет второй платформы; нет копий; нет ETL; нет синхронизации копий; нет пользователей, чтобы перейти к двум источникам. Конечно, требуется умение и понимание производительности, а также немного специального кода для преодоления ограничений SQL (вы не можете указать 6NF в DDL, вам нужно реализовать каталог).

   • зачем реализовывать StarSchema или Снежинка, когда чистая нормализованная структура уже имеет полную возможность измерения-факта.
     .

5. даже если вы этого не сделали, если вы просто сделали традиционную вещь и вытравили эту базу данных в отдельную систему datawarehouse, в ней, если вы устранили дублирование, уменьшили размер строки, уменьшили индексы, конечно, она будет работать быстрее. В противном случае, это бросает вызов законам физики: толстые люди будут бежать быстрее, чем худые люди; корова будет бежать быстрее лошади.

   • справедливо, если у вас нет нормализованной структуры, тогда что-нибудь, пожалуйста, чтобы помочь. Вот они и придумывают StarSchemas, снежинки и всевозможные размеры-то конструкции.

и, пожалуйста, поймите, только неквалифицированные, неопытные люди верят во все эти мифы и магию. Образованные опытные люди имеют свои с трудом заработанные истины, они не нанимают знахарей. Эти "гуру" только подтверждают, что толстяк выигрывает гонку не из-за погоды или звезд, а из-за чего угодно.--7-->но вещь, которая решит проблему. Некоторые люди завязывают свои трусики в узел, потому что я прямолинейна, я говорю толстяку сбросить вес; но настоящая причина их расстройства в том, что я разрушаю их заветные мифы, которые держат их оправданными быть толстыми. Люди не любят меняться.

• одно дело. это когда-либо оправдано отклоняться. Правил нет черное или белое-это не одиночные правила в изоляции. Мыслящий человек должен рассматривать их все вместе; расставлять приоритеты в соответствии с контекстом. Вы не найдете ни всеIdключи ИОТ , ни ноль IdIoT ключи в моих базах данных, но каждый Id ключ был тщательно продуман и обоснован.

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

  • но никогда не начинайте с суррогатов. Это серьезно затрудняет вашу способность понимать данные; нормализовать; моделировать данные.

    • вот один вопрос▶/ответить◀ (многих!) где человек застрял в процессе, не в состоянии идентифицировать даже основные сущности и отношения, потому что он застрял IdIoT ключи на все в начале. Проблема решена без обсуждения, в первой итерация.
      .
• ладно, еще кое-что. Изучайте этот предмет, приобретайте опыт и продвигайтесь дальше самостоятельно. Но не пытайтесь учить этому или обращать других, даже если свет зажегся, и вы жаждете. Особенно если вы полны энтузиазма. Почему ? Потому что, когда вы сомневаетесь в Совете знахаря, вся деревня линчет вас, потому что вы нападаете на их заветные мифы, их комфорт; и вам нужен мой опыт, чтобы прижать ведьму врачи (просто проверьте его в комментариях!). Дайте ему несколько лет, получить реальный опыт, а затем взять их на.

если вы заинтересованы, следуйте этому ▶вопрос/ответ◀ в течение нескольких дней, это будет отличный пример того, как следовать методологии IDEF1X, как выявить и отразить эти идентификаторы.

ну, стандартный sql where my_field between date1 and date2 является инклюзивным, поэтому я предпочитаю инклюзивную форму-не то, чтобы другая была неправильной.

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

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

select ProductKey
from dimProduct
where ProductName = 'unique_name_of_some_product'
  and rowValidTo > current_date ;

или, если вы предпочитаете создать ключ-конвейер перед загрузкой:

insert into keys_dimProduct (ProductName, ProductKey)  -- here ProductName is PK
select ProductName, ProductKey 
from dimProduct
where rowValidTo > current_date ;

это помогает загрузке, потому что легко кэшировать таблицу ключей в память перед загрузкой. Например, если ProductName имеет тип varchar(40) и ProductKey целое число, таблица ключей составляет менее 0,5 ГБ на 10 миллионов строк, легко кэшировать для поиска.

другие часто встречающиеся вариации включают were rowIsCurrent = 'yes' и where rowValidTo is null.

In общие, используется одно или несколько из следующих полей:

• rowValidFrom
• rowValidTo
• rowIsCurrent
• rowVersion

в зависимости от конструктора DW и иногда используемого инструмента ETL, потому что большинство инструментов имеют загрузочные блоки SCD типа 2.

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

предположим, я использую все поля row_.

rowValidFrom date       = 3 bytes
rowValidTo   date       = 3 bytes
rowIsCurrent varchar(3) = 5 bytes
rowVersion   integer    = 4 bytes

итого 15 байт. Можно утверждать, что это 9 или даже 12 байт слишком много-хорошо.

для 10 миллионов строк это составляет 150,000,000 байт ~ 0,14 ГБ

я посмотрел цены с сайта Dell.

Memory ~ /GB
Disk   ~ /TB = 0.078 $/GB 

я предположу raid 5 здесь (три диска), поэтому цена диска будет 0.078 $ / GB * 3 = 0.23 $ / GB

Итак, для 10 миллионов строк хранить эти 4 поля на диске стоит 0.23 $/GB * 0.14 GB = 0.032 $. Если вся таблица измерений должна быть кэширована в память, цена этих полей будет 38 $/GB * 0.14GB = 5.32 $ на 10 миллионов строк. Для сравнения, пиво в моем местном пабе стоит ~ 7$.

год 2010, и я ожидаю, что мой следующий ноутбук будет иметь память 16GB. Вещи и (лучшие) практики меняются со временем.

EDIT:

сделал некоторые поиск в за последние 15 лет емкость диска среднего компьютера увеличилась примерно в 1000 раз, памяти-примерно в 250 раз.