|
|
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Собственно вопрос: какого размера ключ - "слишком большой"? Имеется в виду в основном суммарный размер составного ПК. Хочу знать на какой размер можно рассчитывать для баз, спроектированных вменяемыми людьми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 16:03 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovсоставного ПК О какой вменяемости в общем случае может идти речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 16:10 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov wrote: > Собственно вопрос: какого размера ключ - "слишком большой"? Имеется в > виду в основном суммарный размер составного ПК. В общем случае, наверное, более 5 полей или более 512 байт по своей суммарной длине. В частных случаях могут быть отклонения как в ту, так и в другую сторону. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 16:44 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Я бы сказал что ДВА (второе поле для распределенной системы) поля - максимум для первичного ключа (большее количество необходимо обосновывать). Остальное лучше обозвать альтернативным ключом и для ссылочной целостности не использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 17:48 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovСобственно вопрос: какого размера ключ - "слишком большой"? Имеется в виду в основном суммарный размер составного ПК.Чем меньше, тем лучше, особенно, если он может мигрировать далее. Желательно фиксированного типа, еще лучше - целочисленного. P.S. Как-то видел очень печальные последствия применения для master-таблицы в качестве PK varchar-строки размером 40-50 байт на Informix. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 17:57 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovХочу знать на какой размер можно рассчитывать для баз, спроектированных вменяемыми людьми. Я работал с базой, где первичный ключ некоторых таблиц насчитывал двенадцать полей, в среднем было пять-шесть. "Спроектированных вменяемыми людьми" я совершенно не почувствовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 22:40 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
больше одного уже тяжело, человек явно не может определиться с сущностями. 12... хм.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 23:51 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Разовьем тему. Интересуют распределенные базы. Видится три варианта реализации первичного ключа в этом случае: 1. UUID. Плюс: поле атомарно и как утверждается риск неуникальности ничтожен. Минус - поле большое, не все СУБД его поддерживают. Сам ключ не говорит о месте (базе) создания данных. 2. Держать пару полей (код базы создания объекта, уникальный код в этой базе), во внешних ключах также пара данных. Плюс - можно однозначно идентифицировать какая база породила эту запись. Минус - внешние ключи достаточно большие. Работа с неатомарными значениями. 3. Первичный ключ - одно поле уникальное в базе. Кроме того существует еще уникальная пара полей (как в варианте 2), не входящих в базу, но являющихся синхронизаторами между базами. Первичный ключ не мигрирует между базами. Плюс - первичный и внешние ключи атомарны. Минус - дополнительные 2 поля (уникальный индекс), единственная нагрузка которых обеспечить синхронизацию данных. Прошу обсудить каждый из подходов, возможно, у вас есть решение и получше. С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 09:32 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Не думаю, что Дмитрий имел в виду именно эту тему, и не понимаю, зачем городить сложности, когда существует общеупотребимое, простое и правильное решение: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 10:27 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
softwarerНе думаю, что Дмитрий имел в виду именно эту тему, и не понимаю, зачем городить сложности, когда существует общеупотребимое, простое и правильное решение: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 10:45 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Nafгде оно существует? и как эти средством пользоваться? Oracle, PostgreSQL, Sybase ASA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 11:20 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
sn1251, в целом понятно, ну а если баз стало больше 1000? в действующем проекте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 11:36 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНNaf, UUID и UUID-OSSP ваше всё. Что-то подобное есть в любой СУБД.неплохой вариант, но нет информации о базе-создателе, придется еще одно поле вносить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 12:12 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Nafв целом понятно, ну а если баз стало больше 1000? (пожимая плечами) Никто не мешает increment by 1000000. Я не встречал проекта, где нельзя было бы сразу оценить "заведомо недостижимую" цифру количества. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 12:17 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
softwarerNafв целом понятно, ну а если баз стало больше 1000? (пожимая плечами) Никто не мешает increment by 1000000. Я не встречал проекта, где нельзя было бы сразу оценить "заведомо недостижимую" цифру количества.в общем тоже неплохая идея, как и все со своими плюс/минусами разумеется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 12:26 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
softwarerНе думаю, что Дмитрий имел в виду именно эту тему Ну, вообще-то примерно эту тему я и имел ввиду, поскольку распределённые БД - моя работа. Но перечисленные варианты слишком простые. GUID это всего лишь 16 байт в двоичном представлении и 32 в текстовом. Два нумерика - ещё проще. Про распределение по диапазонам я вообще молчу. Максимум, что я видел в клиентских базах это 3-4 поля суммарной длиной 40-50 в символьном представлении. Но теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Жар-птичка - до 4096. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 14:02 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovsoftwarerНе думаю, что Дмитрий имел в виду именно эту тему Ну, вообще-то примерно эту тему я и имел ввиду, поскольку распределённые БД - моя работа. Но перечисленные варианты слишком простые. GUID это всего лишь 16 байт в двоичном представлении и 32 в текстовом. Два нумерика - ещё проще. Про распределение по диапазонам я вообще молчу. Максимум, что я видел в клиентских базах это 3-4 поля суммарной длиной 40-50 в символьном представлении. Но теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Жар-птичка - до 4096.а что не так с размером? не хватает? 0_о а с распределением? а вам не все равно? это же суррогат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 14:09 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Nafа что не так с размером? не хватает? 0_о Наоборот - лишко. У меня в таблице протокола есть поле (даже два), в которые записываются значения ключей. Если эти поля слишком большие - падает производительность. Слишком маленькие - ...., ну, всем ясно. Вот, ищу баланс с помощью народного мнения. Настройку в руки пользователя я, конечно, дам, но нужно осмысленное значение по умолчанию для тех, кто не заморачивается чтением документации и ковырянием настроек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 14:35 |
|
||
|
Безумно большой первичный ключ
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovНу, вообще-то примерно эту тему я и имел ввиду, Вы говорите про размер. А Naf - про архитектурные вариации, которые, исключая UUID, с размером связаны крайне мало. Dimitry SibiryakovНо теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Cомнительная цифра. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. Я так полагаю, максимальный размер ключа в Oracle определяется размером блока индекса для этого ключа. У меня 8К-блоки, соответственно ключ может быть up to 6Кб с небольшим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 21:59 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36326428&tid=1542970]: |
0ms |
get settings: |
6ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 462ms |

| 0 / 0 |
