Конструкция БД для синхронизированного настольного приложения

Question

Я создаю настольное приложение, которое будет работать на нескольких ноутбуках. Он должен будет синхронизироваться с центральной базой данных всякий раз, когда пользователь возвращается в офис и снова получает доступ.

Моей главной проблемой для преодоления является создание базы данных так, чтобы она легко синхронизировалась с центральным сервером базы данных. Одним из основных препятствий является определение того, как обрабатывать ключи таким образом, чтобы они не дублировались через несколько баз данных ноутбуков, которые будут использоваться.

Например, ноутбук 1 вводит нового клиента под названием «Клиент А» - с использованием уникального идентификатора ему может быть присвоен идентификатор клиента 20. Ноутбук 2 входит в «Клиент С» - он также может назначить идентификатор 20 к этому клиенту. Когда придет время для синхронизации, оба клиента A & C попадут на сервер с дублирующимся идентификатором.

Кто-нибудь работал с приложением, подобным этому, которое имеет изящное решение?

Answer 1

Альтернативы:

• диапазоны идентификаторов, которые трудно осуществить, и для выполнения. Их очень сложно управлять, сложно обеспечить новый сайт/диапазон и еще сложнее справиться с удаленными сайтами/диапазонами.
• Составные клавиши, (siteId, EntityId) лучше, чем диапазоны, но требуют предварительной разработки и могут создавать проблемы с запросами, которые объединяют несколько/все сайты (центральные DW), поскольку самый левый ключ во всех индексах (siteId) не указан ,
• GUIDs. В теории они идеальны, поскольку они гарантируют уникальность (они могут конфликтовать в теории, я еще не вижу истинного конфликта с руководством). На практике они представляют собой очень плохие кластерные ключевые варианты из-за размера (16 байт) и из-за фрагментации. Тем не менее, они намного легче получить, чем подход с комбинированным ключом.

Answer 2

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

Вы также лучше разработали процесс удаления дубликатов, так как, как и все, rep A собирается upt в клиенте A, а rep b также будет размещен в клиенте A, а также потому, что они поступают из разных источников с разными первичными ключи, они будут разными записями.

Answer 3

Используйте Guids (aka uniqueidentifier) для ваших основных ключей, и все ваши проблемы с репликацией исчезнут. Штрафы за использование гидов почти всегда сильно завышены сторонниками автоинкремента int ПК. Дополнительный размер, который им нужен (16 байт против 4 байтов для int) настолько тривиальен, что я поражен тем, что он когда-либо появляется в дискуссиях по этому вопросу. Запросы, которые JOIN на Guid PK будут работать медленнее запросов JOIN на int ПК, но это не порядка величины (т. Е. 10X) медленнее. Ваши результаты могут отличаться, но я обнаружил, что Guid Запросы JOIN занимают на 40% больше времени для выполнения (что может показаться большим штрафом, пока вы не вспомните закон Мура).

Использование Guids for PK также избавляет вас от необходимости делать действительно взломанные вещи, когда вы вставляете связанные данные. Вместо того, чтобы вставлять дочерние записи, а затем извлекать идентификаторы только что вставленных строк, прежде чем вставлять родительские строки, вы просто создаете все идентификаторы на стороне клиента с помощью Guid.NewGuid().

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