8000 Add a reference · symfony/symfony-docs@28eceb8 · GitHub
[go: up one dir, main page]

Skip to content

Commit 28eceb8

Browse files
committed
Add a reference
1 parent 63e4578 commit 28eceb8

File tree

1 file changed

+6
-4
lines changed

1 file changed

+6
-4
lines changed

components/uid.rst

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -113,6 +113,8 @@ sortable (like :ref:`ULIDs <ulid>`). It's more efficient for database indexing
113113
It's recommended to use UUIDv7 instead of UUIDv6 because it provides
114114
better entropy.
115115

116+
.. _uid-uuid-v7:
117+
116118
**UUID v7** (UNIX timestamp)
117119

118120
Generates time-ordered UUIDs based on a high-resolution Unix Epoch timestamp
@@ -347,10 +349,10 @@ entity primary keys::
347349
.. caution::
348350

349351
Using UUIDs as primary keys is usually not recommended for performance reasons:
350-
indexes are slower and take more space (because UUIDs in binary format take 128 bits
351-
instead of 32/64 bits for auto-incremental integers) and the non-sequential nature of
352-
UUIDs fragments indexes. UUID v7 is the only variant that solves the fragmentation
353-
issue (but the index size issue remains).
352+
indexes are slower and take more space (because UUIDs in binary format take
353+
128 bits instead of 32/64 bits for auto-incremental integers) and the non-sequential
354+
nature of UUIDs fragments indexes. :ref:`UUID v7 <uid-uuid-v7>` is the only
355+
variant that solves the fragmentation issue (but the index size issue remains).
354356

355357
When using built-in Doctrine repository methods (e.g. ``findOneBy()``), Doctrine
356358
knows how to convert these UUID types to build the SQL query

0 commit comments

Comments
 (0)
0