Должен ли я использовать код в моей таблице поиска

Question

Я просыпаюсь в базе данных Orable и добавляю пару таблиц поиска.

Общий вопрос: должна ли таблица поиска содержать код и описание, а код должен быть FK обратно к основномутаблица, или если таблица поиска содержит только описание, и это FK обратно к основной таблице.

Я спорю по паре код / ​​описание.Я чувствую, что если у меня есть type = Contractor и code = CN сохраненный процесс должен сказать where type='CN', а не только type=Contractor и без кода и сказать это в хранимом процессе: where type='Contractor' Потому что, что если я хочу отобразить: General Contractor пользователю, а не Contractor.Я тогда должен был бы изменить сохраненный процесс.Я чувствую, что не должен был этого делать.(изменение сохраненного процесса требует перекомпиляции в dev, переноса для тестирования, повторного тестирования клиентами и переноса продукта, который требует прохождения процесса управления изменениями, который включает двухнедельный период ожидания; тогда как изменение записи в таблице не требует каких-либоиз этого)

Мой разработчик данных хочет использовать только описание.Его главный аргумент заключается в том, что для этого потребуется необязательное соединение.

Каким образом это должно быть сделано?И если нужно сделать код / ​​описание так, как мне убедить разработчика данных?

Спасибо!

type_cd    type_dsc
CN         Contractor
IN         Inspector

Answer 1

Суммируя все ответы, я думаю, что есть четыре варианта для таблицы поиска:

Альтернатива 1:
• Описание (первичный ключ, более длинный столбец varchar2)

Альтернатива 2:
• Код (первичный ключ, короткий столбец varchar2)
• Описание (не ноль, более длинный столбец varchar2)

Альтернатива 3:
• Id (бессмысленный первичный ключ, целочисленное значение, полученное из последовательности)
• Описание (не ноль, более длинный столбец varchar2)

Альтернатива 4:
• Id (бессмысленный первичный ключ, целочисленное значение, полученное из последовательности)
• Код (уникальный ключ, короткий столбец varchar2)
• Описание (не ноль, более длинный столбец varchar2)

Столбец первичного ключа будет находиться в главной таблице с ограничением внешнего ключа сверху.

Некоторые характеристики для альтернативы:

Альтернатива 1:
• При запросе к основному столу объединение не требуется
• Понятное значение при выполнении специальных запросов в основной таблице
• Требуется больше места для основного стола
• Индекс на основном столе будет намного больше, чем в других альтернативах
• Обновление значения Description означает проблемы с обслуживанием и, возможно, время простоя приложения.

Альтернатива 2:
• Присоединение требуется, если вы хотите получить значение описания
• Регистрация не требуется, если вы хотите фильтровать определенные значения поиска: для этого вы можете использовать значение кода.
• Довольно ясный смысл при выполнении специальных запросов к основной таблице
• Минимальные дополнительные требования к хранилищу для основного стола
• Индекс на основном столе будет небольшим.
• Обновление значения Description легко, однако код обычно является аббревиатурой от описания. При обновлении значения Description код может запутаться.

Альтернатива 3:
• Присоединение требуется, если вы хотите получить значение описания
• При фильтрации определенных значений поиска вам придется использовать значения Description в ваших запросах, так как идентификаторы не имеют смысла.
• Значение неясно при выполнении специальных запросов к основной таблице
• Минимальные дополнительные требования к хранилищу для основного стола
• Индекс на основном столе будет небольшим.
• Обновление значения Description легко и не вызывает путаницы, как со значениями Code

Альтернатива 4:
• Присоединение требуется, если вы хотите получить значение описания
• Объединение требуется при фильтрации по определенным значениям поиска, вы должны использовать значение кода в таблице поиска.
• Значение неясно при выполнении специальных запросов к основной таблице
• Минимальные дополнительные требования к хранилищу для основного стола
• Индекс на основном столе будет небольшим
• Обновление значения «Описание» легко, и вы также можете очень легко обновить значение «Код», чтобы оно напоминало значение «Описание». При этом вам, возможно, придется пересмотреть часть своего кода.

Личное мнение:

Я бы посмотрел, как планирую использовать основную таблицу и справочную таблицу. Какие запросы будут важны и должны работать эффективно? Будут ли значения когда-либо меняться?

Мой личный выбор - альтернатива 2 или 4. Я бы использовал альтернативу 2, если бы был абсолютно уверен, что значение кода никогда не изменится. И это редко. Меняются коды стран, меняются номера социального страхования. Коды валют меняются и так далее. Таким образом, большую часть времени я бы выбрал альтернативу 4. Меня бы не волновало дополнительное объединение, особенно потому, что таблица поиска - это маленькая таблица.

Но: выберите альтернативу, которая соответствует вашим требованиям.

Пожалуйста, не стесняйтесь редактировать текст, если вам известны некоторые дополнительные характеристики альтернативы.

С уважением,
Роб.

Answer 2

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

РЕДАКТИРОВАТЬ : на основеВ примере кода, который вы только что добавили, я бы посоветовал вам сделать ваше кодовое значение целочисленным, а не строкой типа 'CN', 'IN'.Вы хотите, чтобы значение вашего ключа было независимым от любого «значения», связанного с описанием.«CN» по-прежнему подразумевает «Подрядчик», и если / когда это описание изменится на «Внешний ресурс», то «CN» будет вводить в заблуждение.

Answer 3

