Сообщение Re[3]: id integer vs uuid от 22.08.2022 20:15
Изменено 22.08.2022 20:17 fmiracle
Re[3]: id integer vs uuid
Здравствуйте, vsb, Вы писали:
vsb>В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их.
А мне понравилась идея.
Причины тут те же самые, что ты описал выше, только только для справочников у них веса другие
Т.е. выборка типа
select * from orders where status = 2
(где "2" — это "открыт" и аналитик/саппорт это прекрасно помнит уже)
такая может быть куда чаще требоваться в анализе данных, чем выборка по id собственно заказа и полезно что она может быть записана наглядно и быстро. Т.е. "плохая читабельность" для справочников более большая проблема, чем для таблиц данных, а польза от удобной распределенной генерации для них совершенно несущественна. Более того, очень часто эти значения заполняются от руки в скриптах типа начальной инициализации, и в случае чисел ты их проставишь сразу из голоы, в случае с гуидами надо будет еще открывать генератор.
При этом проблемы расхода места и памяти для них вполне актуальны, т.к. поля со значением из справочника в таблице очень даже часто индексируются, а более компактный индекс лучше чем менее компактный.
vsb>В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их.
А мне понравилась идея.
Причины тут те же самые, что ты описал выше, только только для справочников у них веса другие
Т.е. выборка типа
select * from orders where status = 2
(где "2" — это "открыт" и аналитик/саппорт это прекрасно помнит уже)
такая может быть куда чаще требоваться в анализе данных, чем выборка по id собственно заказа и полезно что она может быть записана наглядно и быстро. Т.е. "плохая читабельность" для справочников более большая проблема, чем для таблиц данных, а польза от удобной распределенной генерации для них совершенно несущественна. Более того, очень часто эти значения заполняются от руки в скриптах типа начальной инициализации, и в случае чисел ты их проставишь сразу из голоы, в случае с гуидами надо будет еще открывать генератор.
При этом проблемы расхода места и памяти для них вполне актуальны, т.к. поля со значением из справочника в таблице очень даже часто индексируются, а более компактный индекс лучше чем менее компактный.
Re[3]: id integer vs uuid
Здравствуйте, vsb, Вы писали:
vsb>В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их.
А мне понравилась идея.
Причины тут те же самые, что ты описал выше, только только для справочников у них веса другие
Т.е. выборка типа
select * from orders where statusId = 2 and cityId=678
(где "2" — это "открыт" а город 678 это Питер и аналитик/саппорт это прекрасно помнит уже)
такая может быть куда чаще требоваться в анализе данных, чем выборка по id собственно заказа и полезно что она может быть записана наглядно и быстро. Т.е. "плохая читабельность" для справочников более большая проблема, чем для таблиц данных, а польза от удобной распределенной генерации для них совершенно несущественна.
При этом проблемы расхода места и памяти для них вполне актуальны, т.к. поля со значением из справочника в таблице очень даже часто индексируются, а более компактный индекс лучше чем менее компактный.
vsb>В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их.
А мне понравилась идея.
Причины тут те же самые, что ты описал выше, только только для справочников у них веса другие
Т.е. выборка типа
select * from orders where statusId = 2 and cityId=678
(где "2" — это "открыт" а город 678 это Питер и аналитик/саппорт это прекрасно помнит уже)
такая может быть куда чаще требоваться в анализе данных, чем выборка по id собственно заказа и полезно что она может быть записана наглядно и быстро. Т.е. "плохая читабельность" для справочников более большая проблема, чем для таблиц данных, а польза от удобной распределенной генерации для них совершенно несущественна.
При этом проблемы расхода места и памяти для них вполне актуальны, т.к. поля со значением из справочника в таблице очень даже часто индексируются, а более компактный индекс лучше чем менее компактный.