Ну, стандартный sql where my_field between date1 and date2 является включающим, поэтому я предпочитаю инклюзивную форму, а не то, что другой неправильный.
Дело в том, что для обычных запросов DW эти (rowValidFrom, rowValidTo) поля в основном вообще не используются, потому что внешний ключ в таблице фактов уже указывает на соответствующую строку в таблице измерений.
Они в основном нужны во время загрузки (здесь речь идет о SCD типа 2), чтобы найти наиболее актуальный первичный ключ для соответствующего бизнес-ключа. В этот момент у вас есть что-то вроде:
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.
Обычно используется одно или несколько из следующих полей:
- 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 ~ $38/GB
Disk ~ $80/TB = 0.078 $/GB
Я предполагаю рейд 5 здесь (три диска), поэтому цена диска будет составлять 0,078 $ / ГБ * 3 = 0,23 $ / ГБ
Итак, для 10 миллионов строк хранить эти 4 поля на диске стоит 0.23 $/GB * 0.14 GB = 0.032 $. Если вся таблица измерений должна быть кэширована в памяти, цена этих полей будет 38 $/GB * 0.14GB = 5.32 $ за 10 миллионов строк. Для сравнения, пиво в моем местном пабе стоит ~ 7 $.
2010 год, и я ожидаю, что у моего следующего ноутбука будет 16 ГБ памяти. Вещи и (лучшие) практики меняются со временем.
EDIT:
Делали некоторые поиски, за последние 15 лет емкость диска среднего компьютера увеличилась примерно в 1000 раз, памяти примерно в 250 раз.