|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
MS SQL 2k + PB8.03 и стоит ли с GUID связываться? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2004, 11:53 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Напрямую использовать GUID не удастся, PB не понимает GUID при работе с native MS SQL. Через ODBC или OLE DB не пробовал. Можно конвертировать GUID в строку и работать с ним как со строковым полем (varchar(40)) - можно поиметь отличный Primary key. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2004, 12:56 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
gerssможно поиметь отличный Primary key Это в смысле хорошо или плохо ? Именно в этом плане он меня и интересует. Работать вобираюсь через OLEDB. Может еще кто что скажет? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2004, 13:00 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Отличный PK должен быть как можно компактнее чего о GUID не скажешь. Поскольку GUID напрямую не поддерживается - лучше его вообще не использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2004, 15:36 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2004, 17:13 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Вовик Это в смысле хорошо или плохо ? Это хорошо, так как уникальность его гарантирована в очень широких пределах. ЗоринАндрей Отличный PK должен быть как можно компактнее чего о GUID не скажешь. использовать Отличный PK такой, за уникальность которого можно не беспокоиться, причем даже в рамках распределенной системы, БД которой расположены на разных серверах. И GUID обеспечивает уникальность PK даже и в этом случае. В нашей системе использовали другой способ формирования PK и поимели большой геморрой с синхронизацией 2 (только 2...) баз, которых, на самом деле, должно быть порядка 8-10. При этом сам GUID (честный, а не отконвертированный в строку), занимает в базе 16 байт - ИМХО нормально для PK. Так что использование GUID в качестве PK имеет определенные плюсы, но я готов согласиться с тем, что ЗоринАндрей Поскольку GUID напрямую не поддерживается - лучше его вообще не использовать ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2004, 15:47 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
gerssЭто хорошо, так как уникальность его гарантирована в очень широких пределах Меня вопросы производительности волнуют гораздо больше чем гарантии уникальности в широких пределах. Распределенные базы это вообще отдельная история. int занимает в четыре раза меньше места - это сильно влияет на скорость и объем. Проблемы синхронизации GUID не решает полностью - два идентичных Мухосранска с разными GUID это аномалия. А конфликты реальных ключей все равно будут и их как-то в распределенной базе все равно приходится решать. В итоге мы имеем ухудшение производительности в обмен на частичное решение проблем распределенной базы. Если у меня база локальная и я не собираюсь ее "размазывать" - использование GUID никакого выигрыша не дает - только минусы. например кластерный индекс по GUID уже просто так не сделаешь - надо позаботиться о выборе филлфактора чтобы из-за случайного характера GUID уменьшить количество pagesplits - иначе добавление будет в разы медленнее чем в таблицу к integer identity. А отказываться от кластерных индексов из каких-то глобальных соображений на мой взгляд глупо. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2004, 17:10 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
ЗоринАндрейВ итоге мы имеем ухудшение производительности в обмен на частичное решение проблем распределенной базы. А какое это, позвольте спросить решение? В случае применения суррогатных ключей, что само по себе есть очень верно, все решается очень просто штатными средствами MS SQL. А в случае наличия unique constraints (а естейственный ключ - тот же unique constraint) проблемы при слиянии содержимого баз, как уже было замечено, это никаким образом не решает. ЗоринАндрейнапример кластерный индекс по GUID уже просто так не сделаешь - надо позаботиться о выборе филлфактора чтобы из-за случайного характера GUID уменьшить количество pagesplits - иначе добавление будет в разы медленнее чем в таблицу к integer identity. Ну и не только это. К примеру, в этом случае GUID будет частью всех индексов, что добавит +16 байт в каждую запись индекса. Так что только проблем добавляет. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2004, 20:10 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Вовик, насчёт PB8.03 не знаю, но 9.01 через OLEDB нормально работает с ROWGUID columns (и по моему может их использоват как autoincrement)... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2004, 20:16 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
Локшин МаркВ случае применения суррогатных ключей, что само по себе есть очень верно Можно поподробнее , почему это верно? 2Филипп Спасибо , не знал , буду иметь в виду! Вообще я вижу , очень много спорят на форумах по этому поводу, насчет использования первичных ключей в распределенных базах. У меня проблема такая : сейчас организуется одна база. Затем предполагается что они будут размножаться ( на филиалы , представительства и т.п. ). Встанет задача слияния данных из разных баз для консолидации отчетов. Вот я и в разждумьях. До сих пор использовал только int в качестве PK с включенным identity. Для моего случая , думаю подойдет создание специальной консолидированной базы для отчетов , куда будут сливаться не первичные данные , а результаты некоторых view или sp. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2004, 10:27 |
|
PowerBuilder понимает GUID ?
|
|||
---|---|---|---|
#18+
ВовикМожно поподробнее , почему это верно? http://www.akzhan.midi.ru/devcorner/articles/NaturalKeysVersusAtrificialKeysByTentser.html ВовикУ меня проблема такая : сейчас организуется одна база. Затем предполагается что они будут размножаться ( на филиалы , представительства и т.п. ). Встанет задача слияния данных из разных баз для консолидации отчетов. Вот я и в разждумьях. До сих пор использовал только int в качестве PK с включенным identity. Ну и используйте дальше. Прочитайте про not for replication, identity seed и identity increment. ВовикДля моего случая , думаю подойдет создание специальной консолидированной базы для отчетов , куда будут сливаться не первичные данные , а результаты некоторых view или sp. А вы это будете делать стандартными средствами MS SQL или что-то свое писать, а то я что-то плохо представляю, как вы будете сливать результаты view/sp c помощью стандартных возможностей. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2004, 11:26 |
|
|
start [/forum/topic.php?fid=15&fpage=107&tid=1339226]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
95ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 201ms |
0 / 0 |