я должен поместить ничего в мою таблицу поиска?

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

Реальный сценарий:

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

У нас есть таблица рецептов, в которой хранятся значения DrugId, OrderId (FK), частота, дозировка и т. д., которые в настоящее время не могут быть обнулены.

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

Одна из идей состоит в том, чтобы добавить «Нет» как часть справочной таблицы «Лекарства», которая формирует основу для этого вопроса. Я беспокоюсь о таком подходе по нескольким причинам:

  • кажется, что в каждом сценарии, когда мы хотим использовать данные, мы очень помним об этом (с парой незначительных исключений, поскольку это внутреннее соединение в сторонней базе данных).
  • Это кажется очень неочевидным для всех, кто присоединяется к проекту (не говоря уже о занозе в заднице), и должно быть однозначно протестировано. Может быть, делать это только с «Нет» не так уж и плохо, но как насчет того, чтобы добавить в микс «Отклонено» или «Не знаю»? Теперь в нашей справочной таблице есть 3 неочевидных исключения, которые должны учитываться КАЖДЫЙ РАЗ, когда осуществляется доступ к данным.
  • Либо мы делаем текущие обязательные поля обнуляемыми, либо вставляем в них фиктивные данные.

Другие идеи для решения этого сценария:

  • добавить в заказ новый столбец с такими параметрами, как «есть рецепты», «отклонено», «нет рецептов». Это нежелательно, поскольку десятки тысяч строк будут «пустыми», но в остальном это не так уж плохо.

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

Мысли сообщества SO?


person emragins    schedule 23.08.2012    source источник
comment
Лучший ответ выбран на основе полезности для достижения окончательного решения. В итоге я поместил код (не внешний ключ) в таблицу «Заказы», ​​который будет предоставлять такую ​​​​информацию, как отсутствие ответа, наличие, отсутствие и т. д. В итоге это работало довольно легко с кодом проверки, а также с предварительно заполненными параметрами переключателя.   -  person emragins    schedule 07.09.2012


Ответы (2)


Вы можете добавить два поля для заказа

LookupValueID NULL FK,
PrescriptionType tinyint

С PrescriptionType = (Present = 1, Null = 2, Declined = 3, DontKnow = 4, ...)

И добавьте ограничение CHECK:

(PrescriptionType = 1 AND LookupValueID IS NOT NULL)
OR (PrescriptionType <> 1 AND LookupValueID IS NULL)

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

person usr    schedule 23.08.2012
comment
Это звучит как первое из других решений, которые я упомянул (неплохая вещь). Я думаю, что, возможно, есть некоторая путаница, поскольку таблица OrderPrescription является таблицей "один-много", и она, в свою очередь, содержит идентификатор искомого значения (DrugId .) Идея иметь возможность ограничивать данные хороша, и я не рассматривал ее как преимущество этого маршрута. (Вы правы, моя исходная таблица Orders) - person emragins; 23.08.2012

Разве вы не должны просто делать что-то подобное?

введите здесь описание изображения

(Возможно, с триггером, который гарантирует, что неудавшийся заказ не может иметь рецептов.)

Или вам действительно нужно иметь отдельную причину отказа для каждого из предписаний?

person Branko Dimitrijevic    schedule 24.08.2012