Чи нормалізуються відносини один на один?

Подумайте, у нас є великий набір статистичних даних для запису; наприклад 20-30 INTстовпців. Чи краще зберігати весь набір в одній таблиці, оскільки всі вони належать до запису АБО створюють іншу таблицю, пов’язану із співвідношенням один на один.

Перевага першого - уникати JOINшвидкого доступу до всіх статистичних даних для відповідного запису.

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

Загалом, я хочу знати, чи корисно роздільно використовувати різні набори даних для одного запису?

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

Щоб відповісти на ваше запитання щодо практичності відносин 1: 1, бувають випадки, коли це ідеально корисна конструкція, наприклад, коли у вас є підтипи з чіткими предикатами (стовпцями).

Причини, якими ви користуєтесь відносинами 1: 1, залежать від вашої точки зору. DBA, як правило, сприймають усе як рішення про ефективність. Моделі даних та програмісти, як правило, вважають ці рішення орієнтованими на дизайн або модель. Насправді між цими точками зору багато перекриттів. Це залежить від ваших перспектив та пріоритетів. Ось кілька прикладів мотивації відносин 1: 1:

• У вас є кілька підмножин стовпців, які дуже широкі, і ви хочете їх фізично відокремити у сховищі з міркувань продуктивності.

• У вас є деякий підмножина стовпців, які не читаються і не оновлюються часто, і ви хочете відрізнити їх від часто використовуваних стовпців з міркувань продуктивності.

• У вас є колонки, необов’язкові в цілому, але вони є обов'язковими, якщо ви знаєте, що запис певного типу.

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

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

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

Тож ви можете бачити, що іноді драйвер - це продуктивність, іноді це чистота моделі або просто бажання повністю скористатися правилами декларативної схеми.

Основні причини, чому ви використовуєте відображення «один на один» для розбиття великої таблиці на дві, - це, наприклад, причини продуктивності:

a) У таблиці є двійкові / clob / blob дані в часто доступній таблиці, отже, уповільнення продуктивності, оскільки великі стовпці обробляються по-різному.

б) У таблиці є багато стовпців, до яких звертаються різні запити, отже, продуктивність знижується, тому ви пересунете пов’язані стовпці в окрему таблицю, щоб покращити продуктивність доступу

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