GUID как первичные ключи - автономный OLTP

Question

Мы работаем над созданием приложения, которое обычно является OLTP (подумайте: система закупок). Однако для этого, в частности, необходимо, чтобы некоторые пользователи были в автономном режиме, поэтому им необходимо иметь возможность загружать БД на свою машину, работать на ней, а затем выполнять синхронизацию, когда они находятся в локальной сети.

Я хотел бы отметить, что я знаю, что это было сделано раньше, у меня просто нет опыта работы с этой конкретной моделью.

Одна идея, о которой я подумал, - это использование GUID в качестве ключей таблицы. Так, например, заказ на поставку будет иметь не номер (авто-числовой), а GUID, так что каждый автономный клиент может их сгенерировать, и у меня не будет конфликтов при подключении к БД.

Это плохая идея по какой-то причине? Будет ли доступ к этим таблицам через ключ GUID медленным?

Был ли у вас опыт работы с системами такого типа? Как вы решили эту проблему?

Спасибо!
Daniel

Answer 1

@ Саймон,

Вы поднимаете очень хорошие очки. Я уже думал о «временных» «понятных человеку» числах, которые я генерировал бы в автономном режиме, которые я воссоздаю при синхронизации. Но я хотел избежать использования внешних ключей и т. Д.

Answer 2

Если ваша база данных достаточно мала для того, чтобы загружать ее на ноутбук и работать с ней в автономном режиме, вам, вероятно, не нужно слишком беспокоиться о различиях в производительности между int и Guids. Но не стоит недооценивать, насколько полезны целые числа при разработке и устранении неполадок в системе! Вам, вероятно, потребуется придумать довольно сложную логику импорта / синхронизации независимо от того, используете ли вы Guids или нет, поэтому они могут не так сильно помочь, как вы думаете.

Answer 3

Использование GUID избавило нас от большой работы, когда нам пришлось объединить две базы данных в одну.

Answer 4

Бэкэнд будет SQL Server 2005
Логика внешнего интерфейса / приложения будет .Net

Помимо GUID, можете ли вы подумать о других способах устранения "слияния", которое происходит, когда автономный компьютер синхронизирует новые данные обратно в центральную базу данных?
Я имею в виду, что если ключи INT, мне придется все нумеровать при импорте. GUID избавит меня от этого.

Answer 5

Направляющие будут, конечно, медленнее (и использовать больше памяти), чем стандартные целочисленные ключи, но будет ли это проблемой, зависит от типа нагрузки, которую увидит ваша система. В зависимости от вашей внутренней БД могут возникнуть проблемы с индексированием полей guid.

Использование направляющих упрощает целый класс проблем, но вы платите за это, отчасти производительность и отладка - ввод руководств в эти тестовые запросы устареет очень быстро!