Почему бы не использовать время создания записи в качестве первичного ключа?

Question

У меня есть таблица с автоинкрементным полем PK и creation_date, которая является меткой времени Unix.
Мне интересно, почему бы не потерять автоинкрементное поле и использовать поле даты создания в качестве PK, поскольку оно уникально (я использую 1/1000 секунды с точностью).

Для: я убиваю проиндексированную строку.
Против: есть небольшая (очень очень небольшая) вероятность дублирования, но с этим очень редким событием легко справиться.

БД mysql.

Answer 1

Общий ответ заключается в том, что ваши данные могут измениться (где бессмысленный идентификатор никогда не изменится) ... что произойдет, когда вы поймете, что вы храните время в локальной зоне и начинается DST? Если вы хотите хранить против UTC и / или против определенного часового пояса? Для получения дополнительной информации о порядке заказа см. ответ wcoenen .

.

Если вы начинаете создавать тысячи строк в секунду, и вам приходится связываться с данными, чтобы «заставить их работать», делая то, для чего они не были предназначены. Возможно, вы бы добавили столбец устранения неоднозначности, который увеличил бы и замедлил бы ваш индекс ...

А потом, когда ваш проект становится мега-популярным, и люди начинают пытаться запускать отчеты / запросы и "он использует дату в качестве ПК ??? !!!"

Также рассмотрите возможность использования базы данных, которая разрешает кластеризованные индексы для неосновных столбцов.

Answer 2

Плохая идея, из-за «часовых поясов».

Если страна, в которой размещены ваши серверы, наблюдает за изменениями времени, связанными с планами «Переход на летнее время», то раз в год время будет сбрасываться на час.

Затем в течение часа он сгенерирует дубликаты ключей.

Я работал в компании, у которой была база данных с таким ключом временной метки, записывающая тысячи измерений в час с оборудования на заводе по производству полупроводников. Он был разработан в Корее (без перехода на летнее время).

Когда они установили его здесь, в США ... нам приходилось закрывать весь завод каждый год на час, чтобы не потерять измерения, сделанные в течение этого часа. : -)

Answer 3

Из-за размера (ширины) индекса. Метки времени широкие; если ваша таблица не содержит кучу строк, вам не нужен bigint как тип данных PK. Чем тоньше столбец первичного ключа, тем больше размер фрагмента индекса, который вы можете сразу сохранить в памяти, и тем быстрее ваши запросы. Так что не делай этого.

Answer 4

Обычно ПК или серверы синхронизируют свои часы с сервером времени . Из-за этого вы не можете полагаться на то, что системные часы сохраняют устойчивый шаг вперед. В любой момент он может слегка подпрыгнуть назад или вперед.

Поэтому, если вам нужно будет восстановить порядок, в котором были созданы ваши записи, вам потребуется ПК с автоматическим увеличением. Вы не можете полагаться на метки времени. Это может звучать очень теоретически, но это уже укусило нас.

Answer 5

Что бы вы получили от не с автоматическим увеличением PK?

Answer 6

Время недостаточно точное, вы можете столкнуться с ошибками вставки, если две записи вставлены одновременно.

Answer 7

Из-за:

Против: существует небольшая (очень очень небольшая) вероятность дублирования, но с этим очень редким событием легко справиться.

У вас нет гарантии, что ваш ключ всегда будет уникальным, поэтому информация не подходит для первичного ключа.

Что если вам нужно вставить 10 или 100 записей в пакетном режиме? Будете ли вы вставлять паузы между вставками, чтобы убедиться, что у вас есть уникальный первичный ключ?

Answer 8

Основной ответ - не масштабируется. Это может сработать сейчас, но по мере того, как компьютеры становятся быстрее, и вы получаете больше пользователей, рано или поздно это начнет конфликтовать и ограничивать пропускную способность вашей системы.

Тогда есть много основных технических причин, как указывали другие.

Answer 9

Для: я убиваю проиндексированную строку.

Против: ... в пользу другой индексированной строки, которая из-за ее значительно большей длины приведет к значительным дополнительным издержкам, если будет использоваться гораздо чаще, чем раньше.