GUID как первичные ключи - офлайновый OLTP
In main()
{
printf("enter string :\n");
fgets(buf, 200, stdin);
unsigned char str_len = strlen(buf);
k=0;
unsigned char bytearray[100];
for(j=0;j<str_len-1;j=j+2)
{ bytearray[k++]=converttohex(&buffer[j]);
printf(" %02X",bytearray[k-1]);
}
}
Use this
int converttohex(char * val)
{
unsigned char temp = toupper(*val);
unsigned char fin=0;
if(temp>64)
temp=10+(temp-65);
else
temp=temp-48;
fin=(temp<<4)&0xf0;
temp = toupper(*(val+1));
if(temp>64)
temp=10+(temp-65);
else
temp=temp-48;
fin=fin|(temp & 0x0f);
return fin;
}
15 ответов
Используя Гуиды как первичные ключи приемлемо и считается довольно общепринятой практикой по тем же причинам, что Вы рассматриваете их. Они могут злоупотребиться, который может сделать вещи немного утомительными, чтобы отладить и справиться, так попытайтесь сохранить их от кодовых таблиц и других справочных данных если вообще возможными.
Вещью, которой необходимо коснуться себя, является человекочитаемый идентификатор. Гуидами не могут обменяться люди - можно ли предположить пытаться подтвердить номер заказа по телефону, если это - гуид? Таким образом в офлайновом сценарии Вам, вероятно, все еще придется генерировать что-то - как издатель (рабочая станция/пользователь) идентификатор и некоторый порядковый номер, таким образом, номер заказа может быть 123-5678-.
Однако это не может удовлетворить бизнес-требования наличия порядкового номера. На самом деле нормативные требования могут быть и влияние - некоторые инструкции (SOX, возможно) требуют, чтобы номера счетов-фактур были последовательны. В таких случаях может быть необходимо генерировать своего рода число проформы, которое согласовано позже, когда системы синхронизируются. Можно кончить с наличием таблиц OrderId (Гуид), OrderNo (интервал), ProformaOrderNo (varchar) - некоторая сложность может закрасться.
По крайней мере, наличие гуидов как первичные ключи означает, что Вы не должны делать большого расположения каскадом обновлений, когда синхронизация действительно в конечном счете происходит - Вы просто обновляете человекочитаемое число.
@Portman PK по умолчанию == Кластерный индекс, создавая ограничение первичного ключа автоматически создаст кластерный индекс, необходимо указать не кластеризируемый, если Вы не хотите кластеризируемый.
Сначала мысль, которая приходит на ум: Разве MS не разработал модель DataSet и DataAdapter для поддержки сценариев как это?
Я полагаю, что читал, тот MS изменил их модель набора записей ADO на текущую модель DataSet, таким образом, это работает отлично офлайн также. И существует также эта Sync Services для ADO.NET
Я полагаю, что видел код, который использует модель DataSet, которая также использует внешние ключи, и они все еще синхронизируют отлично при использовании DataAdapter. Havn't испытывают Sync Services хотя, но я думаю, что Вы смогли извлекать выгоду из этого также.
Надеюсь, это поможет.
я начал бы смотреть на SQL Server Компактный Выпуск для этого! Это помогает со всеми Вашими проблемами.
Архитектура хранения данных с SQL Server компактный выпуск 2005 года
Это специально предназначенный для
Полевые приложения силы (FFAs). FFAs обычно совместно используют один или несколько следующих атрибутов
Они позволяют пользователю выполнять свои функции задания, в то время как отключено от сети бэкенда — на месте в клиентском местоположении, на дороге, в аэропорту, или из дома.
FFAs обычно разрабатываются для случайной возможности соединения, означая, что, когда пользователи выполняют клиентское приложение, у них не должно быть сетевого соединения никакого вида. FFAs часто вовлекают несколько клиентов, которые могут одновременно получить доступ и использовать данные из базы данных бэкенда, и в связанном и разъединенном режиме.
FFAs должен смочь копировать данные от базы данных бэкенда до клиентских баз данных для офлайновой поддержки. Они также должны смочь копировать измененные, добавленные, или удаленные записи данных от клиента к серверу, когда приложение может соединиться с сетью
@Simon,
Вы поднимаете очень положительные вопросы. Я уже думал о "временных" "человекочитаемых" числах, которые я генерирую, в то время как офлайн, который я воссоздал бы на синхронизации. Но я не хотел делать с с внешними ключами и т.д.
Если Ваша база данных является достаточно маленькой, чтобы загрузить на ноутбук и работать с ним офлайн, Вы, вероятно, не должны волноваться слишком много о различиях в производительности между ints и Гуидами. Но не недооценивайте, как полезные ints при разработке и поиске и устранении неисправностей системы! Необходимо будет, вероятно, придумать некоторую довольно сложную логику импорта/синхронизации независимо от того, используете ли Вы Гуиды, таким образом, они не могли бы помочь столько, сколько Вы думаете.
Бэкенд будет SQL Server 2005
Frontend / Прикладная логика будет .NET
Помимо GUID, можно ли думать о других способах разрешить "слияние", которое происходит, когда офлайновый компьютер синхронизирует новые данные назад в центральную базу данных?
Я имею в виду, если ключи являются INTs, я должен буду перенумеровать все при импорте в основном. GUID сэкономят меня этого.
Используя GUID сохранил нас большая работа, когда мы должны были объединить две базы данных в одну.
Удостоверьтесь, что использовали guid.comb - заботится о материале индексации. Если Вы будете заниматься проблемами производительности после этого затем, то Вы будете, в быстром порядке, экспертом по масштабированию.
Другая причина использовать GUID состоит в том, чтобы включить рефакторинг базы данных. Скажите, что Вы решаете применить полиморфизм или наследование или безотносительно к Вашему Клиентскому объекту. Вы теперь хотите, чтобы Клиенты и Сотрудники произошли от Человека и сделали, чтобы они сидели за одним столом. Наличие действительно уникальных идентификаторов делает миграцию данных простой. Нет никаких последовательностей или целочисленных полей идентификационных данных для борьбы с.
Вы корректны, что это - старая проблема, и она имеет два канонических решения:
Используйте уникальные идентификаторы в качестве первичного ключа. Обратите внимание что, если Вы обеспокоены удобочитаемостью, что можно прокрутить собственный уникальный идентификатор вместо того, чтобы использовать GUID. Уникальный идентификатор будет использовать информацию о дате и машине для генерации уникального значения.
Используйте составной ключ 'Агента' + идентификатор. Каждый пользователь получает числовой идентификатор агента, и ключи недавно вставленных строк используют идентификатор агента, а также следующий доступный идентификатор. Таким образом, если два агента оба вставят новую строку с идентификатором "100", то ограничение первичного ключа не будет нарушено.
Лично, я предпочитаю первый подход, поскольку я думаю, что составные ключи действительно утомительны как внешние ключи. Я думаю, что человеческая жалоба на удобочитаемость завышена - конечным пользователям ничего не придется знать о Ваших ключах, так или иначе!
Получит доступ к этим таблицам через ключ GUID быть медленным?
Существуют другие проблемы с GUID, Вы видите, что GUID не последовательны, поэтому вставки будут рассеяны повсеместно, это вызывает индексная фрагментация и расщепления страницы
В мс SQL Server 2005 представленный NEWSEQUENTIALID () для фиксации этого единственная проблема для Вас могла бы состоять в том, что можно только использовать NEWSEQUENTIALID в качестве значения по умолчанию в таблице
Это - совершенно хорошее использование GUID. Единственные спины ничьей были бы небольшой сложностью в работе с GUID по INTs и небольшому различию в размере (16 байтов по сравнению с 4 байтами).
Я не думаю, что любой из тех является грандиозным предприятием.
@SqlMenace
Существуют другие проблемы с GUID, Вы видите, что GUID не последовательны, поэтому вставки будут рассеяны повсеместно, это вызывает индексная фрагментация и расщепления страницы
Не верно. Первичный ключ! = кластерный индекс.
Если кластерный индекс является другим столбцом ("inserted_on", приходит на ум), затем, вставки будут последовательны и никакие расщепления страницы, или чрезмерная фрагментация произойдет.
Гуиды, конечно, будут медленнее (и использовать больше памяти), чем стандартные целочисленные ключи, но является ли это проблемой, будет зависеть от типа загрузки, которую будет видеть Ваша система. В зависимости от Вашего бэкенда DB там может быть проблемами с индексацией полей гуида.
Используя гуиды упрощает целый класс проблем, но Вы платите за него, часть будет производительность и также debuggability - ввод гуидов в те тестовые запросы станет старым очень быстро!
Я просто хочу указать вам на Каково улучшение производительности Sequential Guid по сравнению со стандартным Guid? , в котором рассказывается о GUID.
Для удобства чтения человеком рассмотрите возможность присвоения идентификаторов машин и последующего использования последовательных номеров с этих машин. Однако для этого потребуется управлять назначением идентификаторов компьютеров. Это можно сделать в одну или две колонки.
Мне лично нравится ответ SGUID.