Существуют стандарты и схемы кодирования для многих вещей, которые были придуманы людьми, которые умнее меня и имели гораздо больше времени, чтобы подумать об этом.Например, стандарт ISO охватывает половые коды (ISO 5218), коды стран (ISO 3166), языковые коды (ISO 639), коды валют (ISO 4217) и так далее.В прошлом году я купил Данные, измерения и стандарты Джо Селко в SQL , и меня по-настоящему удивило количество официально поддерживаемых готовых стандартов и схем кодирования.

Хорошо, хорошоИтак, иногда какая-то страна отказывается от своих бананов в пользу EUR / USD, и теперь вам приходится переписывать всю заявку?Нет, вам придется потратить несколько часов на написание сценария для объединения / разделения любых кодов, которые были изменены.Большое делоПочему бы вам не исправить несколько ошибок во время того же выпуска, пока вы работаете над этим?

Лично я использую короткие коды символов почти для всего, против чего приходится писать код, или когда мне нужно назначить поведениев зависимости от некоторого «кода типа».Код так тесно связан с тип-кодом, так зачем делать его сложнее, чем нужно?Полученный код легче читать, и он выполняется быстрее, потому что мне нужно меньше соединений.Для всего остального (в основном для всех пользовательских) я использую целочисленные суррогаты.

Я «только» работал с базами данных в течение 11 лет, но я не видел много случаев, когда «имя менялось» настолько значительно, что код вводил в заблуждение.Код типа «подрядчик» не может быть изменен на «менеджер по персоналу» или «вице-президент».Это новый код.Он может быть разделен на «внутренний / внешний ресурс», но для этого также потребуются изменения кода, и в этом случае я не вижу проблемы с добавлением нескольких часов преобразования данных в бюджет проекта?

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

Я видел все следующее:

where type = 1 /* contractor */ 
  vs

int type_code = configfile.lookup("sqlcodes.contractor");
...
where type = :type_code
  vs

 from sometable
 join contract_types using(type_id)
where contract_types.type_name = 'Contractor';

... ноЯ до сих пор не вижу преимущества над просто:

where type = 'CN'

Я пытаюсь подчеркнуть следующее: когда мы тратим 80 часов на разработку, как, черт возьми, 4 часа работы с базами данных НЕ вписываются вбюджет проекта?

Answer 4

Ну, это будет зависеть от того, насколько «стандартными» являются эти коды.

Рассмотрим таблицу поиска, подобную этой:

Code  Description
------------------
USD   United States Dollar
GBP   Pound Sterling
AUD   Australian Dollar
EUR   Euro

Для этого я бы использовал char(3) дляCode и сделайте его первичным ключом.Ваши коды кажутся char (2) - аккуратными, маленькими;меньше, чем целое число.

Так что я бы предположил, что Code будет использоваться в качестве PK в таблице поиска, а "главная таблица" будет иметь Code в качестве FK для таблицы поиска.

А если ваши коды не очень стандартные и могут быть изменены, предпочтение отдается целому числу.

Answer 5

Используйте мнемонику (например, CN для Подрядчика и т. Д.), Которая никогда не изменяется. Пусть пользовательский интерфейс покажет описание. Небольшая кодовая таблица, вероятно, поместится в один или два блока и, следовательно, обычно находится в кеше, поэтому поиск будет дешевым.

Самое главное, будущие разработчики и люди (такие как я), которые придут позже и должны будут сопоставить эти данные с другими системами, будут вам благодарны, потому что это означает, что в 80% случаев вы можете просто запрашивать таблицу и понимать ее интуитивно.

Когда я вижу такой стол, я просто хочу кричать:

ADDRESS_ID
HOUSE_NUMBER
STREET_NAME
STREET_TYPE_ID
LOCALITY_ID

SELECT * FROM addresses WHERE street_type_id = 10053;

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

Answer 6

использовать числовое значение идентификатора и описание. Сохраните идентификатор в основной таблице как FK.

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

Answer 7

внешний вид, в зависимости от распределения ключей - для большинства небольших таблиц поиска любые присоединяющиеся к нему запросы будут в любом случае выполнять полное сканирование таблицы по поиску и хэш-соединению ключа - так что числовые и символьные символы, вероятно, не являются проблемой для выполнения объединения.

Вопрос на самом деле - вам нужно объединение?

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

Если, с другой стороны, вы используете файлы ресурсов для многоязычного приложения и используете возвращенный код в качестве поиска, И это небольшой набор кодов, который не должен изменяться (Gender_Code = 'M' ale или 'F'emale или' U'nknown, например) - затем сделайте коды осмысленными, используйте проверочное ограничение на поле для управления значениями, и даже не заморачивайтесь с таблицей поиска, потому что вы знаете их по коду и пользовательский интерфейс выяснит, как их отображать.

Answer 8

Я предлагаю использовать int ID и описание char / varchar.

Используйте идентификатор в своих запросах и используйте ссылку на описание только тогда, когда вам нужно отобразить описание.

Не беспокойтесь, ID не будет выглядеть как описание. Это способ, которым он должен работать. Вам нужен незначительный идентификатор, чтобы никто не угадал значение «CH» или «EX» и т. Д. Добавьте комментарии к коду, поясняющие, что должен означать этот идентификатор.

Вы хотите иметь возможность изменить описание в любое время, не нарушая свой код. Вы НЕ хотите исправлять все коды при их изменении.

Кроме того, вы можете добавить одну или несколько групп в таблицу описаний. Если у вас есть несколько типов подрядчиков, вы можете добавить столбец группы, который указывает тип. Затем вы можете связаться с таблицей описания группы и вернуть все строки, где группа является Подрядчиком. Конечно, эта группа должна иметь таблицу поиска с идентификатором и описанием, чтобы вы могли изменять отображаемые имена групп поиска.

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