Насколько hashcode() уникален?

Насколько такая ситуация возможна практически?

Более чем возможна. hashCode() не должен быть уникальным, он лишь позволяет в некоторых случаях избежать лишней проверки equals для неравенства. Т.е. по нему можно проверять, что объекты не равны, но нельзя утверждать, что они равны.

За отклики благодарен.

Если этот код писал ты, иди и оторви себе руки, если этот код писал другой человек - иди и оторви руки ему.

стоит ли в программе во всяких хешмапах и списках хранить значения из бд

Используй ORM

Понятно. Я вот только сейчас подумал о том, а почему бы мне эти самый id не генерировать средствами СУБД: т.е. создаю инстанс, заливаю его в бд, получаю id, которое ему назначила СУБД и присваиваю его инстансу. Как такой вариант? Можно прикрутить триггер какой-нибудь, возвращающий id последнего эл-та при INSERT, и получать его как результат запроса-вставки.

Думаю, хотя хранить все это достаточно ресурсоемко, но все равно оптимальнее, чем каждый раз обращаться к бд. Или как-то комбинировать?

запусти профайлер да скажи нам :) сколько программ, столько и вариантов

вон PHPшники вообще не могут ничего в памяти кэшировать, и живут же как-то

Если этот код писал ты, иди и оторви себе руки, если этот код писал другой человек - иди и оторви руки ему.

зачем? Руки — всего лишь исполнитель.

Используй ORM

за это спасибо, почитаю.

? Можно прикрутить триггер какой-нибудь, возвращающий id последнего эл-та при INSERT

присвятой Иесус, что у тебя за язык?

жаба искаропки умеет возвращать генерированные ключи http://stackoverflow.com/questions/1915166/how-to-get-the-insert-id-in-jdbc

скала/анорм вообще сразу id выплевывает

а если у тебя postgresql, то там сам бог велел - брать id из секвенции

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

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

Насколько hashcode() уникален?

Если его генерять на основе int поля (id), видимо будет полностью уникален.

По дефолту hashcode() просто генерится с помощью PRNG.
Если ты оверрайднул метод (вместе с equals), то уникальность уже зависит от тебя. Но самому лучше не делать - проще через встроенные стредства IDE.
Но, даже в таком случае могут быть коллизии.

В твоем случае самый простой вариант - использовать, например, hibernate + auto-increment / sequence в БД.

вон PHPшники вообще не могут ничего в памяти кэшировать, и живут же как-то

Кто сказал Memcached?

как ты в memcached объекты языка сохранишь?

как ты в memcached объекты языка сохранишь?

Сериализация, не? Хотя бы она в похапе должна же быть

Она и есть. Единственное - нельзя сериализовать всякие streams - объекты подключения к бд, etc.

http://www.php.net/manual/ru/memcache.set.php
var
The variable to store. Strings and integers are stored as is, other types are stored serialized.

Сериализация тормозит (даже бинарная в шаредмемори), общение с memcached тормозит => всё тормозит. Нет в PHP возможности кэшировать объекты языка, только хранить во внешней базе.

отсюда и фраза «вон PHPшники вообще не могут ничего в памяти кэшировать, и живут же как-то»

плохо живут, конечно, но живут...

да ты поехавший, в нормальных языках (не PHP) не нужно ничего сериализовывать, как создал объект в памяти - так он и висит, пока его никто не убьет. Чувствуешь разницу между сохранением референса на объект (1 лонг) который уже есть и достаточно не потерять, не требующая процессора, и длительной серилаизацией, а потом и десериализацией, хрен пойми чего хрен пойми как?

Так язык сам сериализует-десериализует. Ты прочитай,

objects are _stored_ serialized.

как создал объект в памяти - так он и висит, пока его никто не убьет.

Ну так логично. http://software-gunslinger.tumblr.com/post/47131406821/php-is-meant-to-die почитай. Вроде на швабре даже перевод был.

Разницу я чувствую, но пых пока устраивает абсолютно во всем (за исключением костыльной многопоточности).