Если нет PK, не понятно, как запись идентифицировать. При delete например

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

Я в целом, если без ПК живете хорошо - ну живите, мешать не буду. Но для меня таблица без ПК как-то нонсенс )))

maytonА точность TIMESTAMP задаётся до 10 знаков после запятой. Как вы понимаете трудно создать процесс который
генерит события дважды за 0.0000000001 s....
Это если Вы поштучно в таблицу добавляете

А пусть у Вас на логе затык, и я хочу лог накапливать в своем буффере и потом в базу кидать одним bulk insert? Если код на Java, C то сгенерить соседние записи лога быстрее, чем например оттикает currentTimeMillis - легко.

А в целом, просто личные привычки. Спорить не буду.

maytonИ не спорь. Просто расскажи что тебе даст второй суррогат ID в данном кейсе.
хотя бы order by

что бы лог читать в том же порядке, в котором я его генерил (принимаем, что поле timestamp может быть не уникальное. Пусть по причине кривых рук разработчика log'а)

Если, же, поле timestamp уникально, то тогда уверять, что в данной таблицы "нет PK" странно )))

maytonТиппичный лог



В многопользовательской системе, хорошо бы как-то по user'ам / или на крайняк процессам-сессиям разделять

А то если два пользователя одновременно работать будет - такая помойка получится )))

Не претендую на истинность в последней инстанции, но у нас на проекте Hiubernate сразу же ID выдавал (вроде через newEntity() создавали).

Правда там все было сложно: Hibernate -> Cobol -> Oracle. В детали реализации старались не лезть, что бы не пугаться.

1. Использовать id. Плохо тем, что до момента вставки в БД id ещё не определён.

AFAIK
Например MS Visual FoxPro при оптимистической блокировке, до момента вставки выдает ROWNUM -1, -2, -3 etc... В момент физического Insert'а ROWNUM становится реальным.

В Oracle Forms мы просто запрашивали очередной ID из сиквенса. Сиквенс большой, его не жалко.

junixar...
maytonА про хибернейты меньше надо читать. Они только портят общее понимание
как работает БД.

Это из разряда - "..., но осуждаю"?

Не имеет значения какой стэк в моём случае используется. Будь то голый JDBC или одна из ряда ORM. К вопросу это не имеет отношения.
Мне кажется тут mayton прав

У Вас получается все скомкано в одну кучу. И объекты, и база. Отсюда и проблемы.

Термин "время жизни объекта" он же тоже не абсолютный, а от контекста зависит. Добавили объект в БД, старый грохнули, новый создали ))) Вот Вам и "по контракту значение hashCode не может изменяться за время жизни объекта" обеспечено.

В данном случае, Вы пытаетесь скрестить ежа (контракты Java рассчитанные на работу с объектами в памяти) с удавом (базой данных, пусть реалиционную, да еще и с поддержкой транзакций). Получаете сто метров колючей проволоки.

IMHO & AFAIK

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

1. Есть бизнес объект реального мира. Марья Ивановна. Она родилась в 1951 году и умрет в 2017 ))) Это ее "время жизни"

Она живет в квартире, иногда ходит на кладбище навестить могилу своей матери. Которая когда то умерла. Но жить на кладбище она категорически отказывается )))

2. Есть электронное представление этого объекта реального мира в виде экземпляра объекта в памяти Java Machine.

3. Есть представление этого же объекта в СУБД с поддержкой транзакций

Если мы говорим о СУБД с поддержкой транзакций, то как минимум, у нас будет 3-и больших "периода времени жизни". У объектов hibernate все по другому, я говорю с точки зрения СУБД

3.1. Данные введены но не переданы в СУБД
3.2. Данные переданы в СУБД но commit не выполнен (команда post)
3.3. Commit выполнен

СУБД, как Вы понимаете, на время жизни экземпляра объекта в памяти JVM и "контракты" глубоко наплевать.

Но и объекты, с точки зрения прикладной системы и бизнес логики, при этих трех состояниях совершенно разные. Как живая Марья Ивановна и ее уже покойная мама. И заставлять жить разные экземпляры Java отображающим объекты СУБД в этих разных состояниях в одном HashMap'е - как заставлять реальную Марью Ивановну жить на кладбище с ее бабушкой.

Иногда (например в интерфейс при вводе новых данных) - приходится. Отображаем и реальную информацию из БД и новую, фейковую, которую оператор только еще вводит с клавиатуры. Но тогда, некий фейковый ключ (в FoxPro -1,-2,-3 etc) вполне может спасти. Ввод закончился. Фейковый объект попал в БД, стал реальным. ВСЕ. Это уже другой объект. Марья Ивановна тоже когда-то 9 месяцев в животе своей матери жила, но к ее паспортным данным сейчас это не имеет никакого значения и никого не интересует.

Лирическое отступление по поводу относительности "времени жизни" и соответственно незыблемости "контрактов на время жизни объекта"

junixarТеперь повторюсь: сущности не имеют явного уникального неизменяемого поля. Ид (первичный ключ) генерируется в момент вставки записи в БД. И это здесь не обсуждается. Это исходные условия.

Вы ошибаетесь!

Сущность Марья Ивановна неизменяемый пол имеет. Нет... конечно... кто сейчас Евровидение выигрывает всем известно... но Марья Ивановна не такая!

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

Только... подозреваю... Вы не об этом )))


Вот. Как-то так. Отделяя вечное - СИСЬКИ. От переходящего - хибернайт и база данных )))