Сабж. Цікавлять думки в розрізі продуктивність-зручність, якщо GUID зберігати у вигляді CHAR (32)
а чому тоді "vs Number"?
> Первинний ключ GUID vs NUMBER в Oracle
Це смерті подібно! НАВІЩО. Цим грішили тільки фахівці з MS SQL Server (не маючи можливості отримувати ID Автоінкрементний ключів до виконання DML).
мається на увазі щщётчік по сиквенсу
Проізводітельнеее ROWID все одно нічого немає.
А її можна привести до рядка і назад взад.
> 1 Можна генерувати на клієнті або на аппсервере і знати
> Значення ключа до моменту вставки
І Number можна генерувати. Не бачу проблеми.
> 2 Унікальна ідентифікація пакетів даних, переданих
> В офф-лайн режимі (наприклад, SMTP-SOAP) між різними
> Організаціями, в яких встановлена система
Це від завдання залежить, на мій погляд. А твоє запитання GUID vs NUMBER занадто заг, щоб на нього в цьому випадку дати однозначну відповідь.
> 3 Апгрейд довідників від головного до дочірнім організаціям
> В тому випадку, якщо в дочірніх організаціях дозволено доповнювати
> Довідники своїми записами
Це неоднозначно. Точно також їх можна upgradіть і NUMBER "ом. Як конфлікти будуть визначатися, якщо парочка дочірніх організацій введе однакові записи, що відрізняються тільки GUID" ом?
Ось цим-то Оракл і відрізняється від MS SQL Server.
Роби запит SEQ_NAME.NEXTVAL і отримуй гарантовано унікальне значення!
Більш того, компоненти типу DOA і ODAC самі вміють це робити (їм треба вказати послідовність, "працюючу" на обрану таблицю).
> (Не маючи можливості отримувати ID Автоінкрементний ключів
> До виконання DML)
А навіщо його отримувати до. Можна і відразу після. Я і в Оракл так часто роблю - там returning є.
Имхо. GUID - спроба легше вирішити проблему реплікації.
Плюс тільки один - швидко і легко у всіх базах унікальні (з високою ймовірністю) ID-шники.
мінуси:
1) Взагалі то ймовірність хапнути однаковий ID їсть, хоч і дуууже низька
2) генерітся довше сиквенсу
3) Чи індексувати важче - по числах індекс ефективніше
4) Ні мнемонічною інформації, як то. джерело формування (номер сервера, наприклад), порядок генерації (при грамотній організації формування ID можна за номерами визначити, яка із записів з'явилася пізніше)
5) Для намбер треба таки менше місця.
6) Мій вчитель сказав, що за його досвіду намберовие ID краще (для мене це основний пункт :))
> 6) Мій вчитель сказав, що за його досвіду намберовие ID краще
> (Для мене це основний пункт :))
Watch somebody used / debug once
(C) VMS user hierarchy
Так я 100 раз приклад наводив - в разі, якщо треба створити безліч записів з пов'язаних таблиць на клієнті. Відправляєш їх на сервер вже з розставленими по правилам зовнішніх ключів значеннями і більше про них не турбуєшся.
> 2 Унікальна ідентифікація пакетів даних, переданих
> В офф-лайн режимі (наприклад, SMTP-SOAP) між різними
> Організаціями, в яких встановлена система
Як це до ключів в БД має відношення?
І навіщо тобі унікальний ключ на всі види таблиць?
Індекси по CHAR помітно гальмівні.
ЗИ кожній дії свій інструмент. GUID як PK в таблицях, имхо, що не рулить.
> Так я 100 раз приклад наводив - в разі, якщо треба створити
> Безліч записів з пов'язаних таблиць на клієнті
Це - а нафіга. Ну, якщо MS SQL такої кривої, що немає генераторів, крім автоїнкрементальних полів, то нафіга все відразу формувати?
Створюєш спочатку майстер-запис. Потім витягаєш ID і підставляєш в деталі. І спосіб генерації в MS SQL теж підкручувати можна.
У Оракл можна сиквенс посмикати заздалегідь і вставити. Хоча все одно оператори по одному поїдуть. А ще краще по можливості запхати цей код в пакет і не мучиться.
Дополнб - тому що MS SQL їсть пакети DML операторів, то можна заганяти отримані ID в серверні змінні (якщо я правильно їх назвав) і далі їх використовувати. Теж одним пакетом всі і поїде.
Це шарашіт обмін клієнт-сервер при відкритій транзакції.
На це я піти не можу :(
(Напевно тому не працюю з MS SQL).
> Це шарашіт обмін клієнт-сервер при відкритій транзакції?
>.
> На це я піти не можу :(
А що тут такого неправильного?
MS SQL такого не пробачить!
> Тобто як "що такого"?
> Ти пропонуєш відкрити транзакцію, запустити DML на сервер,
> # XA0; дочекатися виконання, отримати @@ identity на сервері, відіслати
> Його на клієнта, де заповнити потрібні значення підлеглих
> Таблиць, потім відправити нові DML на сервер і закрити транзакцію?
>.
>
> MS SQL такого не пробачить!
По-перше - пробачить
По друге - можна це все в одному пакеті зробити.
А що, распределёнок никто не пишет? Вражає така одностайність в думках. Мені важко уявити собі життя без Гуїдо в системах, ну, наприклад, документообігу. Хоча його цілком можна використовувати як допоміжний поле, але в такому випадку ми маємо фактично два первинних ключа
І распределенкі пишуть.
І проблему унікальності вирішують. І в разі намбер ключів і в разі рядків. Причому як уже говорилося кимось вище з використанням мнемонічною прив'язки ключа до підсистеми.
Багато пишуть распределенкі. Але до чого тут GUID.
Мені важко уявити собі, куди прикрутити GUID в документообігу. І чим в даному випадку документообіг відрізняється від, наприклад, бухгалтерського обліку? Може бути для проводки GUID корисний?
Єдиний раз він мені знадобився - при оформленні індивідуальної пластикової картки клієнта.
> Я насилу уявляю собі життя без Гуїдо в системах,
> # XA0; ну, наприклад, документообігу.
Насилу уявляю - а на хрена він там потрібен. )
> Хто такий "пакет"?
В MS SQL можна відправити на сервер кілька DML в одному запиті.
А можна і шматок T-SQL.
Фактично він кожен запит розуміє як щось на зразок безіменного блоку в Оракл. При цьому ще й можна повернути набір даних. І не один.
Приклад з життя. Номенклатура лабораторних досліджень включає в себе кілька тисяч найменувань, тому жодна лабораторія не в змозі виконати всі досліджень і між лабораторіями може існувати домовленість про розподіл робіт. Наприклад, одна досліджує тільки кров, інша тільки сечу, а для клієнта це поділ праці байдуже - він приходить в першу лабораторію, здає і те, і інше. Оформляє електронне замовлення і досліджує кров та лабораторія, в яку він звернувся, а сечу ця лабораторія відправляє лабораторії-партнеру, і їй же відправляється копія замовлення в електронному вигляді.
Таким чином, в базі даних лабораторії-партнера автоматично опиняється копія направлення з унікальним ідентифікатором. Після того, як всі дослідження були виконані, розумно ці два замовлення злити в один.
Не розумію, яку там сечу треба злити з кров'ю. )))
Я підозрюю, що GUID якимось чином затикає огріхи в проектуванні БД.
> Абсолютно вірно, реплікація - ключове слово.
Цікаво, як ти по Гуїдо потім визначиш, на якому з серверів народилася запис?
Я працював з системою, в якій в реплікації було задіяно більше 10 реальних серверів (не рахуючи допоміжних дзеркал). І там нормально використовувалися саме намберовие ID. При цьому при розборі польотів завжди можна було простежити звідки що приїхало.
За ідентифікатором організації. Теж Гуїдо. Причому береться з Active Directory.
> За ідентифікатором організації. Теж Гуїдо. причому береться
> З Active Directory.
Тоді у тебе буде два GUID "а. Один для унікальності записи, другий для організації, яка за цей запис відповідальна. Або я чогось не зрозумів.
Що в цьому поганого. )
Так, в принципі, нічого особливого. З такої логіки випливає, що GUID-ним корисно зробити все первинні ключі всіх таблиць всіх БД в світі.
Зрозумій же, - ти так і не обґрунтував застосування саме GUID для ідентифікації! У той час, як проти нього висловилися дуже багато.
Однак, треба віддати належне істині - бази з GUID-ними ID можуть працювати безпомилково.
У мене є дві сістемкі на сотню тис. Записів у таблиці max на Гуїдо. Працює як годинник. Звик і руку набив. Просто планується ще один модуль, в якому є мегатабліца, що використовує декартовій твір, там справа може до десятка мільйонів дійти.
Тест продуктивності на Oracle 10 XE я виконати не зміг :) мільйон записів з ідентифікатором типу Number він вставляв хвилин 10, а над мільйоном записів з ідентифікатором-char (32) Оракл покряхтел півгодини і сказав, що у нього інтернал еррор.
Пам'ять: 0.83 MB
Час: 0.098 c