Таблица Нормализация без значений домена

Question

Существует дискуссия между нашей командой ETL и Data Modeler о том, следует ли нормализовать таблицу или нет, и я надеялся получить некоторую перспективу от интернет-сообщества.

В настоящее время таблица настроена как таковые

 
    MainTable    LookupTable 
    PrimaryKey (PK)   Code (PK) 
    Code (FK)    Name 
    OtherColumns 

• Обе таблицы только заселяются периодическим файл (с 3-го участника) через работу ETL
  • Одиночный запись в файле содержит все атрибуты в обеих таблицах для одной строки)
• Файл, заполняющий эти таблицы, является дельта (только файлы с некоторыми изменениями в них находятся в файле)
  • Одно изменение одного атрибута для одной записи (опять же только третьей стороной) приведет к тому, что все данные для этого запись в файле
• Значение домена для кода и имени не известны.

Вопрос: Должен ли LookupTable быть денормализован в MainTable.

• Команда ETL: Да. С помощью этой настройки каждая строка из файла сначала должна будет проверить вторую таблицу, чтобы увидеть, есть ли там их FK (вставить, если это не так), а затем добавить строку MainTable. Больше кода, ухудшение производительности и да немного больше места. Однако, независимо от изменения LookupTable.Name от стороннего участника, периодический файл будет отражать каждую затронутую строку, и нам все равно придется анализировать каждую строку. Если сосредоточиться в MainTable, все, что есть, это простое обновление или вставка.
• Data Modeler: Это стандартный хороший дизайн базы данных.

Любые мысли?

Answer 1

Построить прототипы. Сделайте измерения.

Вы начали с этого, о чем говорит ваш модельер данных, является стандартным хорошим дизайном базы данных.

 
    MainTable    LookupTable 
    PrimaryKey (PK)   Code (PK) 
    Code (FK)    Name 
    OtherColumns 

Он прав. Но это тоже хороший дизайн базы данных.

 
    MainTable 
    PrimaryKey (PK) 
    Name 
    OtherColumns 

Если все обновления этих таблиц приходят только от работы ETL, вы не должны быть очень обеспокоены обеспечения целостности данных с помощью внешних ключей. Задача ETL в любом случае добавила новые имена в таблицу поиска, независимо от того, каковы их значения. Целостность данных зависит главным образом от системы, данные извлекаются от. (И качество работы ETL.)

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

Если они выполняют рядную обработку, нанимайте новых ребят ETL. Шутки в сторону.

Больше кода, ухудшение характеристик и да немного больше места.

Они нуждаются в немного больше кода для обновления двух таблиц вместо одного. Сколько времени требуется для написания операторов SQL? Как долго их запускать? (Как долго каждый раз?)

Хуже производительность? Может быть. Возможно, нет. Если вы используете код фиксированной ширины, например целое число или символ (3), обновления по кодам не повлияют на ширину строки. А так как коды короче имен, на странице может помещаться больше строк. (Не имеет смысла использовать код, который длиннее, чем имя.) Больше строк на страницу обычно означает меньше ввода-вывода.

Меньше пространства, конечно. Потому что вы храните короткий код вместо длинного имени в каждой строке «MainTable».

Например, средняя длина названия страны составляет около 11,4 символов. Если вы использовали 3-значные коды стран ISO, вы сохранили бы в среднем 8,4 байт в строке в «MainTable». Для 100 миллионов строк вы сохраняете около 840 миллионов байт. Размер этой таблицы поиска пренебрежимо мал, около 6k.

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