Проектирование базы данных с пользовательскими данными и центральными обновлениями базы данных - PullRequest
0 голосов
/ 17 декабря 2018

Я разрабатываю приложение для рабочего стола Windows.Он использует LiteDB в качестве единого файла local db для пользователей - он очень часто используется в качестве реляционной базы данных с внешними ключами и т. Д. (Каждая таблица имеет целочисленный идентификатор в качестве первичного ключа и ссылки на другие таблицы через целые числа FK).

Это приложение для ретро-игр, поэтому «столы» будут включать в себя такие вещи, как:

Система (например, «Sony PlayStation», «Nintendo 64»)

Контроллер (например, «Sony Dual Shock»)

Control (например, «Cross», «Start», «Select»)

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

Пользователь должен иметь возможность добавлять и удалять записи по своему усмотрению (хотя будет нежелательно удалять «стандарты»)

Проблема в том, что я также собираюсь разместить базу данных mysql на моем сервере, что позволит пользователям обновлять свои таблицы с этого.Теперь это то, что я не могу понять.

Допустим, они добавляют Системные "Часы Casio" в свою локальную таблицу.Это получит идентификатор автогена (скажем, «94»).В то же время, некоторые обновления происходят в базе данных сервера, и добавляется новая система (например, «Commodore Calculator»), которая также получает автоматический идентификатор «94».Это конфликт номер 1.

Вы можете обойти вышесказанное, просто добавив его в качестве новой строки в пользовательской базе данных - получив в этом новый идентификатор.Но мое второе беспокойство касается внешних ключей.Допустим, есть таблица «Производители» с полем «Крупнейший продавец».Теперь для сервера «Производитель = Commodore» для «Commodore Calculator» FK «Крупнейший продавец» равен 94. Однако если эта таблица «Производитель» импортируется в локальную базу данных пользователя, то самым крупным продавцом «Коммодора» будет «Часы Casio» - это идентификаторбудучи 94 на пользователя дБ.

Простите, если я немного медленнее всего этого.На ум приходит ссылочная целостность (это та, в которой обновляются / обнуляются FK при изменении ??), но я не думаю, что вы можете сделать это через LiteDB (то есть изменение в одной не каскадируется к связанным таблицам).

Любой совет будет принята с благодарностью.

1 Ответ

0 голосов
/ 17 декабря 2018

Использование простого поля автоинкремента не будет работать, как вы точно указали.

Либо добавьте поле «идентификатор сервера» в соответствующие таблицы, идентифицирующие компьютер / установку, откуда поступают данные, и убедитесь, что этоПоле уникально для всех ваших установок.Каждая система / производитель / и т. Д., Которые необходимо синхронизировать между несколькими базами данных, будет иметь составной первичный ключ, состоящий из идентификатора сервера и автоматически увеличиваемого значения (хотя, вероятно, вам потребуется отдельный генератор для локального создания автоматического увеличения).Таким образом, «Casio Watch» будет иметь идентификатор сервера 1 и автоматически увеличенное значение 94. «Commodore Calculator» будет иметь то же значение автоматического увеличения, но его идентификатор сервера будет другим, поэтому конфликт не возникнет.

Другой вариант - использовать универсальный уникальный идентификатор (UUID) вместо простого поля автоматического увеличения.UUID гарантированно будут уникальными во всех установках mysql (есть некоторые ограничения).В mysql вы можете использовать функцию uuid () для генерации uuid.

В представлении проектирования системы UUID проще, потому что mysql гарантирует его уникальность в определенных ограничениях, которые описаны в приведенной выше ссылке,Однако UUID требуют больше места для хранения и будут иметь негативное влияние на производительность innodb .

...