jonnify·bcs /bcs/elixir-core/property-stores/the-only-key

B2.2.1 · dive 1 of 3 · module B2.2

The branded id is the only key.

One table, one key: the 14-byte branded id. No surrogate, no timestamp column, no secondary index — the key is the identity, and it carries namespace and mint time at once.

The branded id as the sole key, carrying namespace and time; no extra columns. Select a part.
key: USR0KHTOWnGLuCthe 14-byte branded idthe value USR0KHTOWnGLuCbase62(snowflake)namespace + time, in the key surrogate id columntimestamp columnneither exists
readout · Select a part. The table’s only key is the branded id; it carries a 3-byte namespace and a 64-bit snowflake; a surrogate id and a timestamp column are not needed.
§1

The idea

echo_data · property_store.ex, timeline.ex

A property store keeps one ETS table, and that table has exactly one key: the 14-byte branded id. There is no surrogate integer, no separate timestamp column, no secondary index — the key is the identity, and the row is the key and its value, nothing more. EchoData.Timeline states the same shape from the other side: it keys by the raw snowflake with the branded form at the edges, and adds no column the key already carries.

The key is not opaque; it is structured. The first three bytes are the namespace, and the remaining eleven are base62 of a 64-bit snowflake — so the key already carries who-this-is, what-kind, and when-it-was-minted. A store that keys by the branded id is keying by all of that at once, which is why the rows need nothing beside the value.

Codemojex keys every store this way. A player’s record sits under a PLR id, a room’s under a ROM id, a round’s under its own; the store never asks which player with a join against a name table, because the name is the key. Identity is the address, and the address is the whole of the row’s left-hand side.

§4

The doors

the sibling courses
§2

References

sources · related

Sources

Related