булева таблица SQL лучший подход

Я хочу, чтобы сохранить текущую ситуацию пациентабулева таблица SQL лучший подход

Вступление
In Treatment Body
Высокий медицинский

Что бы наилучший подход для хранения такая булевая таблица?

Я думал

ID_STATUS INT 
ID_PATIENT INT 
ENTRY  BOOL 
BODY_TREATMENT BOOL 
HIGH_MEDICAL BOOL

ли это хороший подход, или только таблицу, как следующее необходимо?

ID_STATUS   INT 
ID_PATIENT  INT 
CURRENT_STATUS VARCHAR

источник

2013-05-06 cMinor

Без каких-либо знаний о вашем домене ** невозможно рассказать **. AFAIK, эти таблицы несовместимы вообще: они делают совершенно разные вещи. Вы должны знать то, о чем не сказали нам. (Например, что делает 'CURRENT_STATUS'?) – jpaugh

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

Являются ли эти статусы _exclusive_? –

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

Булевы столбцы представляют собой запах кода. Флаги, подобные этому, часто могут быть реорганизованы в лучшие реляционные структуры. В вашем случае было бы смысл, если бы два статуса были истинными одновременно?

источник

2013-05-06 17:13:53

ANSI SQL *** *** определяет логический тип данных. И я не уверен, что они «запах кода». Как насчет флага 'active'? Это вполне допустимый прецедент для булевского столбца. Но я согласен с тем, что статус лучше помещается в таблицу поиска с ограничением внешнего ключа. –

Да, я дернул эту часть, прежде чем я даже увидел ваш хороший комментарий. Я вижу, что boolean был добавлен в SQL: 1999 как необязательный (и нулевой) тип. Тем не менее, я согласен с Celko на booleans, и я не могу сказать, сколько раз я спрашивал другого разработчика: «Что означает этот пустой флаг?» и получил пустой взгляд. Или видели, как их злоупотребляют так, как это предлагает ОП. Активные флаги для мягких удалений часто могут быть лучше реализованы как datetime, если они _truly_ необходимы (и не имеют других возможных статусов), хотя я не считаю их отличным методом для архивирования. –

Я вижу 'bit' [устарела] (http://books.google.com/books?id=W2Yi4TQaAjwC&pg=PA228&lpg=PA228&dq=celko+boolean&source=bl&ots=sH6MtlQLJg&sig=7PV-BL2IL7FHrOJDggMrykAbkfg&hl=en&sa=X&ei=A-eHUcnILcWs4AOf7oCQDQ&ved = 0CEQQ6AEwAg # v = onepage & q = celko% 20boolean & f = false) в SQL: 2003. –

Если вы не заботитесь о том, когда одна ситуации останавливается, а следующий начинается, все, что вам нужно:

id_patient 
id_situation

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

источник

2013-05-06 17:14:36

булева таблица SQL лучший подход

ответ

Смежные вопросы