ID базы данных по умолчанию; системные и пользовательские ценности
В рамках нашей текущей работы с базами данных мы рассматриваем процесс обновления баз данных.
Вопрос, который неоднократно поднимался, - это вопрос о соотношении системных и пользовательских ценностей; в нашем проекте пользовательские и системные значения хранятся вместе. Например...
У нас есть список шаблонов.
1, <system template>
2, <system template>
3, <system template>
Они отображаются в приложении в перечисление (1, 2, 3)
Затем входит пользователь и добавляет ...
4, <user template>
...и...
5, <user template>
Затем .. выпускаем обновление .. и вставляем как часть наших сценариев обновления ...
<new id> [6], <new system template>
ТОГДА !! ... мы обнаружили ошибку в новом шаблоне системы и нужно его обновить ... Проблема в том, как? Мы не можем обновить запись с использованием ID6 (поскольку мы могли вставить ее как 9 или 999, поэтому мы должны идентифицировать запись с помощью какого-либо другого механизма)
Итак, мы пришли к двум возможным решениям для этого.
В красном углу (скорость) ....
Мы просто запускаем идентификаторы пользователей с 5000 (или какое-то другое значение) и тестируем данные с 10000 (или какое-то другое значение). Это позволит нам вносить изменения в системные значения и тестировать их до нижнего предела следующего диапазона идентификаторов.
Преимущество ... Быстро и легко внедрить,
Недостаток ... могут закончиться значения, если мы не выберем достаточно большой диапазон!
В синем углу (масштабируемость) ...
Мы храним системные и пользовательские данные отдельно, используем идентификаторы GUID в качестве идентификаторов и объединяем два списка с помощью представления.
Преимущество ... Масштабируемость ... Нет ограничений по размеру БД.
Недостаток .. Сложнее реализовать. (многие к одному обновляемому представлению и т. д.)
Я без ума от первого варианта, но ищу боеприпасы, чтобы поддержать меня!
Есть ли у кого-нибудь мысли по поводу этих подходов или хотя бы одного (-ых), которые мы упустили?
Ответы 6
Может быть, я этого не понял, но разве вы не могли бы использовать GUID в качестве идентификаторов и при этом иметь вместе пользовательские и системные данные? Затем вы можете получить доступ к системным данным по (неизменяемым) идентификаторам GUID.
Я рекомендую использовать второй с модификацией, что вы храните системные и пользовательские значения в одной таблице. В этом смысле GUID довольно надежен.
Другая идея: используйте любой текстовый идентификатор (не обязательно GUID), который вы даете для системных значений и генерируется случайной строкой или строкой на основе какой-то настраиваемой логики для пользовательских значений.
Другая идея: используйте первый подход, но дополните таблицу флагом, который показывает, является ли значение системным или пользовательским. Может это самый простой. Хорошо, вам нужно написать какой-то механизм для обновления правильного системного значения, но это легко сделать.
Я не думаю, что GUID должен создавать какие-либо проблемы.
Если вы хотите этого избежать, используйте флаг:
ID int
template whatever
flag enum/int/bool
Флаг показывает, является ли фактическое значение системным или пользовательским.
Если вы хотите обновить системное значение, то запрашивайте только системные значения, упорядоченные по идентификатору, и он покажет вам фактический порядок вставки (у вас должен быть bigint или что-то для идентификатора, чтобы убедиться, что он не заполнится и он не возвращает удаленные идентификаторы к работе). В этом списке x. запись - это x. вставленное системное значение.
+1 для текстового идентификатора Biri - определите текстовый столбец template_mnemonic и сделайте его первичным ключом. Это будет известное значение, когда вы вставите его как вы, разработчики определят его (или автоматически сгенерируют), и вы всегда сможете ссылаться на шаблон с помощью его мнемоники, независимо от того, сколько существует пользовательских шаблонов. Это также позволяет пользователям иметь осмысленное соглашение об именах для своих шаблонов.
У меня никогда не было проблем (с производительностью или разработкой - включая TDD и модульное тестирование) с использованием GUID в качестве идентификатора для моих баз данных, и я работал над некоторыми довольно большими. Взгляните на здесь, здесь и здесь, если вы хотите узнать больше об использовании GUID (и потенциальных вовлеченных GOTCHAS) в качестве ваших первичных ключей, но я не могу рекомендовать его достаточно сильно, так как безопасное перемещение данных и синхронизация БД становится такой же простой как чистить зубы утром :-)
Для вашего вопроса выше я бы либо порекомендовал третий столбец (если возможно), который указывает, является ли шаблон пользовательским или системным, либо вы можете по крайней мере сгенерировать GUID для системных шаблонов по мере их вставки и сохранить список те, которые есть под рукой, так что если вам нужно обновить шаблон, вы можете просто настроить таргетинг на тот же GUID в своих базах данных DEV, UAT и / или PRODUCTION, не опасаясь перезаписать другие шаблоны. Третий столбец может пригодиться, хотя для выбора всех системных или пользовательских шаблонов по желанию, без необходимости разделять их на две таблицы (это излишество, IMHO).
Надеюсь, это поможет,
Роб Джи
Думаю, есть третье решение получше. Мне кажется, что вы храните две разные вещи в одной таблице и что, возможно, вам лучше создать две отдельные таблицы: одну для пользовательских шаблонов, а другую - для системных шаблонов. Затем вы можете создать представление для двух таблиц, чтобы они отображались в вашем приложении как один объект. Очевидно, у меня нет полного знания о вашем приложении, и это может быть невозможно для вас по ряду причин, но я думаю, что это более аккуратное решение, чем GUID, и намного безопаснее, чем диапазоны идентификаторов (серьезно, не делайте диапазоны идентификаторов, это будет кусаю тебя однажды)