많은 경우에 "없음"을 두는 것이 그렇게 나쁠 것 같지 않습니다. 그러나 조회 테이블에서 오는 데이터와 직접 관련이있는 여러 null이 아닌 필드를 포함하는 다른 테이블에서이 특정 조회 테이블 (수천 개의 행)의 값을 사용하려고합니다.내 조회 테이블에 "없음"을 입력해야합니까?
실제 시나리오는 :
조회 테이블 제네릭 이름의 목록이며, 우리의 응용 프로그램에서 별도의 다른 데이터베이스에 합류하기위한 코드가 포함되어 있습니다.
우리는 현재 DrugId, OrderId (FK), 빈도, 복용량 등을 저장하는 처방전 테이블을 보유하고 있습니다.
특정 시나리오에서는 주문 처방 정보가 필요하므로 단순히 레코드를 보유하지 않아도 문제를 해결하면 충분하지 않으며 그 이유를 알 필요가 있습니다 나중에 데이터를 검토 할 때 처방전을 입력하지 않고 정확한 이유를 다시 채울 수 있어야합니다.
하나의 아이디어는이 질문의 근거가되는 마약 조회 테이블의 일부로 "없음"을 추가하는 것입니다. 이 접근법을 여러 가지 이유로 고려할 때 걱정할 것입니다 :
- 우리는 데이터를 소비하려고 할 때처럼 보입니다. 몇 가지 예외가 있습니다. 제 3 자 데이터베이스)
- 이것은 프로젝트에 참여하는 모든 사람에게 분명하지 않은 것처럼 보입니다. (엉덩이에 통증이있는 것은 말할 것도없고) 고유하게 테스트해야합니다. 어쩌면 "None"만으로이 작업을하는 것이 그렇게 나쁘지는 않을 것입니다.하지만 "Declined"또는 "Do not Know"를 믹스에 추가하려면 어떨까요? 이제 데이터가 액세스되는 모든 단일 시간에 대해 설명해야하는 조회 테이블에 3 개의 비 명백한 예외가 있습니다.
- 현재 필요한 필드를 Null 허용 또는 가짜 데이터를 삽입합니다. 이 시나리오를 해결하기 위해
다른 아이디어가 있습니다 :
는 거절했다 ""이 처방 ","와 같은 옵션을 순서에 새 열을 추가 "아니오 처방전." 수만 행이 '널 (null)'이되기 때문에 바람직하지 않지만 그렇지 않은 경우에는 그렇게 나쁘지는 않습니다.
필드가 필요한 경우 "없음"또는 "알지 못함"과 같이 예외적 인 경우에만 기록하도록 새 테이블을 만드십시오. 이것은 현재로서는 저에게 가장 큰 호소력을 발휘합니다. 매우 명백한 예외적 인 경우가 생겨나므로 반드시 고려해야합니다. 물론 단점은 매우 적은 수의 열이있는 새로운 테이블 (1이 아닌 관계)입니다. 이것은 UI를 다시 채우기 위해 소비하는 데이터 중 가장 간단한 형태 인 것처럼 보입니다.
SO 커뮤니티에 대한 의견이 있으십니까?
(PrescriptionType = 1 AND LookupValueID IS NOT NULL)
OR (PrescriptionType <> 1 AND LookupValueID IS NULL)
그런 식으로, 당신은 일반적인 특별한 경우 인라인 상수로 :
최상의 해결책은 최종 해결책에 도달하기위한 유용성에 따라 선택됩니다. 나는 "응답 없음", "현재", "없음"등과 같은 정보를 제공하는 코드 (외래 키가 아닌)를 Orders 테이블에 넣는 것을 끝내 었습니다. 이렇게하면 validaion 코드뿐만 아니라 pre -populating 라디오 버튼 옵션. – emragins