long id

[juan_gandhi]

I think I got it where all this bs about passing around numerical ids of entities instead of entity references (maybe lazy) come from. It's like 'error code'. It comes from the ancient c programming, where we just could not allocate a string for a readable piece of text, or for the data that may need some efforts to instantiate or allocate.

In short. It's stupid to pass around "ids" in a program.

Comments

[rssh.livejournal.com]

Hmm, is not 'persistent reference <=> id' ?

[dennisgorelik]

> It's stupid to pass around "ids" in a program

What if you are passing "ids" to database (to retrieve full records)?
Is it still stupid?

[vit-r.livejournal.com]

Когда количество перерастает в качество и таблица перестаёт помещаться в памяти сервера, начинаются интересные вещи.

Потом ещё великолепны будут способы вычисления уникальности.

[rezkiy.livejournal.com]

< rant>

so what do you do if you actually DO fail to allocate? you pass an exception through whatever means. Let's now talk about how your cyclomatic complexity affects your ability to reason about correctness of your program.

If you never learnt to code in imperative programming languages (such as C/C++), it doesn't exactly mean that those that did learn are stupid or something.

< /rant>

[no more turtles (from livejournal.com)]

Имеет ли эта мудрость отношение к тому, что юниксовский сервер под полным лоадом с аптаймами больше года это в порядке вещей, а жабовский сервер без особой загрузки мне приходится бегать и перегружать каждую неделю, потому что OOM exception и вся машина висит как зомби (да, вся, жаба неубиваема!), хотя и на пинг реагирует.

[cema.livejournal.com]

Yes, it's dome more C legacy. But we do need a handle, just a better abstraction than a number.

[soonts.livejournal.com]

>passing around numerical ids of entities instead of entity references
Numerical ids are much better.

>It's like 'error code'.
No it’s not.

You can store them in a CPU register.
You can save them using only 8 bytes of storage.
You can compare them with a single cmp CPU instruction.
You can design your system so the IDs are unique even if your system will scale out to thousands of servers.

[yatur.livejournal.com]

I think C programming has nothing (or little) to do with it. Access to (relational) databases via lazy objects references is very harmful to performance.

Databases are designed to get mass quantities of records in one shot. E.g. retrieving 10,000 records via some simple query (SELECT * FROM Users WHERE OrganizationId=125) is virtually instantaneous. Lazy entity references are designed to get one object at a time. Retrieving 10,000 records via 10,000 queries (SELECT * FROM Users WHERE UserId=n x10,000 times) will take forever.

ORMs like Hibernate do provide lazy references, and make things look easy on toy databases. However, this ease is deceiving. Later on you find yourself rewriting half of the program getting rid of the lazy references, because it just does not work fast enough in production.

[microcell.livejournal.com]

You actually never pass real string to the function. Instead what is happening, you are creating new string object in a heap and pass its pointer to the function through the stack. So in a way there is no much difference, but will be less work for a garbage collector.

If all your strings are static and already loaded in some array, the ID will save you trouble to load them each time. Or, if you have some resource provider, like Android does, it will let you to have multi-language support with no cost at all.

[sorhed.livejournal.com]

Разумеется, это самоочевидная истина. У явных id есть очень немного разумных применений, одно из них такое: звонит, допустим, клиент в саппорт и спрашивает, а что у меня ордер выполнился на два пункта дороже чем надо? А ему в ответ: ща посмотрим, а скажите-ка ID?

(из чего следует, что id для этих целей должен быть красивым и человекочитаемым, например, 137-234-987-202. И вообще генерироваться отдельно, не совпадать с внутренним id, который, как правило, UUIDv4, коих should be enough for everyone).

Ну и ещё из джаваскрипта в скалу приходится id явно гонять, референс же полностью не воссоздать. А так, внутри скального кода, конечно, никаких явных id, кашрут не велит.

id vs pointer

[a r (from livejournal.com)]

1. Id itself is immutable
2. It does not have to live on the same cpu.
3. And there are no life time issues - stale ids are trivially detected.

[109.livejournal.com]

с содроганием прочитал этот тред. особенно про преимущества int перед long.

> In short. It's stupid to pass around "ids" in a program.

не очень осмотрительно представлять свой очень специфический use case как "всегда" и "везде". это очевидный bias, но надо же себя заставлять.

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

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