Для будущего проекта нам нужны уникальные идентификаторы реального мира, которые предоставляются пользователям для таких вещей, как номера счетов или номера дел (например, идентификатор отслеживания ошибок). Они всегда будут генерироваться системой и не будут изменены. Прямо сейчас мы планируем работать строго на Heroku.
Хотя (как подсказывает мое имя) я новичок в этой замечательной возможности Ruby on Rails, но у меня большой опыт разработки корпоративных приложений. Я пытаюсь соединить то, что я делал в прошлом, когда делал «путь RoR»
Очевидно, что RoR имеет замечательную поддержку первичного ключа. Я прочитал десятки постов здесь, рекомендующих адаптировать бизнес-требования, чтобы просто использовать готовую методологию id / key.
Итак, позвольте мне описать то, что я пытаюсь достичь, и, пожалуйста, дайте мне знать, если вы столкнулись с подобными целями и какой подход вы выбрали.
1) Хотелось бы иметь удобный для чтения ключ с одинаковой длиной. Всегда важно иметь идентификатор учетной записи или идентификатора транзакции одинаковой длины (для проверки формы, обучения торгового персонала и т. Д.). С помощью встроенного в Ruby генерирования ключей можно просто добавить буферные символы (например, 100000 вместо 1).
2) Компактность: мой первоначальный план состоял в том, чтобы использовать базовый 36 уникальный ключ (например, 36 значений [0..9], [a..z]). В рамках нашего API / интерфейса мы планируем предоставлять некоторые неконфиденциальные объекты на основе короткого URL-адреса (например, xx.co/000001). Мне нравится идея иметь возможность иметь пятизначный идентификатор в базе 36 против 7+ в десятичной.
Так что я могу придумать два возможных подхода:
а) добавить свое поле и разработать собственный генератор ключей (или, может быть, кто-то укажет мне на него).
b) Начальные цифры пэда (и я предполагаю, что могу заставить генерацию уникального ключа начать с 1xxxxxxx, а не 0000001). Затем используйте метод to_s (36), чтобы преобразовать его в базу 36 и обратно для всех взаимодействий с людьми. Возможно, даже сохраните фактическое значение идентификатора в базе данных в формате base 36, чтобы избежать текущих преобразований, но всегда выполняйте преобразование перед запросом, чтобы избежать необходимости иметь другой индекс.
Я склоняюсь к подходу B, так как кажется, что он будет оптимальным с точки зрения производительности БД и что он потребует наименьших вложений в дополнительные издержки без добавленной стоимости. Еще раз, любой практический опыт с этими темами и мыслями о лучшем подходе был бы очень признателен.
Заранее спасибо!