필드에 대해 여러 문자열을 포함하는 여러 테이블이 있습니다. 이러한 필드 중 일부는 항상 데이터를 포함 할 수도 있고 그렇지 않을 수도 있습니다. 레코드를 생성 할 때 null 인 문자열 필드가있는 레코드를 만들면 필드가 null이거나 쿼리가 빈 문자열을 반환하기 때문에 해당 레코드의 읽기 쿼리를 수행 할 때 문제가됩니까? 기반으로 간주되는 사항은 무엇입니까? nullabay가 아닌 문자열 또는 null이 허용되는 문자열 및 차이점을 언제 알 수 있습니까?데이터베이스 문자열 필드 유형 : nullable 여야합니까?
의견을 보내 주셔서 감사합니다.
쿼리는 데이터베이스에 저장된 문자열이면 빈 문자열을 반환하고 null이 포함 된 null 허용 문자열이면 null 값 (System.DBNull)을 반환합니다.
그러나 결정은 쿼리 기능이 아닌 모델링하는 데이터를 기반으로해야합니다.
DB에서 Null은 일반적으로 값이 알 수 없거나 비어 있음을 의미합니다. 이것은 값이 없음을 의미하는 빈 문자열과 구별 될 수 있습니다.
예를 들어 MiddleName 필드를 가져옵니다. 중간 이름이없는 사람 (빈 문자열)과 아직 입력하지 않은 사람 (Null)을 구분할 수 있습니다. 이 경우 널값 문자열 필드가 필요합니다.
그것은 수백만 번 이상 논쟁의 대상이었습니다. 내 의견으로는, NULL 값은 이유가 있기 때문에 거기에 머물러 있어야한다. (심지어 빈 문자열이라 할지라도 뭔가 의미가있다.)
NULL 값은 읽기 시간에 아무것도 변환되지 않습니다. 너는 널거야. 당신은 이것을 "이 가치가 정해지지 않았 음"으로 해석하고 그런 식으로 취급해야합니다. 그것을 임의의 마술 값 (예 : 빈 문자열)으로 바꾸면, 문제를 찾는 것입니다. 마술 값이 다른 것의 의미를 가지기 시작하면 조만간 문제가되는 것을 구별 할 수 있습니다. 한번도 설정되지 않았습니다.
다른 말로하면, 속성이 (선택 사항) 인으로 간주되는 경우, 그것은 확실히 nullable이 될 수 있습니다. 자신과 함께 토론을 시작할 때마다 "선택 사항"이라는 단어를 기억하십시오. 나는 당신이 좋은 결정을 내릴 것이라고 확신합니다.
데이터베이스 관리자의 스택 교환 사이트에는 similar question이 있습니다. 그들은 여기에서 말한 것을 거의 반복합니다.
언급되지 않은 한 가지 사실은 null 값으로 실제 값을 곱하려고 시도하면 null 결과를 얻게된다는 것입니다. 다른 많은 작업과 동일합니다.