Идентификаторы базы данных по умолчанию; системные и пользовательские значения

Question

В рамках нашей текущей работы с базами данных мы рассматриваем процесс обновления баз данных.

Точка, которая поднималась периодически, - это отношение к системным или пользовательским ценностям; В нашем проекте пользовательские и системные значения хранятся вместе. Например ...

У нас есть список шаблонов.

1, <system template>

2, <system template>

3, <system template>

Они отображаются в приложении на enum (1, 2, 3)

Затем приходит пользователь и добавляет ...

4, <user template>

... и ...

5, <user template>

Тогда .. мы выпускаем обновление .. и вставляем как часть наших скриптов обновления ...

<new id> [6], <new system template>

ТО !! ... мы находим ошибку в новом системном шаблоне и нужно ее обновить ... Проблема в том, как? Мы не можем обновить запись, используя ID6 (поскольку мы могли вставить ее как 9 или 999, поэтому мы должны идентифицировать запись, используя какой-то другой механизм)

Итак, мы пришли к двум возможным решениям для этого.

В красном углу (скорость) ....

Мы просто запускаем идентификаторы пользователей с 5000 (или с другим значением) и тестируем данные с 10000 (или с другим значением). Это позволило бы нам вносить изменения в системные значения и проверять их до нижнего предела следующего диапазона идентификаторов.

Преимущество ... Быстрый и простой в реализации,

Недостаток ... может закончиться, если мы не выберем достаточно большой диапазон!

В синем углу (масштабируемость) ...

Мы храним, системные и пользовательские данные отдельно, используем идентификаторы GUID в качестве идентификаторов и объединяем два списка, используя представление.

Преимущество ... Масштабируемое ... Нет ограничений по размеру БД.

Недостаток. Сложнее в реализации. (многократные обновляемые представления и т. д.)

---

Я пухленько для первого варианта, но ищу боеприпасы, чтобы поддержать меня!

Есть ли у кого-нибудь какие-либо мысли по поводу этих подходов или хотя бы те, которые мы пропустили?

Answer 1

У меня никогда не было проблем (с производительностью или разработкой - включая TDD и модульное тестирование) с использованием GUID в качестве идентификатора для моих баз данных, и я работал над некоторыми довольно большими. Посмотрите здесь , здесь и здесь , если вы хотите узнать больше об использовании GUID (и возможного задействованного GOTCHAS) в качестве ваших первичных ключей - но я Я не могу рекомендовать это достаточно высоко, поскольку безопасное перемещение данных и синхронизация БД становятся такими же простыми, как чистка зубов утром: -)

На ваш вопрос выше я бы порекомендовал третий столбец (если это возможно), который указывает, является ли шаблон пользовательским или системным, или вы можете по крайней мере генерировать GUID для системных шаблонов по мере их вставки и сохранения список из них под рукой, так что если вам нужно обновить шаблон, вы можете просто указать тот же GUID в ваших базах данных DEV, UAT и / или PRODUCTION, не опасаясь перезаписи других шаблонов. Третий столбец пригодился бы для выбора всех системных или пользовательских шаблонов по желанию, без необходимости разделять их на две таблицы (это ИМХО излишне).

Надеюсь, это поможет,

Роб Г

Answer 2

+ 1 для идентификатора на основе текста Бири - определите столбец на основе текста template_mnemonic и сделайте его первичным ключом. Это будет известное значение, когда вы вставите его как вы, разработчики примут решение (или автоматически сгенерируют его), и вы всегда сможете ссылаться на шаблон по его мнемонике независимо от того, сколько шаблонов указано пользователем. Это также позволяет пользователям иметь осмысленное соглашение об именах для своих шаблонов.

Answer 3

Рекомендую использовать второе с модификацией, чтобы вы хранили системные и пользовательские значения в одной таблице. Таким образом, GUID достаточно надежен.

Еще одна идея: использовать любой текстовый идентификатор (необязательный GUID), который вы задаете для системных значений и который генерируется случайной строкой или строкой, основанной на некоторой пользовательской логике пользовательских значений.

Другая идея: использовать первый подход, но дополнить таблицу флагом, который показывает, является ли значение системным или пользовательским. Может быть, это самый простой. Хорошо, вам нужно написать какой-то механизм для обновления правильного системного значения, но это можно легко сделать.

Answer 4

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

Answer 5

Я не думаю, что GUID должен создавать какие-либо проблемы.

Если вы хотите избежать этого, используйте флаг:

ID int

шаблон любой

flag enum / int / bool

Флаг показывает, является ли фактическое значение системным или пользовательским значением.

Если вы хотите обновить системное значение, то запрашивайте только системные значения, упорядоченные по ID, и он покажет вам фактический порядок вставки (у вас должен быть bigint или что-то для ID, чтобы убедиться, что он не заполниться, и он не вернет удаленные идентификаторы к работе). С этим списком х. запись х. введенное системное значение.

Answer 6

Может быть, я не понял, но неужели вы не можете использовать GUID в качестве идентификаторов, и при этом все еще храните данные пользователя и системы вместе? Затем вы можете получить доступ к системным данным по (неизменяемым) GUID.