"사용자 표"에 사용자의 종교를 저장할 때 열을 내려다 보면 여러 번 "기독교"가 여러 번 나타나거나 "무슬림"이 여러 번 나타남 등 일반적인 형태의 오류가 있다고 생각하십니까? 어떤 형태?정상적인 형태로 간주 되나요?
내가보기 :
1NF : 더 반복 열이 없습니다.
2nf : 연결된 기본 키가 없으므로 적용되지 않습니다.
3nf : 키가 아닌 속성에 대한 종속성은 없습니다.
그러나 그것은 매우 비효율적 보인다,이 방법은 어떤 정규형 실패하지 않는 것 사용자 종교를 저장. 코멘트?
귀하의 디자인은 모든 일반 양식을 지원합니다. 속성에 문자열 값이있는 것이 좋습니다. 데이터 형식의 크기는 정규화와 관련이 없습니다.
정규화의 목표는 물리적 저장 효율성이 아니라 목표를 달성하는 것입니다. 그리고 논리적 인 효율성을 지원하기 위해, 즉 주어진 사실을 한 번만 저장하십시오. 이 경우 특정 행에있는 사용자가 기독교인이라는 사실.
이러한 방식으로 열을 저장하는 주된 단점은 행 수가 늘어남에 따라 저장 공간에 존재한다는 것입니다.
문자 열이 아니라 외래 키가있는 종교 옵션의 추가 테이블을 만드는 것을 거의 수정하지 않고 고정 된 선택 집합이있는 경우 문자 열 대신에 ENUM()을 사용할 수 있습니다. . 그러나 선택 사항이 유동적 일 경우 표준화 규칙은 사용자 테이블에 외래 키가있는 자체 테이블에 선택 항목을 배치하는 것을 선호합니다.
다른 테이블에 보관할 수있는 저장 공간 외에 다른 장점이 있습니다. 그것들을 수정하는 것은 간단합니다. Christianity에 Christian을 변경하려면, 당신이 (당신이 행을 많이 가지고 있고 종교는 인덱싱되지 않은 경우) 잠재적으로 비용을하는 것이 아니라,
UPDATE users SET religion='Christianity' WHERE religion='Christian'
을 종교 테이블에서 하나의 변화를 만들 수 있습니다 ... 당신은 할 수 있습니다 훨씬 간단하고 저렴합니다.
UPDATE religions SET name='Christianity' WHERE id=123
물론 종교 테이블을 입력하여 데이터 무결성을 강화할 수도 있습니다. 맞춤법이 틀린 Christain과 같은 잘못된 값을 삽입하는 것은 불가능합니다.
큰 통찰력, 그러나 질문은 의미합니다. 당신은 "비정규 화 된 방식"이라고 말합니다. 어떤 정상적인 형태의 실패가 여기에 적용됩니까? 1nf, 2nf 또는 3nf? – user
@ user1122200 처음 3 개의 NF 중 하나를 엄격히 위반 한 것이 아니라 비효율적으로 확장 될 것입니다. –
그것이 내가 묻고있는 것입니다. 그것은 일반적인 형태의 실패가 전혀없는 것 같습니다. 나는 스케일링에 신경 쓰지 않는다. 보통 형태에 관한 것이다. 그렇게 저장하는 것은 추악하고 비효율적 인 것처럼 보이지만 제대로 정규화 될 것입니다. – user
유효한 종교 목록이 있다고 가정합니다. 사용자가 자신의 문자열을 입력하는 경우 사용자 테이블에 저장해야하며 이는 모두 잘못된 것입니다.
종교는 자신의 테이블에 저장되어 있다고 가정합니다. 잘 정립 된 사례를 따르면,이 테이블은 정수인 기본 키를 가지며 다른 테이블 (예 : 사용자 테이블)의 테이블에있는 항목에 대한 모든 참조는 외래 키가됩니다. 종교를 저장하는 문자열 방법은 일반적인 형식을 위반하지 않지만 (종교 이름이 종교 테이블의 후보 키이므로) 문자열을 키로 사용하지 않는 방식을 위반합니다.
(이론적으로 관계형 대수학의 이론과 실습 사이에는 흥미로운 차이점이 있습니다. 이론적으로 문자열은 정수와 다르지 않으며 둘 다 원자 수학 값입니다. 실제로는 문자열에 많은 오버 헤드가 있습니다. 프로그래머가 키로 사용하지 마십시오.)
물론 가능한 값의 목록을 저장하는 다른 방법 (예 : 일부 RDBMS의 경우 ENUM)은 각각 고유 한 장단점이 있습니다.
"하지만 문자열을 키로 사용하지 않는 습관을 위반합니다."문자열은 키가 아닙니다. 이것들이 별도의 테이블로 옮겨 졌다면, 숫자 인 ReligionID를 만들 것입니다. – user
여기서 주요 요점은 효율성입니다. 추가 테이블을 추가하는 것은 여분의 조인을 의미하지만,이 전략이 여러 속성에 사용될 때는 유효하지 않습니다. 그러면 사용자에 대한 정보를 끌어 올리기 위해 여러 개의 조인이 발생할 수 있습니다. 조인이 너무 많습니다. 그리고이 방법이 정상적인 형식을 위반하지 않는다면 여분의 테이블을 추가 할 이유가 없습니다. – user
정상적인 양식은 약간 잘못되었습니다. 두 번째 정규 형식은 나머지 행이 "전체 키"에 의존한다는 것입니다. 세 번째 정규 형식은 행의 나머지 부분이 "키 이외의 것"에 의존한다는 것입니다. (그래서 나를 도와주세요.)
아니요, 귀하의 상황은 처음 세 가지 일반형을 위반하지 않습니다. (다른 요인에 따라 여섯 번째를 위반할 수도 있습니다.)
진술 된대로 정상적인 형태가 좋습니다. 귀하의 버전은 동일한 것을 다시 말합니다. "전체 키"는 연결된 기본 키의 두 부분을 모두 나타냅니다. "키 이외의 키"는 다른 키가 아닌 속성에 따라 키가 아닌 속성을 참조합니다. – user
아, 죄송합니다. 두 번째 정규 형식이 복합 기본 키를 불법화 한 것을 의미한다고 생각했습니다. 내 잘못이야. 나는 '연결된 기본 키'를 문구로들은 적이 없으므로 그 의미를 추측했습니다. –
외부 키를 사용하는 것과 비교해 볼 때이 접근 방식에는 몇 가지 단점이 있습니다. 1 - 스토리지를 낭비합니다. 2 - 종교에 의한 질의가 더 느림 3 - 누군가가 일치하지 않는 데이터를 넣을 수 있습니다. 예를 들어 수동으로 "제다이"또는 올바르지 않다고 생각되는 것을 삽입 할 수 있습니다. 4 - 가능한 종교 목록을 가질 방법이 없습니다. (예 : Zoroastrian과 같이 테이블에 특정 종교가없는 경우) 5 - 잘못된 대문자 사용으로 인해 문제가 발생할 수 있습니다. 6 - 문자열 주위에 공백이 있으면 문제가 발생할 수 있습니다.
이 기술의 주요 프로는 데이터를 빼내는 것이 더 빠르며 (테이블에 조인하지 않아도 됨) 사람이 읽을 때 더 빠릅니다.
여기에 제안 된대로 mySQL 열거 형을 사용하려고 생각했지만, 또는 SQL의 CHECK 제한 조건. 그러면 데이터 오류 (대소 문자, 철자 등)가 제거됩니다. 이 방법으로 스토리지가 낭비되고 느려질 것이라고 생각하십니까? – user
나는 그런 식으로 생각하고 싶습니다. – Taymon
이 모델에서 데이터 수정 예외가 실제로 어떤 제약 조건 (CHECK 또는 FOREIGN KEY)없이 방지됩니까? (ORM 등을 통한 클라이언트 코드 적용을 무시함) – gbn
당신이 제기하는 좋은 점입니다. CHECK는 넣을 수 있지만 데이터 수정 소스가 없습니다. 어떤 원자 데이터 값에 관해서도 같은 질문을 할 수 있습니다. 나는 데이터 수정 예외를 방지하는 것이 항상 필요하다고 생각하지 않는다. 동의하지 않으셔도됩니다. – user