Сообщение Re[3]: Ключи в базе - гуиды, 80 символов и прочая чухня от 27.11.2021 12:08
Изменено 27.11.2021 12:10 vsb
Re[3]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.
PD>Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
PD>А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.
Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.
Вопрос не в сравнении, а во всём остальном. Хранение индексов для первичного ключа, хранение индексов для foreign key. Это всё раздувает оперативную память, вытесняет кеши и тд.
PD>В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.
Ну я постгресом в основном пользуюсь. В нём есть встроенный тип uuid, с которым работаешь, как со строкой, а он преобразовывает всё как надо.
vsb>>80 маловато, я для себя 120 стандартом держу.
PD>Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?
Да как-то сейчас по-другому код пишут. На C всё кратко пишут. mkdir. А на Java — Files.createDirectory. Хочешь-не хочешь, а оно раздувает строки, а сокращать как-то странно уже кажется.
Хотя я видел код, написанный в таком вертикальном стиле. Практически каждая функция писалась в виде
```
someFunc(
arg1,
arg2
)
```
вот он в 80 символов влезал. Но зато по вертикали раздувался — дай боже. Там, где у меня будет 15 строк, влезающих на полэкрана, тут будет 60 на 2 экрана. Мне не понравилось.
vsb>>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.
PD>Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
PD>А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.
Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.
Вопрос не в сравнении, а во всём остальном. Хранение индексов для первичного ключа, хранение индексов для foreign key. Это всё раздувает оперативную память, вытесняет кеши и тд.
PD>В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.
Ну я постгресом в основном пользуюсь. В нём есть встроенный тип uuid, с которым работаешь, как со строкой, а он преобразовывает всё как надо.
vsb>>80 маловато, я для себя 120 стандартом держу.
PD>Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?
Да как-то сейчас по-другому код пишут. На C всё кратко пишут. mkdir. А на Java — Files.createDirectory. Хочешь-не хочешь, а оно раздувает строки, а сокращать как-то странно уже кажется.
Хотя я видел код, написанный в таком вертикальном стиле. Практически каждая функция писалась в виде
```
someFunc(
arg1,
arg2
)
```
вот он в 80 символов влезал. Но зато по вертикали раздувался — дай боже. Там, где у меня будет 15 строк, влезающих на полэкрана, тут будет 60 на 2 экрана. Мне не понравилось.
Re[3]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.
PD>Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
PD>А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.
Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.
Вопрос не в сравнении, а во всём остальном. Хранение индексов для первичного ключа, хранение индексов для foreign key. Это всё раздувает оперативную память, вытесняет кеши и тд.
PD>В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.
Ну я постгресом в основном пользуюсь. В нём есть встроенный тип uuid, с которым работаешь, как со строкой, а он преобразовывает всё как надо.
vsb>>80 маловато, я для себя 120 стандартом держу.
PD>Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?
Да как-то сейчас по-другому код пишут. На C всё кратко пишут. mkdir. А на Java — Files.createDirectory. Хочешь-не хочешь, а оно раздувает строки, а сокращать как-то странно уже кажется.
Хотя я видел код, написанный в таком вертикальном стиле. Практически каждая функция писалась в виде
вот он в 80 символов влезал. Но зато по вертикали раздувался — дай боже. Там, где у меня будет 15 строк, влезающих на полэкрана, тут будет 60 на 2 экрана. Мне не понравилось.
vsb>>Недавно проектировал новый сервис, думал над этим вопросом. Всё же решил остаться на числовых id. Как ни крути, а компактность решает. GUID-ы будут замедлять все аспекты СУБД.
PD>Вот это мне, кстати, не совсем понятно. Если я правильно понимаю, GUID обычно хранится как текстовая строка. Сравнивать числа, представленные в виде текстовой строки, на <> не очень удобно и не быстро.
PD>А между тем это 128 битное целое. И сравнение 128-битных целых на <> в 64-битном коде ничем не отличается от сравнения 64-битных целых в 32-битном коде, а это еще в прошлом веке вполне умели, и ненамного это медленнее было сравнения 32-битных целых.
Конечно GUID-ы хранятся как 128-битные числа или как 16-байтовые массивы, хранить их в виде строк это уже совсем за гранью добра и зла.
Вопрос не в сравнении, а во всём остальном. Хранение индексов для первичного ключа, хранение индексов для foreign key. Это всё раздувает оперативную память, вытесняет кеши и тд.
PD>В MS SQL вроде есть тип guid, и представляют в виде 16-байтного массива. В MySQL не видел ничего подобного.
Ну я постгресом в основном пользуюсь. В нём есть встроенный тип uuid, с которым работаешь, как со строкой, а он преобразовывает всё как надо.
vsb>>80 маловато, я для себя 120 стандартом держу.
PD>Нарушаешь обратную совместимость. А если придется обратно на перфокарты переходить ?
Да как-то сейчас по-другому код пишут. На C всё кратко пишут. mkdir. А на Java — Files.createDirectory. Хочешь-не хочешь, а оно раздувает строки, а сокращать как-то странно уже кажется.
Хотя я видел код, написанный в таком вертикальном стиле. Практически каждая функция писалась в виде
someFunc(
arg1,
arg2
)вот он в 80 символов влезал. Но зато по вертикали раздувался — дай боже. Там, где у меня будет 15 строк, влезающих на полэкрана, тут будет 60 на 2 экрана. Мне не понравилось.