|
|
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Подскажите, пожплуйста, стоит ли мне создавать отдельный поле под первичный ключ, если у меня в таблице есть поле, значения которого не будут нулевые и будут уникальные. Насколько я понимаю, первичный ключ - это поле не нулевое и уникальное, которое дополнительно индексируется СУБД (может не всеми по-умолчанию). Если конкретнее, то я говорю про таблицы devicetype, cartridgetype, stock, employee. Например, в качестве первичного ключа для таблицы cartridge я выбрал sn (серийный номер), т.к. эти значения не могут быть нулевыми или дублироваться. Как будет правильнее по теории и на практике. Заранее благодарю! PS. Индексируются ли автоматиччески поля с уникальными значениями в MySQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 05:42 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
OlegrikНапример, в качестве первичного ключа для таблицы cartridge я выбрал sn (серийный номер), т.к. эти значения не могут быть нулевыми или дублироваться. У разных производителей серийные номера могут дублироваться, по крайней мере за обратное никто не утверждал... Они могут гарантировано не повторяться, только если вы сами будете присваивать им свои собственные серийные номера... Но в этом случае это будет все тот же обычный счетчик ключ, так зачем тогда городить огород, если можно пользоваться штатными счетчиками-ключами ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 08:35 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Olegrik, Тема потенциально флеймовая. Суррогатный ключ vs естественный ключ. Решается в зависимости от конкретных бизнес-требований. А так, в общем случае суррогатный ключ универсальнее, хотя не всегда удобнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 09:08 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
OlegrikНапример, в качестве первичного ключа для таблицы cartridge я выбрал sn (серийный номер), т.к. эти значения не могут быть нулевыми или дублироваться. Типичное заблуждение. Для учета ТМЦ используйте суррогатный ключ (счетчик). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 10:34 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Вообще-то назначение первичного ключа - это однозначная идентификация записи. Однако - с обязательным учётом следующих обстоятельств: 1) Значение поля первичного ключа записи должно быть уникально в пределах таблицы в течение всего срока жизни (внимание!!!) таблицы. Именно таблицы, а не записи! То есть удаление записи не "освобождает" значение первичного ключа этой записи для повторного использования. 2) Значение поля первичного ключа записи, кроме собственно уникальной идентификации записи, в первую очередь предназначено для уникальной идентификации записи в операции установления связи с другими таблицами (внешние ключи). То есть типы данных, которые "не очень подходят" для установления связи (скажем, строковые типы... или совсем не подходят - скажем, блобы), точно так же плохо подходят и в качестве первичного ключа. Одним из следствий этого является то, что наличие у поля, являющегося первичным ключом, содержательной компоненты - нежелательно. Попытка "втиснуть" в одно поле двух принципиально различных и способных противоречить друг другу назначений скорее всего приведёт к проблемам - если не сейчас, то в будущем. Когда переделывать придётся гораздо больше, чем если принять правильное решение на этапе проектирования. Чтобы содержательное поле делать первичным ключом, нужно иметь к тому более чем веские основания. Которые встречаются крайне редко, даже я бы сказал - почти никогда. Моя рекомендация - суррогатный ключ. И, если нужно, уникальный констрейнт (индекс) на содержательное поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 12:38 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Если удобно использовать естественный ключ, надо использовать естественный ключ. Правоверных развелось... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 13:21 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Спасибо всем большое! Буду думать о суррогатных и естественных ключах - мой пробел в знаниях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 13:51 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
schiЕсли удобно использовать естественный ключ, надо использовать естественный ключ. В учете ТМЦ не бывает естественных ключей. Для любого атрибута может возникнуть ситуация, когда он не указывается, изменяется или дублируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 14:59 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Alibek B.schiЕсли удобно использовать естественный ключ, надо использовать естественный ключ. В учете ТМЦ не бывает естественных ключей. Для любого атрибута может возникнуть ситуация, когда он не указывается, изменяется или дублируется. Какой ключ использовать - целиком и полностью зависит от задач, а не от советов гуру разного уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 15:32 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
schiКакой ключ использовать - целиком и полностью зависит от задач, а не от советов гуру разного уровня. Разумеется есть люди, которым нравится набивать собственные шишки, а затем их лелеять. Но если таких склонностей нет, то лучше поверить на слово, что в складском учете и в учете ТМЦ естественных ключей не бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 15:43 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Если нет своего совета - нужно хотя бы охаять чужие... schi , если человек не знает, какой ключ ему нужно использовать в его задаче - как он может узнать это без советов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 16:28 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
schiКакой ключ использовать - целиком и полностью зависит от задач, а не от советов гуру разного уровня. Да, это правда. Проблема лишь в том, что не существует задач, где было бы целесообразно использовать естественный ключ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 20:02 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherschiКакой ключ использовать - целиком и полностью зависит от задач, а не от советов гуру разного уровня. Да, это правда. Проблема лишь в том, что не существует задач, где было бы целесообразно использовать естественный ключ. Ну, смотря что считать "естественным ключом". 2 ID в таблице "многие-ко многим" - это что? Определенно не суррогат :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2017, 20:54 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Так и знал, что будет флейм, флуд и содомия! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 07:40 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинНу, смотря что считать "естественным ключом". 2 ID в таблице "многие-ко многим" - это что? Определенно не суррогат :) 2 ID в таблице "многие-ко многим" - да, это никак не суррогат, это совокупность пользовательских данных, несущих прикладной смысл и подлежащих изменению - стало быть, настоящий естественный ключ. И потому здесь в общем случае необходимо третье поле - собственно суррогатный ID. Необходимость его станет очевидной, если представить себе, например, что записи участвуют в репликации, или какой-то системе проколирования "кто и когда это сделал". Можно, конечно, заявить, что и с двумя идами из всего этого можно выкрутиться. Конечно, можно. Но это будут уверки вроде "а у меня в конторе первичный ключ - фамилия, и ничего, все работает уже месяц". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 13:39 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
"По теории", скорее всего, имена столбцов уникальны в БД. Действительно, теория реляционных БД предполагает, что они могут оказаться в одной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 19:05 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
"По теории", скорее всего, суррогатные ключи рассматривать не имеет смысла. Она (теория) как бы применяется на логическом уровне. Теория пытается помочь спроектировать оптимальную схему или показать, что этого сделать нельзя в данном случае и выбрать между альтернативами. После ее применения получится таблицы. А суррогатный ключ - имеет смысл именно для таблицы, а не сам по себе. Тогда как естественный имеет смысл в предметной области. Суррогатные ключи имеют некие преимущества в нынешней так сказать реализации СУБД. Там важно, что их изменение маловероятно, что всего один атрибут в во внешнем ключе. А естественным ключем могут оказаться все колонки таблицы. А если уже есть суррогаты, то лучше для стиля их ставить везде. Одинаковый стиль упрощает сопровождение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 19:37 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
OlegrikЗдравствуйте! Подскажите, пожплуйста, стоит ли мне создавать отдельный поле под первичный ключ, если у меня в таблице есть поле, значения которого не будут нулевые и будут уникальные. Нет, не стоит OlegrikНасколько я понимаю, первичный ключ - это поле не нулевое и уникальное, которое дополнительно индексируется СУБД (может не всеми по-умолчанию). Не обязательно одно поле, может быть и набор полей. OlegrikЕсли конкретнее, то я говорю про таблицы devicetype, cartridgetype, stock, employee. Например, в качестве первичного ключа для таблицы cartridge я выбрал sn (серийный номер), т.к. эти значения не могут быть нулевыми или дублироваться. Как будет правильнее по теории и на практике. Ну, тут ещё надо 200 раз подумать, потому что очень многие поля, "уникальные" с точки зрения предметной области, оказываются неуникальными с точки зрения технической. Примеры, которые уже навязли в зубах -- это ИНН, номер паспорта и подобные вещи. Это тема отдельной беседы, поищи, почитай. OlegrikPS. Индексируются ли автоматиччески поля с уникальными значениями в MySQL? Автоматически -- нет. При создании констрейнтов PRIMARY KEY или UNIQUE -- да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2017, 18:44 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
1) Значение поля первичного ключа записи должно быть уникально в пределах таблицы в течение всего срока жизни (внимание!!!) таблицы. Именно таблицы, а не записи! То есть удаление записи не "освобождает" значение первичного ключа этой записи для повторного использования. Это сильно зависит от предметной области. 2) Значение поля первичного ключа записи, кроме собственно уникальной идентификации записи, в первую очередь предназначено для уникальной идентификации записи в операции установления связи с другими таблицами (внешние ключи). То есть типы данных, которые "не очень подходят" для установления связи (скажем, строковые типы... или совсем не подходят - скажем, блобы), точно так же плохо подходят и в качестве первичного ключа. То, что строки не подходят для PK -- это заблуждение. Тексты/блобы -- да, не подходят, тебя просто пошлют когда будешь создавать. Чтобы содержательное поле делать первичным ключом, нужно иметь к тому более чем веские основания. Которые встречаются крайне редко, даже я бы сказал - почти никогда. Моя рекомендация - суррогатный ключ. И, если нужно, уникальный констрейнт (индекс) на содержательное поле. Да, чаще всего проектировщики закладываются на то, чтобы поля PK (ни одно из) не имели никакого назначения в предметной области задачи. Это в 90% правильно, но иногда могут быть задачи, где это допустимо. Я тоже бы рекомендовал остановиться на суррогатных ключах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2017, 18:48 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Olegrik, не используйте эту концепцию (ключ), и у Вас не будет никаких проблем. Используйте базы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2017, 18:30 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
Работал как-то с оборудованием, серийники которого были уникальны в пределах Глобуса. Руководство решило менять серийники между оборудованием. Ничего такого, просто чтобы не иметь геморроя с бюрократией и простаиванием. Для наружной бухгалтерии ничего не менялось. Но для аналитики и всякого обслуживания объекты должны быть разными. Хорошо, что были суррогатные ключи. Это я к тому, что когда начинается черный учет, естественные ключи перестают быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2017, 00:49 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
AX-ClassЭто я к тому, что когда начинается черный учет, естественные ключи перестают быть. Тут проблема не в виде учёта, а в том, что в предметной области само значение естественного ключа имеет какой-то смысл, т.е. предметной области не всё равно, какое значение используется для идентификации данного конкретного экземпляра сущности. Нормальный же PK по хорошему не должен нести никакой смысловой нагрузки КРОМЕ идентификации экземпляра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2017, 11:29 |
|
||
|
Первичный ключ (выделять отдельное поле или нет?)
|
|||
|---|---|---|---|
|
#18+
OlegrikКак будет правильнее по теории и на практике. По теории правильнее не плодить лишних полей. На практике надёжных естественных ключей не бывает. OlegrikНапример, в качестве первичного ключа для таблицы cartridge я выбрал sn (серийный номер), т.к. эти значения не могут быть нулевыми или дублироваться. Напишите инструкцию для кладовщика "Что делать, если по базе картридж №12345 год назад продан в Магадан, а на самом деле я держу его в руках, и номер точно именно такой, сверен три раза, и клиент хочет купить его прямо сейчас, потому что он единственный остался, а до Магадана не дозвониться". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2017, 02:10 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=11&tid=1540155]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
95ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 178ms |

| 0 / 0 |

На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даете согласие с использованием данных технологий.