Разрешены ли когда-либо текстовые поля в таблицах фактов?

Question

Есть ли случаи, когда у меня может быть текстовое поле, например описание в таблице фактов?

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

Есть идеи или советы из прошлого опыта?

Спасибо

Answer 1

В форме «вырожденного измерения» это может быть измерение, настолько незначительное, что нет необходимости создавать для него таблицу. Типичным примером могут служить номера счетов: они не являются метриками, но, поскольку они настолько уникальны, было бы ложной экономией иметь 32-битный FK для таблицы Invoices с 128-битным полем CHAR (16) с столько записей, сколько ваша таблица фактов. Это следует делать осторожно, поскольку они расширяют строки таблицы фактов.

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

Answer 2

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

Рассмотрим следующий пример: Расположение: Форт-Лодердейл, Уэст-Палм-Бич, Майами

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

Итак, у меня есть таблица ShippingLocation со следующими столбцами
- ShippingLocationId (PK)
- PackagingSystemId (FK)
- ConveyorBeltTypeId (FK)
- ProductWeightRangeId (FK)
- ShippingLocationName VarChar (200)

Мне кажется очень логичным, что название места доставки будет там же, где определено место доставки и определены его атрибуты. Единственная возможная нормализация, которую я вижу здесь, состоит в том, что я могу взять это к таблице 1 к 1. ИМО, это бесполезная нормализация.