Чому ключ повинен бути явним?

15

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

primary-key unique-constraint

— dsaxton
джерело

Ви маєте на увазі, що якщо у вас є УНІКАЛЬНИЙ ключ, навіщо турбуватись з ПЕРВИЧНИМ?

— Vérace

1

Тільки чому вони взагалі декларуються? Це здається дуже корисним, але чи потрібно насправді мати базу даних, яка функціонує?

— dsaxton

1

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

— Андрій М

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

— Thorbjørn Ravn Andersen

32

Ви, очевидно, пропонуєте, що CONSTRAINTs в базі даних повинен бути застосований додатком (ими), які / які отримують доступ до цієї бази даних?

Є багато причин, чому це погана (погана, погана ...) ідея.

1) Якщо ви будуєте "рулонний" власний "обмежувальний" двигун "(тобто в рамках свого коду програми), ви просто наслідуєте те, на що витратили Oracle / SQL Server / MySQL / PostgreSQL / <. років написання. Їх код CONSTRAINT був перевірений протягом цих років буквально мільйонами кінцевих користувачів.

2) При всій повазі до вас та вашої команди, ви не збираєтеся виправити це навіть за лічені роки - звідси лише MySQL-код коштував 40 мільйонів доларів. І MySQL - найдешевший із трьох вищезгаданих серверів, і вони навіть не реалізують ПРОВЕРКУВАННЯ КОНСТРАНЦІЙ. Очевидно, що отримати правильний RI (Referential Integrity) повністю правильно, важко.

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

Джонатан Льюїс (він написав книгу на 550 сторінках про основи оптимізатора Oracle ) дає як ні. 2 його дизайнерських катастроф в іншій книзі (" Казки про дубовий стіл " - Дубовий стіл - група експертів Oracle) є

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

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

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

Щоб спеціально відповісти на ваше запитання:

Тільки чому вони взагалі декларуються? Це здається дуже корисним, але чи потрібно насправді мати базу даних, яка функціонує

Причина того, що KEYs (або PRIMARY, FOREIGN, UNIQUEабо просто звичайні INDEXадреси) оголошуються в тому , що, в той час як це НЕ є строго необхідним для бази даних , щоб мати їх для його функціонування, це абсолютно необхідно , щоб вони були оголошені для нього функціонувати добре .

— Vérace
джерело

1

Дякую за вашу відповідь. Мені, мабуть, доведеться дізнатися більше, щоб повністю зрозуміти це. (Я насправді не належу до команди, я просто

— довідаюся

2

Прочитайте кілька книг (Дата, Гарсія-Моліна ...) та поверніться до нас, якщо у вас є конкретні запитання (питання, які надто широкі, тут вважаються позатематичними). ps Ласкаво просимо на форум :-)

— Vérace

Хоча я б ніколи, ніколи НЕ припустити , що ви поклали немає обмежень в базі даних (Ви завжди повинні мати первинний ключ і зовнішні ключі, як мінімум), ви могли б уникнути # 3, маючи всі додатки споживають від загального обслуговування (сервіс - орієнтованої архітектури ). (Це, мабуть, щось, що ви повинні врахувати для кількох споживачів, так чи інакше, коли кожна остання перевірка цілісності, яка вам потрібна в базі даних, теж може отримати кошмарний

— вигляд

10

Під час створення ключа в базі даних двигун СУБД виконує обмеження унікальності щодо ключових атрибутів. Це служить щонайменше трьом суміжним цілям:

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

— nvogel
джерело

8

Я додам один аспект до існуючих відмінних відповідей: Документація. Часто важливо дізнатися, які типи ключів можна використовувати для ідентифікації сутності. Будь-яка комбінація унікальних стовпців - це кандидатський ключ.

Первинний ключ, як правило, є особливо корисною концепцією на практиці.

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

— boot4life
джерело

1

Діаграми бази даних! Перше, що я завжди роблю, коли мене просять сказати щось значуще про програмне забезпечення, з яким я не знайомий, - це побачити, чи він використовує реляційну базу даних, і якщо так, спробуйте створити діаграму бази даних. Це дасть мені чудове уявлення про інформацію, з якою працює програма. На жаль, 90% баз даних, які я бачив, не декларують сторонні ключі, тому діаграми - це лише набори таблиць. Виведення неявних закордонних ключів на рівні програми вимагає здогадок та налаштування.

— reinierpost

1

@reinierpost Я повністю згоден. Дані - це найцінніший об'єкт для документування та збереження чистоти, оскільки він зберігається назавжди. Код може змінюватися; воно, як правило, є тимчасовішим.

— boot4life

@reinierpost - Консультувався з компанією, яка постачала програмне забезпечення для всієї залізничної інфраструктури великої європейської країни (великі - думають мільярди віджетів), і я сказав: "Хм, я просто проведу запит, щоб перевірити FOREIGN KEYвизначення, щоб отримати відчуваю за систему ". Мій запит повернув zip !!! Впевнений, що мій SQL, мабуть, помилився, я згадав про це одному з старших програмістів. З гордістю (не менше) він оголосив (ніби він представляє новонародженого сина), що в системі не було жодних ФК, оскільки "всі пошуки ведуться PRIMARY KEY" - (не має значення). <Дох ...> а-ля Гомер Сімпсон!

— Vérace

5

Ще одна причина, чому ви повинні використовувати CONSTRAINT замість коду внутрішньої програми:

Що відбувається, якщо розробник / dba використовує оператор вставлення / оновлення / видалення для зміни даних безпосередньо в БД? У цьому випадку вся ваша приємна орієнтація на основі додатків буде марною. Я знаю, деяким розробникам подобається можливість змінювати дані безпосередньо, не турбуючись з RI, тому що вони знають, що роблять - принаймні найбільше часу (але не завжди)

PS: Звичайно, ви можете створити тригери, але вони зазвичай жахливі повільно (порівняно з КОНСТРЕЙНАТИ).

— Тома Франц
джерело