Чи повинна кожна таблиця мати первинний ключ?

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

Чи повинна кожна таблиця мати первинний ключ?

Коротка відповідь: так .

Довга відповідь:

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

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

Зауважте, що первинний ключ може бути складеним.

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

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

А оскільки будь-який первинний ключ включає створення унікального індексу, вам слід оголосити його і отримати як логічну послідовність, так і продуктивність.

Дивіться цю статтю в моєму блозі, чому завжди слід створювати унікальний індекс унікальних даних:

• Створення індексу УНІКАЛЬНО

PS Є кілька дуже-дуже особливих випадків, коли вам не потрібен первинний ключ.

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

Завжди найкраще мати первинний ключ. Таким чином він відповідає першій нормальній формі і дозволяє продовжувати шлях нормалізації бази даних .

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

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

За винятком кількох дуже рідкісних випадків (можливо, таблиця відносин «багато-багато» або таблиця, яку ви тимчасово використовуєте для масового завантаження величезних обсягів даних), я б сказав:

Якщо він не має первинного ключа, це не таблиця!

Марк

Просто додайте його, ви будете шкодувати пізніше, коли цього не зробили (вибір, видалення. Посилання тощо)

Чи вам коли-небудь потрібно буде приєднати цю таблицю до інших таблиць? Чи потрібен спосіб однозначної ідентифікації запису? Якщо відповідь "так", вам потрібен первинний ключ. Припустимо, ваші дані - це щось на зразок таблиці клієнтів, яка містить імена людей, які є клієнтами. Можливо, немає природного ключа, оскільки вам потрібні адреси, електронні листи, номери телефонів тощо, щоб визначити, чи відрізняється ця Саллі Сміт від тієї Саллі Сміт, і ви будете зберігати цю інформацію у відповідних таблицях, оскільки людина може мати кілька телефонів, доповнень , електронні листи та ін. Припустимо, Салі Сміт виходить заміж за Джона Джонса та стає Саллі Джонсом. Якщо у вас немає штучного ключа на столі, під час оновлення імені ви просто змінили 7 Sally Smiths на Sally Jones, хоча лише одна з них вийшла заміж і змінила її ім'я.

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

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

Це хороша практика мати ПК на кожному столі, але це НЕ ОБОВ'ЯЗКОВО. Швидше за все, вам знадобиться унікальний індекс та / або кластерний індекс (який є ПК або ні) залежно від ваших потреб.

Перегляньте розділи Основні ключі та кластеризовані індекси в Книгах онлайн (для SQL Server)

" ПЕРШИЧНІ КЛЮЧОВІ обмеження ідентифікують стовпчик або набір стовпців, які мають значення, що однозначно ідентифікують рядок у таблиці. Жоден два рядки таблиці не можуть мати однакове значення первинного ключа. Ви не можете ввести NULL для будь-якого стовпця в первинному ключі. Ми рекомендуємо використовувати невеликий цілий стовпець у якості основного ключа. Кожна таблиця повинна мати первинний ключ. Стовпець або комбінація стовпців, які кваліфікуються як значення первинного ключа, згадуються як кандидатський ключ. "

Але перевірте це також: http://www.aisintl.com/case/primary_and_foreign_key.html

Не погоджуйтесь із запропонованою відповіддю. Коротка відповідь: НІ .

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

Хоча є випадки, наприклад, реєстрація даних часових рядів, коли існування такого ключа просто не потрібно і просто займає пам'ять. Зробити рядок унікальним просто ... не потрібно!

Невеликий приклад: Таблиця A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Первинний ключ не потрібен.

Таблиця B: Користувач

Columns: Id, FirstName, LastName etc. 

Первинний ключ (Id), необхідний для використання в якості "зовнішнього ключа" для таблиці LogData.

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

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

Я в ролі підтримки додатків, створених командою з офшорних розробників. Тепер у мене виникають всілякі проблеми в додатку, оскільки оригінальна схема бази даних не містила ПЕРШИХ КЛЮЧІВ у деяких таблицях. Тому, будь ласка, не дозволяйте іншим людям страждати через ваш поганий дизайн. Завжди добре мати первинні ключі на столах.

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

Словом, ні. Однак вам потрібно мати на увазі, що певні операції з клієнтським доступом до CRUD вимагають цього. Для подальшої перевірки я прагну завжди використовувати первинні ключі.

Якщо ви використовуєте Hibernate, неможливо створити об'єкт без первинного ключа. Ці проблеми можуть створити проблему, якщо ви працюєте з існуючою базою даних, створеною за допомогою простого сценарію sql / ddl, і не було додано первинного ключа