Хранение номеров составных продуктов

Question

Я проектирую лабораторную базу данных. Несколько продуктов, образцов и т. Д. Идентифицируются составным числом с несколькими частями, которые указывают разные значения, такие как: происхождение, дата, тип, идентификатор сегодня и т. Д. Примеры составных номеров могут включать номер водительского удостоверения (X44-555-3434) , номер лота (XBR-A26-500-2).

Как составные числа должны храниться в базе данных? Должны ли они храниться в виде строки или каждый компонент составного числа должен храниться (или выводиться) отдельно?

ПРИМЕЧАНИЕ. Используйте Oracle, если на вопрос невозможно ответить вообще.

Answer 1

По моему опыту, если есть элементы строки, которые имеют значение, лучше поместить их в свое поле. Гимнастика, через которую мы проходим, пытаясь выявить значение, сложна и подвержена ошибкам; также легче проводить проверку данных, когда мы имеем дело с каждым полем явно. Составную строку легко построить, ее можно легко найти по созданной строке (хотя иногда ее трудно проиндексировать). Мелкозернистое хранилище всегда работало лучше для меня.

Answer 2

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

Answer 3

Может ли произойти изменение этих чисел и как это повлияет на приложение?

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

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

Если бы вы просто интересовались регистрационными номерами, то вам лучше было бы хранить регистрационные номера как одно значение. Однако приложение, ответственное за выдачу номеров, вероятно, нуждалось в том, чтобы они были разбиты на составляющие.

Answer 4

Я бы хранил каждую кодированную часть составного числа отдельно, возможно, в качестве фактического значения, которое должен представлять код (т.е. вместо того, чтобы хранить «XBR» в хранилище «12 января 2007 года» как метку времени). Но это будет зависеть от того, ожидаете ли вы искать элементы по кодированным составным числам чаще или от их фактической семантики.

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

Answer 5

Кроме того, если вы решили хранить их в отдельных столбцах, было бы неплохо создать из них уникальный ключ (уникальный ключ, содержащий все столбцы).