ORDER BY id или date_created, чтобы показать последние результаты? - PullRequest
4 голосов
/ 06 апреля 2011

У меня есть таблица (на самом деле несколько), из которой я хочу получить результаты с самыми последними записями.Вот мои ORDER BY параметры предложения:

  • date_created INT (никогда не изменяет значение)
  • id (конечно, INT AUTO_INCREMENT!)

Оба столбцадолжен в равной степени представлять порядок, в котором записи были вставлены.Я, естественно, использовал бы поле date_created, как любой здравомыслящий человек, но мне все еще любопытно по этому поводу.

Я знаю, что это, вероятно, расщепление волос, но есть ли причина или крайний случай, почему я не должен НЕиспользовать столбец id?

РЕДАКТИРОВАТЬ: Я думаю, что этот вопрос неясен относительно того, какое значение мы хотим действительно представить порядок вставки.Всем спасибо за все ваши ответы, я собираюсь принять лучший и двигаться дальше, потому что я думаю, что затруднил это, предполагая, что идентификаторы всегда будут в порядке (см. Комментарий @ Wrikken).Мой инстинкт инстинкта заключается в том, что идентификатор никогда не должен учитываться разработчиком, на что указывает большинство ответов здесь.

Ответы [ 5 ]

4 голосов
/ 06 апреля 2011

Не стоит полагаться на столбец ID для упорядочения времени, потому что это не его цель. По сути, идентификатор - это просто уникальный ключ для этой строки, не более того. Использование идентификатора может никогда не вызывать проблем, но нет никаких причин добавлять сложность, предполагая, что упорядочение по идентификатору всегда будет выполняться. Например, вы можете в будущем захотеть удалить записи, а затем вручную вставить новые записи или импортировать записи из какого-либо другого источника, которые имеют временную метку в прошлом. Если у вас нет столбца date_created, тогда ID будет вашим единственным вариантом, но, поскольку у вас есть столбец, используйте его, так как это ваш лучший выбор.

2 голосов
/ 06 апреля 2011

Одна хорошая причина, как правило, - потому что вы (или кто-то, кто наследует ваше приложение) могут задним числом вставить запись со старой меткой времени (то есть явно установить метку времени в прошлом, а не в текущем). Вы не всегда можете полагаться на сортировку идентификаторов, соответствующую сортировке по меткам времени.

2 голосов
/ 06 апреля 2011

Как правило, вы не должны полагаться на идентификаторы, если у вас уже есть поле, посвященное времени создания.Возможно, в случае коллизии (записи, созданные в один и тот же момент) вы можете использовать ID в качестве предложения вторичного заказа.

1 голос
/ 06 апреля 2011

Предполагая, что date_created никогда не будет затронут (вы заявили, что это не так). Я думаю, что сортировка по столбцу ID будет лучше с точки зрения производительности.Предположительно столбец идентификатора - это ваш ключ и, следовательно, уже проиндексирован.Нет причин не использовать его для сортировки.Я знаю, что было заявлено, что вы всегда должны использовать дату для заказа, но, честно говоря, в этом случае я бы использовал ID.

0 голосов
/ 06 апреля 2011

Допустим, вы исчерпали положительные целые числа в идентификаторе и изменили свое автоинкремент на использование отрицательных целых чисел.Ваш заказ по идентификатору не будет возвращать самые последние записи в первую очередь.

Эй, вы просили крайний случай!; -)

...