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

Question

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

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

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

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 в качестве идентификаторов и объединяем два списка с помощью представления.

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

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

---

Я склоняюсь к первому варианту, но ищу подкрепления!

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

Answer 1

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

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

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

Роб Джи

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

ID int

шаблон что угодно

флаг перечисления/int/bool

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

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

Answer 6

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