Проект базы данных с двумя таблицами для большого проекта

Question

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

Например, вот первая таблица с данными:

KEY, DATA
0,   Name
1,   First Name
2,   Last Name
3,   Position
4,   Title
5,   Reports To
6,   John
7,   Smith
8,   Developer
9,   CTO

А вот вторая таблица, объединяющая данные:

KEY, GROUP_KEY, DATA_KEY, CHILD_KEY
0,   NULL,      0,        NULL
1,   0,         1,        2
2,   0,         2,        NULL
3,   NULL       3,        NULL
4,   3,         4,        5
5,   3,         5,        NULL
6,   0,         6,        7
7,   0,         7,        NULL
8,   3,         8,        9
9,   3,         9,        NULL

По сути, первая строка во второй таблице (ключ 0) определяет новую группу, которая называется Name. Следующие две строки определяют «столбцы», принадлежащие этой группе. Четвертая строка (поз. 3) определяет другую группу, которая называется «Позиция», и снова следующие две строки определяют «столбцы», которые принадлежат группе. Последние четыре строки «присваивают» значения «Джон и Смит» группе «Имя», а значения «Разработчик и технический директор» группе «Положение».

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

Мой новый менеджер не слишком увлечен этим дизайном, и лично я никогда не сталкивался с ним. Поскольку это будет проект C #, использующий либо платформу Entity, либо NHibernate для взаимодействия с базой данных, такой дизайн базы данных кажется сложной задачей для реализации в любой из этих платформ. Есть ли название для такого дизайна, чтобы я мог исследовать его дальше? Есть ли основные плюсы или минусы для этого дизайна? В документации упоминается, что это сделано для повышения производительности и «гипер» нормализации.

Answer 1

Это похоже на антипаттерн Inner-Platform . У вас есть СУБД, и вместо того, чтобы нормализовать ваши данные в отношения, вы решаете использовать ее как плоский файл и выгружать каждый элемент данных в отдельную строку, ожидая, что во время выполнения эти строки будут объединены в отношения путем объединения столбцов с волшебным ключом.

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

Ваши архитекторы, вероятно, думали, что они обеспечивают «расширяемость». Смотри! Вы можете добавить любые данные любого вида в конец базы данных! Это редко полезно; это делает поиск данных и обеспечение достоверности почти невозможным. Если вам действительно необходимо добавить какой-либо тип данных во время выполнения, каждая база данных SQL, начиная с 1970-х годов, допускает динамический SQL и изменение схемы во время выполнения.

-1. Не будет покупать снова.