Це смішний спосіб структурування схеми БД, чи я щось зовсім пропускаю?

Я провів неабияку роботу з реляційними базами даних, і думаю, що я досить добре розумію основні поняття хорошого дизайну схем. Нещодавно мені було доручено взяти на себе проект, де БД був розроблений високооплачуваним консультантом. Будь ласка, дайте мені знати, чи моя кишка непомітна - "WTF ??!" - це гарантовано, чи цей хлопець такий геній, що він працює поза моєю цариною?

Розглянута БД - це власний додаток, який використовується для введення запитів працівників. Просто переглянувши невеликий його розділ, ви маєте інформацію про користувачів та інформацію про запит, що робиться. Я б створив це так:

Таблиця користувачів:

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

Таблиця запитів

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

Просте, правда?

Консультант розробив це так (із зразками даних):

UsersTable

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

ВідділиТаблиця

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

Вся база даних побудована так, кожен фрагмент даних укладений у власну таблицю з числовими ідентифікаторами, що пов'язують все разом. Мабуть, консультант читав про OLAP і хотів "швидкості цілочисельних пошуку"

Він також має велику кількість збережених процедур для перехресного посилання на всі ці таблиці.

Це дійсна конструкція для малого та середнього розміру SQL БД?

Дякуємо за коментарі / відповіді ...

Здійснює для мене ідеальний сенс. Це просто дуже нормалізовано, що надає велику гнучкість, яку б у вас не було. Денормалізовані дані - це біль в області попереку.

Я не думаю, що або WTF не має жодних гарантій, або що хлопець робить якийсь шалений геніальний дизайн - це досить стандартна нормалізація бази даних.

Причиною таблиці таблиць є те, що якщо ви не помістите відділи в окрему таблицю, вам доведеться мати справу з користувачами у відділах "Продажі", "Продажі", "Продавці", "Патрила" та "Продаж", якщо ви щось не зробите, щоб запобігти цьому. А наявність додаткової таблиці - це (частина) найкращий спосіб, з якого я це знаю.

Чи має бути таблиця UserDepartment - це більш жорсткий дзвінок, що, звичайно, означає, що жодне рішення не є вихідним і божевільним. З одного боку, це біль, коли весь дизайн та логіка ваших таблиць припускали один відділ на кожного користувача, а потім це змінюється, а з іншого - робити додаткове приєднання без причин протягом багатьох років і років - це реальна можливість, а також біль.

Я особисто погодився б з вами, що таблиця UserDepartment, ймовірно, є надмірною. Навіть якщо він включений, велика ймовірність, що з часом люди напишуть запити, припускаючи, що на відділ працює лише один користувач, тож ви закінчитеся з найгіршим з обох світів - додатковим приєднанням без жодних причин, перш ніж потрібна таблиця, і код все одно не працює, коли дозволено більше ніж один відділ на користувача.

EDIT - Ключовим рушієм того, чи слід підтримувати відносини «багато до багатьох», є, якщо правила бізнесу чіткі. Якщо ви не знаєте, як користувач у декількох підрозділах навіть працюватиме, немає великого сенсу додавати таблицю, оскільки ваш код не може правильно обробити випадки, коли користувач перебуває у кількох відділах.

Уявіть, що ви дозволяли багато відділів на користувача, про всяк випадок. Потім ви застосували ділове правило щодо призначення комісій на основі департаменту. Тоді було дозволено кілька відділів. На щастя, ви також мали передбачення написати свій код комісії таким чином, щоб це врахували. На жаль, ви додали комісії з кожного відділу для користувачів обох. Керівництво хотіло, щоб ви базувались на ролі осіб для кожного продажу. Отже, наскільки добре було заздалегідь мати стіл? Що з іншими таблицями, які у вас були «про всяк випадок», які взагалі ніколи не потрібні?

ПОСЛІДНА РЕДАКЦІЯ - Ще одна причина, за якою консультант, можливо, захотів би додати всі ці посередницькі таблиці, розглядається в цьому подальшому запитанні , відповіді на яке дають деякі причини, чому переробляти базу даних зазвичай важче, ніж код рефакторингу, який, як правило, підштовхне вас до підхід "помістити у всі таблиці, які вам можуть знадобитися".

