Вивчаю ось це питання. там така фраза у відповіді
Composite primary keys typically arise when mapping from legacy databases when the database key is comprised of several columns.
Я правильно розумію, що legacy це практично синонім слову "застарілий"?
Якщо так, то чи варто, при розробці нової програми і нової бази даних, робити складові ключі? Або просто додати ще один стовпець, який по суті нічого не буде робити, адже всю роботу з бд зазвичай виконують фреймворки?
заданий 5 Березня '15 о 21:10
Я зазвичай користуюся таким правилом: якщо на таблицю інші таблиці не посилаються, значить в цій таблиці можна використовувати складовою ключ. Це вірно не завжди (наприклад, отриманий ключ може бути не унікальним, або в ключі доведеться використовувати об'ємні поля і т.п.), але спрацьовує часто. Тоді ми економимо пам'ять на зайвому індексі (вірніше на його відсутності), а значить збільшуємо ефективність індексів. - BOPOH 6 Березня '15 в 6:08
Це досить Холіварние питання, і єдино вірної відповіді тут немає. Але найчастіше думки сходяться до того, що ключі повинні бути не складовими, і в них не повинно зберігатися будь-якої інформації про сутність. Тобто це має бути якийсь (зазвичай целочисленное автоматично інкрементіруемое) поле, що забезпечує унікальність запису
Вважаю, переклад за змістом: "Складові первинні ключі зазвичай виникають при зіставленні з існуючими таблицями бази даних, коли ключ таблиці складається з декількох стовпців."
legacy тут це практично синонім слову "існуючий".
При розробці нової таблиці теоретично не слід створювати надмірність інформації новим ключовим полем якщо існуюча в ній комбінація зовнішніх ключів (або інших полів) вже є унікальним ключем.
Але практично пошук по додатковому полю унікального ключа може бути швидше або суб'єктивно простіше для розробника і таким чином мати сенс для досягнення необхідного результату :)
відповідь дан 20 Жовтня '15 в 5:17
Існує кілька застарілий підхід в проектування БД, іноді помилково званий "академічним", коли первинний ключ відносини вибирається як один з природних ключів відносини. Зазвичай таким ключем стає ім'я записи.
У наведеному вами питанні саме такий підхід і використовується. Але цей підхід застарів з багатьох причин. Перша: первинний ключ запису - це те, що використовується для посилань на запис як в самій БД, так і за її межами. Бажано робити його якомога менше - все більшість природних ключів рядкові.
Причина друга - багато речей, що виглядають на перший погляд як природні ключі, насправді не є такими. Наприклад, серед людей бувають повні тезки (та ще й народилися в один день). У магазині може бути два товари з одним і тим же назвою в різних відділах.
Причина третя - природний ключ ще і може змінюватися, що так само веде до проблем. Так, для людини природним ключем міг би бути номер паспорта або свідоцтва про народження - але ці документи можуть бути замінені при досягненні певного віку або в разі втрати.
Тому гарним вибором введення сурогатного ключа - це нове поле, яке не має ніякого відношення до предметної області. Зазвичай його тип - автоінкрементне 32х-розрядне ціле, рідше - 64х-розрядний. Ще це може бути UUID.
Як правило, при наявності такого поля немає ніякого сенсу в складових ключах.
Проте, іноді складові ключі бувають корисні. Ось ці випадки:
Таблиці-зв'язки для відносин "багато до багатьох". Зазвичай такі таблиці створюються і управляються бібліотеками ORM самостійно - але іноді доводиться створювати їх окремо. У таких таблицях природним ключем є вся запис цілком - і немає ніяких причин створювати окремий сурогатний ключ.
Деякі дочірні подоб'екти, що не мають сенсу у відриві від батьківського. Якщо ми робимо систему для тестування учнів - то іноді має сенс звертатися до відповіді на питання як до 5му відповіді на 147й питання - а не до 3423му відповіді взагалі. А іноді навпаки.
Використання відносин в БД для додаткової перевірки цілісності. Існує так звана доменно-ключова нормальна форма, в якій будь-які обмеження на дані реалізуються в форматі зовнішніх ключів. У такому випадку іноді має сенс включати додаткові поля в первинний ключ.