Intereting Posts
Помощь в получении String Array из файла arrays.xml ImageView вернется в исходное состояние после вращения? Как я могу открыть закрытый InputStream, когда мне нужно его использовать 2 раза Что такое MediaPlayer.OnInfoListener "код 703"? Как включить javadoc для библиотеки поддержки Android? Android Как реализовать нижний лист из документов Material Design Android: добавление окна не удалось / android.os.TransactionTooLargeException на устройствах Samsung Используя OKHttp, в чем разница между синхронным запросом в AsyncTask и OKhttp Asynchronous request? Переход обратно в FragmentPagerAdapter -> фрагменты пустые Пользовательский конвертер для дооснащения 2 Пользовательская сборка Android с использованием Ant Как преобразовать HashMap в json Array в android? Получение «отлаживаемого» значения androidManifest из кода? Как добавить параметры в api (http post), используя библиотеку okhttp в Android Виджет управления питанием, отображаемый на короткое время при обновлении моего собственного виджета через AppWidgetManager, в чем проблема?

Какова наилучшая первичная ключевая стратегия для онлайн-офлайнового многопользовательского мобильного приложения с базами данных SQLite и Azure SQL в качестве центрального магазина?

Какую стратегию первичного ключа лучше всего использовать для модели реляционной базы данных, учитывая следующее?

  • Десятки тысяч пользователей
  • Несколько клиентов на одного пользователя (телефон, планшет, рабочий стол)
  • Миллионы строк в таблице (постоянно растущие)

Azure SQL будет центральным хранилищем данных, которое будет отображаться через Web API. Клиенты будут включать в себя веб-приложение и ряд собственных приложений, включая iOS, Android, Mac, Windows 8 и т. Д. Веб-приложение потребует «всегда включенное» соединение и не будет иметь локальное хранилище данных, но вместо этого будет получать и обновлять Через api – думаю CRUD через RESTful API.

Все остальные клиенты (телефон, планшет, рабочий стол) будут иметь локальный db (SQLite). При первом использовании этого типа клиента пользователь должен аутентифицироваться и синхронизироваться. После аутентификации и синхронизации эти клиенты могут работать в автономном режиме (создание, удаление и обновление записей в локальном SQLite db). Эти изменения в конечном итоге будут синхронизироваться с бэкэндом Azure.

Распределенный характер баз данных оставляет нам проблему с первичным ключом и причину возникновения этого вопроса.

Вот что мы рассмотрели до сих пор:

GUID

Каждый клиент создает свои собственные ключи. При синхронизации есть очень небольшой шанс для дублирующего ключа, но нам нужно будет учесть его, написав функциональность в каждом клиенте, чтобы обновить все отношения с помощью нового ключа. GUID являются большими и при рассмотрении нескольких внешних ключей на таблицу, хранение может стать проблемой с течением времени. Вероятно, самой большой проблемой является случайный характер GUID, что означает, что они не могут (или не должны) использоваться в качестве кластеризованного индекса из-за фрагментации. Это означает, что нам нужно создать кластерный индекс (возможно, произвольный) для каждой таблицы.

тождественность

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

композитный

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

HiLo (объединенный композит)

Подобно комбинированному подходу каждому клиенту присваивается идентификатор клиента (int32) при первой синхронизации. Идентификатор клиента объединяется с уникальным локальным идентификатором (int32) в один столбец, чтобы сделать уникальный уникальный идентификатор приложения (int64). Это не должно приводить к конфликтам во время синхронизации. Хотя для этих ключей и GUID больше ограничений, так как идентификаторы, созданные каждым клиентом, являются последовательными, будут тысячи уникальных идентификаторов клиентов, так что мы все еще подвергаем риску фрагментации нашего кластерного индекса?

Мы что-то пропускаем? Существуют ли какие-либо другие подходы, которые стоит исследовать? Обсуждение плюсов и минусов каждого подхода было бы весьма полезным.

Solutions Collecting From Web of "Какова наилучшая первичная ключевая стратегия для онлайн-офлайнового многопользовательского мобильного приложения с базами данных SQLite и Azure SQL в качестве центрального магазина?"

Ключевая (предназначенная для каламбура) вещь, которую нужно запомнить, – это просто иметь уникальный ключ для каждого объекта, который вы храните в постоянном хранилище. Как вы справляетесь с хранением этого объекта, полностью зависит от вас и до методологии доступа к этому ключу. Каждая из перечисленных вами стратегий имеет свои причины для того, почему они делают то, что они делают, но в конце они хранят ключ для определенного объекта в db, поэтому все его атрибуты могут быть изменены, сохраняя одну и ту же ссылку на объект в базе данных ,