Якщо вимога полягає у наявності декількох відділів на користувача, ця конструкція має сенс. Єдине рішення про це - UserDepartmentTableнаявність сурогатного ключа, UserDepartmentIDякий не потрібен (просто зробіть UserIdі DepartmentIdскладений первинний ключ).

Якщо користувач коли-небудь належить до одного відділу, ваш дизайн має сенс (хоча таблиця пошуку відділу все-таки буде хорошою справою).

Деякі вимоги не зрозумілі у вашому питанні. Правильна відповідь залежить від того, чого хоче ваш клієнт - Якби я був ти, я б попросив замовника про це:

0-Яка різниця між користувачем та працівником?

1-Припустимо, що працівник = користувач, що робити, якщо працівник змінює відділи?

2-Чи може група працівників зробити 1 запит?

3-Чи може працівник належати до більш ніж одного відділу? Що з генеральним директором

4-Чи є підмножина працівників, яким дозволено робити запити?

5 - Що відбувається із запитом, коли запис працівника видаляється (якщо він є)?

6-Чи можете ви видалити запит? Що відбувається, коли запит видалено (переконайтеся, що ви не видаляєте запис працівника за допомогою RI)

7-Чи може працівник зробити один і той же запит більше одного разу (визначити "те саме")

8 - Як обробляти запити працівників, коли вони залишають компанію (скасовують запити чи видаляють запити?)

Питань може бути більше, але я можу сказати, що рішення залежить від точних вимог та обсягу проекту. Після того, як це визначено, схему можна отримати безпосередньо. Відповідно обидва представлені рішення можуть бути правильними.

Я хотів би додати кілька точкових нотаток форми, що чітко розповідають про деякі потенційні переваги використання таблиці приєднання в той спосіб, який зробив ваш високооплачуваний консультант.

• Правильно індексований (наприклад, якщо UserDepartmentTable індексує два зовнішні ключі), є лише невелика втрата продуктивності такої таблиці приєднання, як це через те, що зовнішні ключі не є унікальними. Якщо зовнішні ключі гарантовано є унікальними, то, за моєю малою теорією баз даних, яку я знаю, шукати не UserDepartmentTable.Departmentє «важче», ніж шукати будь-який інший стовпець Userтаблиці.
• Таблиця приєднання дає вам більше гнучкості для налаштування іншої інформації про асоціацію між користувачем та відділом (наприклад, часові позначки на створення).
• Таблиця приєднання дозволяє "легко" версії "асоціації" (наприклад, коли користувач змінює відділи, запускає якийсь індекс булевого прапора, як UserDepartmentTable.Activeна помилковий, і створює нову асоціацію, яка є активною). Можливо також встановити версію асоціації відділів за допомогою моделі двох таблиць (лише користувач та відділ), але це жорсткіше і потребує додавання хоча б ще одного стовпчика або проведення акробатики бази даних, щоб уникнути дублювання первинних ключів.
• Це дозволяє досить легко призначати асоціації «один-багато» чи «багато-до-одного» або «багато-до-багатьох».

Попри це, є кілька причин НЕ робити те, що зробив ваш високооплачуваний консультант.

• Усі перераховані вище переваги є передчуттям можливих майбутніх потреб, надто ускладнюючи речі на сьогоднішній день. Це не сумісне з YAGNI. Пізніше мігрувати складно, щоб записати міграцію, яка переходить від вашої двосторонньої моделі до моделі таблиці приєднання. Це можна зробити, коли з’явиться потреба в бізнесі. Робити це до цього може бути заплутано.
• Це бентежить інших розробників. Хоча, так, я б сказав, що очікування для веб-розробника вашого статусу (де ви переглядаєте рішення консультантів) було б зрозуміти та визнати таблицю приєднання, це все-таки складніше, ніж потрібно, і враховуючи відсутність потреби в бізнесі, це викликає плутанину.

Без повної структури потрібної інформації я не можу сказати, страшно це чи ні. Але принаймні показаний твір не має дизайну "WTF". Це просто здається, що 3-а нормальна форма структури даних (ну, теоретично, у нас також є 4-а та 5-а також)

Деякі переговори можуть мати місце для UserDepartmentTable між двома школами "природних" та "штучних" клавіш на зображеному фрагменті. Більше нічого, як я бачу

Нормалізація - це правило хорошого розробника / дизайнера БД з багатьох причин, * de * нормалізація використовується іноді в середині розробок для більшої швидкості