МарсельПривет
В БД завел поле с типом UNIQUEIDENTIFIER, пробую в Delphi7.1 сделать селект:
"dbExpress error: Invalid field type"
Выход один - UNIQUEIDENTIFIERSTR? Подскажите
Заранее спасибо
Начиная с ASA 9.0.2 тип UNIQUEIDENTIFIER передается клиентским приложениям как varchar(32), по моему даже опция появилась, которая это регулирует. Однако я бы категорически рекомендовал не связываться без особых причин с данным типом по следующим причинам:
1. Большой размер поля, если оно PK, FK или на него есть индексы, то индексы не могут построится оптимально в силу его "случайности" и производительность по любому падает.
2. Все равно у клиентских приложений с ним могут быть проблемы.
3. Тяжело читать запросы и тем более отлаживать их, особенно с учетом того, что в Central и ISQL они хоть и показываются в стринговом виде, а при копировании в буфер все равно идут как бинарные поля.
4. Самое главное - в ASA не до конца идет поддержка данного типа - например могут возникнуть серьезные проблемы с Remote Server, где не подключаются прокси-таблицы удаленного сервера ASA, если в них есть данный тип. Хотя эту я ошибку заявлял и возможно ее уже исправили, сам я в последних EBF это не проверял.

Если нужен уникальный ключ для репликации, то лучше использовать GLOBAL AUTOINCREMENT, самое милое и удобное дело, особенно с учетом того, что под него возможно использовать различные целые типы в зависимости от ориентировочного максимального кол-ва записей в таблице. В свое время ради интереса я попробовал поиграться с UNIQUEIDENTIFIER и точно понял, что он гораздо неудобнее и хуже, чем GLOBAL AUTOINCREMENT.

Хотел бы я посмотреть на приложение, которому даже при куче удаленных узлов не хватит UNSIGNED BIGINT. Такие обьемы данных просто сама консолидированная БД не потянет. С другой стороны, даже если у узла закончится предел счетчика на таблицу, надо думать будет вызвано соотвествующее событие, на котором можно спокойно например присвоить БД новый свободный GLOBAL DATABASE ID. Так что если рассуждать чисто теоретически о террабайтных базах и миллиардах записей (я бы сказал даже маниакально), то GUID надежнее, а если чисто практически, не думая, что будет через сто лет, а озадачиваясь более насущными проблемами (например производительность и размер БД), то GUID достаточно невыгодное решение во всех отношениях.

Рыжий Котесли говорить о земных задачах, то UNSIGNED BIGINT может вызвать больше проблем, нежели char(36)


Неплохо бы пояснить утверждение :) Я у меня пока никаких проблем не наблюдалось, да и к тому же этот тип используется только в паре табличек, в которых действительно может быть большое кол-во записей по узлам. В других, где нет таких обьемов, используются unsigned smallint и unsigned int и получается все компактно и быстро.

авторнет проблем - слава Богу. аналогично могу заявить про UUID. И голова не болит про GLOBAL DATABASE ID. Падение производительности вполне может быть, не чувствуется (а значит :) все в порядке). Немного не понятно утверждение
Ok, вернемся к кроликам - в последнем паке ASA таблицы с GUID можно подключать как прокси-таблицы к другому ASA через удаленный сервер ? ;)

авторвроде как Чингиз описывал проблему, когда у него что-то поехало с раздачей int, правда версия ASA была старенькой, но раз было - уже доверия нет.
Ну если машины попадают в аварии, то это означает, что все ходим пешком ? ;)

авторНапример, во что превратится этот UNSIGNED BIGINT при использовании в Delphi? (я знаю, что вы недолюбливаете этот продукт Борланда, но все же)
Если не через этот ужастный BDE, а тот же ADO, то никаких проблем не наблюдается, если не перелазить за 18 знаков. Хотя я все равно не долюбливаю не то что этот продукт, а вообще Borland и все его продукты :)

авторесли в таблице записи активно не только создаются, но и уничтожаются, то маниакальность в этом случае оправдана.
Гм - берем UNSIGNED BIGINT - это всего то 18 446 744 073 709 551 615 записей, не очень знаю, сколько это будет называться, явно больше квадратиллионов. Считаем, что у нас 10 000 филиалов, плюс сбрасываем максимальное число записей до 18 знаков, чтобы не раздражать клиентские приложения, т.е. для ровного счета 100 000 000 000 000 000 делим на 10 000. Получаем разрез 10 000 000 000 000, иначе в 10 триллионов записей. Возникает закономерный вопрос - это сколько же нужно вбивать и удалять записей, чтобы превысить данный предел ??? :) Аналогично, если не предполагается в таблицах сотни миллионов записей и филиалов меньше сотни, то вообще таблицы спокойно ложатся на UNSIGNED INT, для которого 4 миллиарда записей бывает вполне достаточно.

авторНемного не понятно утверждение про индексы
Очень даже понятно - индексы строятся в виде сбалансированных деревьев, я не представляю себе, как можно построить сбалансированное дерево на GUID, который каждый раз скачет в любую сторону по значению. Соотвествующе при операциях вставки записей идут трудозатраты на вставку скачущего значения в индекс по PK и FK, при запросах дольше идет поиск по деревьям. В случаях же GLOBAL AUTOINCREMENT таких проблем изначально не наблюдается, значения наращиваются постепенно, соотвествующе легче перестраивать индексы и искать по ним.

Ну мне легче, я с PHP и Excel не работаю. Значит приходим к выводу, что от клиентских приложений зависит и способ ведения уникальных ключей.