|
|
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
Подскажите какой тип данных лучше всего использовать для первичного ключа. В Oracle почти для всех(!) таблиц независимо от кол-ва записей и их прироста я использовал тип Number (38) + Sequience + Trigger Before Insert. Возможно не лучшее решение, но проблем не было. В PostgreSQL можно ли подойти к вопросу так: либо serial, либо bigserial в зависимости от кол-ва записей и их прироста? Если я правильно понял, при использовании типа serial (до 2147483647) автоматом создается sequience с максимальным значением 9223372036854775807, что позволяет потом безболезненно перейти на bigserial. Что можете подсказать из личного опыта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2015, 19:10 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
startupлибо serial, либо bigserial это псевдо типы, которые соответствуют int4 и int8. Соответственно они занимают фиксированное место при хранении. В отличие от ораклового number переменной длины, который занимает, грубо, количество значащих цифр пополам плюс один байт. безболезненность смены типа ключа, на который висят фк, зависит от личного болевого порога. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2015, 19:34 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
полагаю... В отличие от ораклового number переменной длины, который занимает, грубо, количество значащих цифр пополам плюс один байт. Если я правильно понял аналог ораклового number(38) будет тип данных numeric(38). Он тоже переменной длины. Но почему, судя по постам на форуме, для PRIMARY KEY почти все используют 4-батный serial и 8-байтный bigserial? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2015, 17:23 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
startupполагаю... В отличие от ораклового number переменной длины, который занимает, грубо, количество значащих цифр пополам плюс один байт. Если я правильно понял аналог ораклового number(38) будет тип данных numeric(38). Он тоже переменной длины. Но почему, судя по постам на форуме, для PRIMARY KEY почти все используют 4-батный serial и 8-байтный bigserial? потому что numeric(N) на порядок медленее в работе чем int/bigint и занимает куда больше места и не дает никаких преимуществ. а bigserial хватет всегда на всех мыслимые применения. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2015, 17:30 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
startupполагаю... В отличие от ораклового number переменной длины, который занимает, грубо, количество значащих цифр пополам плюс один байт. Если я правильно понял аналог ораклового number(38) будет тип данных numeric(38). Он тоже переменной длины. Но почему, судя по постам на форуме, для PRIMARY KEY почти все используют 4-батный serial и 8-байтный bigserial? да собственно во всех субд - и sql server и всяких дб2 и файерфоксах - почти везде любят PK вида int4 или int8. Так что я бы спросил почему в Оракле такие особеные все???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2015, 17:57 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
А использование UUID для PRIMARY KEY может конкурировать с Serial / Bigserial? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2015, 18:21 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
Ivan DurakТак что я бы спросил почему в Оракле такие особеные все????Что положено Юпитеру, не положено быку. В оракле нет хранимых intов. Но и... издержки по объемам на нумерацию миллиона записей будут поменьше int4, а где значения за миллиарды, там уже сидеть на int4 стремно. Насчет "на порядок медленее" достаточно спорный вопрос, зависящий от низкоуровневой реализации операций сравнения на равенство и копирования (присвоения). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2015, 18:24 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
p2.Ivan DurakТак что я бы спросил почему в Оракле такие особеные все????Что положено Юпитеру, не положено быку. В оракле нет хранимых intов. Но и... издержки по объемам на нумерацию миллиона записей будут поменьше int4, а где значения за миллиарды, там уже сидеть на int4 стремно. Насчет "на порядок медленее" достаточно спорный вопрос, зависящий от низкоуровневой реализации операций сравнения на равенство и копирования (присвоения). Я конкретно про PostgreSQL и скорости сравнения и арифметики для int4 и numeric(N). Никакие низкоуровневые операции не помогут если надо работать со скоростью сравнения integer значений в регистрах передаваемых по значению. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2015, 03:01 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
startupА использование UUID для PRIMARY KEY может конкурировать с Serial / Bigserial? Ни по скорости ни по размеру поля нет. 4 байта (8 байт) для Int4(8) и значения в регистрах процессора передаваемые by value и сложный тип длинной в 16 байт не влезающий в регистры и передаваемый по ссылке. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2015, 03:05 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
startupЧто можете подсказать из личного опыта? Из личного опыта. Если знаешь, что таблица будет справочником с фиксированным количеством значений, то можно serial. В остальных случаях, по моему, лучше использовать bigserial. Пару раз наткнулся на проблемы с serial. Т.к. у PostgreSQL строгая типизация, то придется менять не только тип поля, но и SEQUENCE к нему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2015, 06:24 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
mad_nazgulЕсли знаешь, что таблица будет справочником с фиксированным количеством значений, то можно serial.личный опыт предполагает субъективные плюсы и минусы. для условно статических справочников предпочитаю строковые мнемокоды, так как потом приходится писать запросы с условиями на говорящие значения и работать с сырыми данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2015, 11:10 |
|
||
|
Тип данных для Primary key
|
|||
|---|---|---|---|
|
#18+
p2.mad_nazgulЕсли знаешь, что таблица будет справочником с фиксированным количеством значений, то можно serial.личный опыт предполагает субъективные плюсы и минусы. для условно статических справочников предпочитаю строковые мнемокоды, так как потом приходится писать запросы с условиями на говорящие значения и работать с сырыми данными. Вот здесь можно свести дискуссию к флуду "естественный ключ vs суррогатный ключ". По мне так проще работать с суррогатными ключами на основе числовой последовательности. Если вам удобнее ч/з мнемокоды, то я ничего не имею против. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2015, 12:12 |
|
||
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1997829]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
174ms |
get topic data: |
10ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 500ms |
| 0 / 0 |
