Можно положиться на первичный ключ автопостепенного увеличения в Вашей базе данных?

Я считаю, что ответ на ваш вопрос - да ... если я читаю между строк, я думаю, вы обеспокоены тем, что система может повторно использовать номера идентификаторов, которые «отсутствуют» в последовательность, и поэтому, если вы использовали 1,2,3,5,6,7 в качестве идентификационных номеров, во всех реализациях, о которых я знаю, следующий идентификационный номер всегда будет 8 (или, возможно, выше), но я не знаю о любой БД, которая попыталась бы выяснить, что идентификатор записи №4 отсутствует, поэтому попытайтесь повторно использовать этот идентификатор.

Хотя я больше всего знаком с SQL Server, я не знаю, почему любой поставщик, который пытается и заполните пробелы в последовательности - подумайте о накладных расходах, связанных с хранением этого списка неиспользованных идентификаторов, в отличие от постоянного отслеживания последнего использованного номера I и добавления 1.

I 'd скажем, вы можете спокойно полагаться на то, что следующий присвоенный ID номер всегда будет выше последнего, а не просто уникальным.

Да, идентификатор будет уникальным, и нет, вы не можете и не должны полагаться на него при сортировке - он нужен только для гарантии уникальности строки. Как указал emktas, наилучшим подходом является использование отдельного поля «обновлено» или «создано» только для этой информации.

Для установки времени создания вы можете просто использовать значение по умолчанию, подобное этому

CREATE TABLE foo (
  id INTEGER UNSIGNED AUTO_INCREMENT NOT NULL;
  created TIMESTAMP NOT NULL DEFAULT NOW();
  updated TIMESTAMP;
  PRIMARY KEY(id);
) engine=InnoDB; ## whatever :P

Теперь, что заботится о времени создания. со временем обновления я бы предложил триггер AFTER UPDATE, подобный этому (конечно, вы можете сделать это в отдельном запросе, но триггер, на мой взгляд, является лучшим решением - более прозрачным):

DELIMITER $$
CREATE TRIGGER foo_a_upd AFTER UPDATE ON foo
FOR EACH ROW BEGIN
  SET NEW.updated = NOW();
END;
$$
DELIMITER ;

И это должно сработать .

РЕДАКТИРОВАТЬ: Горе мне. По глупости я не указал, что это для mysql, могут быть некоторые различия в именах функций (а именно, «СЕЙЧАС») и другие тонкие мелочи.

Сгенерированные идентификационные номера будут уникальными. Независимо от того, используете ли вы Последовательности, как в PostgreSQL и Oracle, или используете ли вы другой механизм, такой как автоинкремент MySQL.

Однако последовательности чаще всего собираются группами, например, по 20 чисел. Таким образом, с PostgreSQL вы не можете определить, какое поле было вставлено первым. Могут быть даже пробелы в идентификаторах вставленных записей.

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

Создание created [ Поле 1129611] или обновлено во время выполнения команды намного лучше для сортировки по времени создания или обновления позже. Например:

INSERT INTO A (data, created) VALUES (smething, DATE())
UPDATE A SET data=something, updated=DATE()