|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Использую в качестве первичных ключей GUID'ы (+ в репликации данных). Стоит вопрос хранить его в явном виде в виде массива более 30 символов или же в кодированном (с помощью стандартной ф-ции) 16 символов. В явном виде было бы однозначно удобнее для отладки, но размер большой >30, в неявном минус не удобство в отладке, но размер как минимум в 2 раза меньше. Скажите, пожалуйста, влияет ли длина первичного ключа (если да то как сильно) на скорость работы (выборка, обновления, удаления и т.п.) с базой данных? P.S. FB 2.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:12 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Ты integer, double, date тоже в строках хранишь? отлаживать ить удобнее. Если у тебя все в строках, то ГУИДы храни в строках, что уж единообразие рушить. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:15 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Ivan_PisarevskyТы integer, double, date тоже в строках хранишь? отлаживать ить удобнее. Если у тебя все в строках, то ГУИДы храни в строках, что уж единообразие рушить. GUID не строка - а массив байтов ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:21 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Если уж на то пошло - GUID может быть только уникальным реквизитом справочников (для репликации). А ключи - просто целыми числами. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:26 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
olegentyЕсли уж на то пошло - GUID может быть только уникальным реквизитом справочников (для репликации). А ключи - просто целыми числами. Первичным ключом может быть что угодно (главное чтобы был уникален) И все же влияет ли длина первичного ключа на скорость работы БД, если да, то как сильно? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:31 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Да, влияет. На больших объемах данных. На маленьких - не заметишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:35 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
olegentyДа, влияет. На больших объемах данных. На маленьких - не заметишь. на больших это сколько - если таблицы милионники и их больше 100, или разницу заметишь на более скромных объемах? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:38 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
alexey.barkalovна больших это сколько - если таблицы милионники и их больше 100, или разницу заметишь на более скромных объемах? Тоже интересует этот вопрос ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:40 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Проще всего ответить на твой вопрос, сваяв две базы с разными ключами, наполнив их тестовыми данными (в объемах, близких к боевым) и проведя тестовые запросы. Считать больше данных с диска всегда медленнее, чем считать меньше данных с диска. Больший размер ключа - это больше данных. Разница будет видна только в конкретных условиях. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:43 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
DelphiLexxGUID не строка - а массив байтов Курица не птица, прапорщик не офицер и далее по тексту? строка с чарактер сет октетс в аккурат и подходит для хранения массива байтов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:55 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
еще - объемы ПК с GUID на диске будут гораздо больше, чем обычное число. Т.к. "инкрементный ПК" хорошо упаковывается, а нынешние GUID-ы не упаковываются. я как-то писал статью http://www.ibase.ru/devinfo/test2.htm но было это давно, что-то могло измениться (не в лучшую сторону). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 12:55 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
kdvя как-то писал статью В которой двоичные GUID-ы только упомянуты и не тестировались. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:03 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
kdvеще - объемы ПК с GUID на диске будут гораздо больше, чем обычное число. Т.к. "инкрементный ПК" хорошо упаковывается, а нынешние GUID-ы не упаковываются. А будет ли преимущество, если primary key все же хранить как integer, но в таблицы добавлять GUID'ное поле для уникальности и репликации? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:07 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
DelphiLexx, тут читали ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:08 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Таблоидчитали ? прочитал, юмора не понял ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:09 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Если мне не изменяет склероз, сабжевый вопросс уже поднимался, и Таблоид, как всегда дотошно и екстримально, проверял скорость. Разница была, но на миллионах записей в единицы, или десятки процентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:20 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Кстати, возможно я и ошибаюсь, но есть у меня ощущение, что большой индекс хоть и хуже на выборках, но должен быть лучше на DML, поскольку разные коннекты могут работать с разными индексными страницами, не толкаясь плечами. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:23 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
А будет ли преимущество, если primary key все же хранить как integer, но в таблицы добавлять GUID'ное поле для уникальности и репликации? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 13:42 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Вот честное слово - не понимаю я использование гуидов. Ну вот сходу если подумать, то удобство только в том что удобно разобрать таблицы на инсерты, но есть программы для сохранения ссылочной целостности. Больше не вижу плюсов. Использование инкрементов: вероятность появления переноса при увеличении на 1 в бите с номером p это 1/(2^p), да еще и то, что значение максимально компактно. А вот генерация гуида непонятно как(ну ладно понятно, но сложно и за большое количество инструкций), занимает больше место, да еще как-то надо быть уверенным в том, что гуид действительно уникален. Ладно можно ввести ограничение уникальности, но количество инструкций это не уменьшает. Да еще и на больших базах. Зачем такие сложности? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 14:07 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovбольшой индекс хоть и хуже на выборках, но должен быть лучше на DML, поскольку разные коннекты могут работать с разными индексными страницами, не толкаясь плечами.Размер ключа влияет на частоту расщепления страниц. При GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 14:22 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
DelphiLexxпрочитал, юмора не понял виноват, при указании ссылки потерял последнюю цифру номера темы. Вот тест оттуда: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=766493&msg=8966864 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 14:26 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
Андрей ВасильевичВот честное слово - не понимаю я использование гуидов. ........................................ да еще как-то надо быть уверенным в том, что гуид действительно уникален. GUID - действительно уникален. А смысл использования - синхронизация данных N-баз филиалов с Центральной базой (кажется, здесь принято называть это репликацией). Независимо от выбранного способа репликации (специально обученная тулза, голый SQL через cross-database запросы), так или иначе все упирается в решение задачи: "запись имеет ID. какой ID она имеет во внешней базе ?". Следовательно, при решении задачи репликации эту информацию нужно хранить. При использовании GUID мы можем ее не хранить, а идентификатор записи будет одинаковым как в ЦентральноБазе, так и в базе филиала, откуда запись пришла. Вроде бы на первый взгляд - уменьшение размера БД, т.к. мы не храним информацию о соответствии записей в Центральной базе с записями в базах филиалов. Но при этом: 1) БД растет из-за того, что GUID весят гораздо больше, чем INTEGER. 2) Индекс по INTEGER - был и всегда будет самым производительным, ибо одно дело сравнить два LongInt, а другое - сравнить две string[32] (ну хорошо, пусть будет два array[0..31] of byte). Я как-то задавался этим вопросом года два назад и решил поэксперементировать на рабочей базе клиента, введя дополнительные домены. Выигрыша не получил, зато получил проигрыш и время зря убил. (перевести все филиалы на GUID - одна неделя, репликация и отладка - вторая неделя, неделя эксперементов и получение личного опыта, что "все фигня, кроме пчел", и одна неделя - "вернуть все на родину"). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 14:32 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
DelphiLexxА будет ли преимущество Будет геморрой, приводящий к избыточности и тормозам. ТаблоидПри GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4). Да, но расщепляться при этом будут разные страницы, так что этот процесс может идти параллельно. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 14:44 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
ТаблоидРазмер ключа влияет на частоту расщепления страниц. При GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4). Ты залей лимон записей с guid и с int, потом посмотри кол-во страниц каждого индекса и ср. размер ключа. Ни 4, ни 16 ты там не увидишь :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 15:24 |
|
GUID в качестве primary key
|
|||
---|---|---|---|
#18+
hvladТы залей лимон записей с guid и с int, потом посмотри кол-во страниц каждого индекса и ср. размер ключа. Ни 4, ни 16 ты там не увидишь :)Вот результат для 1 ляма GUID в базе с pagesize=4096: Average data length: 14.05 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Код: 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. 52. 53. 54.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
[firebird@firebird firebird]$ gstat -r -t TTT ttt04.fdb Database "ttt04.fdb" Database header page information: Flags 0 Checksum 12345 Generation 25 Page size 4096 ODS version 11.2 Oldest transaction 16 Oldest active 17 Oldest snapshot 17 Next transaction 18 Bumped transaction 1 Sequence number 0 Next attachment ID 5 Implementation ID 24 Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Nov 9, 2011 15:56:18 Attributes Variable header data: *END* Database file sequence: File ttt04.fdb is the only file Analyzing database pages ... TTT (129) Primary pointer page: 22762, Index root page: 22763 Average record length: 9.00, total records: 1000000 Average version length: 0.00, total versions: 0, max versions: 0 Data pages: 12346, data page slots: 12346, average fill: 52% Fill distribution: 0 - 19% = 0 20 - 39% = 1 40 - 59% = 12345 60 - 79% = 0 80 - 99% = 0 Index RDB$PRIMARY2 (0) Depth: 3, leaf buckets: 3392, nodes: 1000000 Average data length: 1.01 , total dup: 0, max dup: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 3391 60 - 79% = 1 80 - 99% = 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2011, 16:36 |
|
|
start [/forum/topic.php?fid=40&msg=37517875&tid=1562582]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 252ms |
total: | 408ms |
0 / 0 |