데이터베이스 정규화가 종료 되었습니까? [닫은]

나는 구식 학교를 열었습니다. 응용 프로그램의 비즈니스 계층 이전에 데이터베이스 스키마를 설계하는 법을 배웠습니다 (또는 다른 모든 것에 OOAD 사용). 나는 스키마 (IMHO :)를 디자인하는 데 꽤 능숙했으며 불필요한 중복성을 제거하기 위해 정규화되었지만 속도에 영향을 미치는 곳은 아닙니다. 그러나 대부분 그렇지 않았습니다.

Ruby의 ActiveRecord 또는 ActiveJDBC와 같은 일부 ORM 프레임 워크의 출현으로 (기억할 수는 없지만 몇 가지가 있습니다.) 일부 키가있는 경우에도 모든 테이블에 대리 키를 선호하는 것 같습니다 '이메일'-2NF를 완전히 깨뜨 렸습니다. 좋아, 나는 너무 많이 이해하지는 않지만, 이러한 ORM (또는 프로그래머) 중 일부가 1-1 또는 1-0 | 1 (즉, 1에서 0 또는 1)을 인정하지 않으면 내 신경에 거의 도달합니다. 그들은 nulls "오늘날 시스템이 처리 할 수 있는 " 톤이 많은 경우에 상관없이 모든 것을 하나의 큰 테이블로 갖는 것이 더 좋다고 규정하고 있습니다 .

나는 메모리 제약이 정규화와 직접적인 상관 관계가 있음에 동의하지만 (다른 이점도 있습니다 :) 오늘날 저렴한 메모리와 쿼드 코어 머신을 사용하는 시대에는 DB 정규화의 개념이 텍스트에 그대로 남아 있습니까? DBA로서 여전히 3NF (BCNF가 아닌 경우)로 정규화를 수행합니까? 상관이 있나? "더티 스키마"디자인은 프로덕션 시스템에 적합합니까? 만약 그것이 여전히 관련이 있다면 어떻게 "for"정규화를해야 하는가.

( 참고 : 디자인의 일부 / 필요로 중복성을 갖는 데이터웨어 하우스의 스타 / 스노 플레이크 스키마가 아니라 StackExchange와 같은 백엔드 데이터베이스가있는 상용 시스템에 대해 이야기하고 있지 않습니다)

정규화의 한 가지 이유는 데이터 수정 예외를 제거
하는 것입니다. ORM은 일반적으로이를 지원하지 않습니다.

이 원칙을 위반하는 최대 절전 모드 설계 데이터베이스의 많은 예가 있습니다.

• bloated (1 억 줄 이상 반복되는 문자열)
• 조회 테이블 없음 (위 참조)
• DRI 없음 (제약, 키)
• varchar 클러스터형 인덱스
• 불필요한 연결 테이블 (예 : nullable FK 열로 충분할 경우 1..0 : 1 시행)

내가 본 최악은 1TB MySQL 데이터베이스로 인해 아마도 75-80 %가 너무 컸습니다.

또한 "오늘날 시스템에서 처리 할 수있다"는 진술은 대부분의 미키 마우스 시스템에 해당된다고 제안합니다. 확장해도 오늘날의 시스템은 그렇지 않습니다.

위의 예에서 키를 리팩터링하거나 변경하거나 데이터를 수정하는 견인력이 없었습니다. 데이터베이스 증가율과 그 위에 의미있는 DW를 구축 할 수 없다는 점에 대해서만 불평하십시오.

일부는 '이메일'과 같은 기본 키가 있어도 모든 테이블에 대해 대리 키를 선호합니다.

대리 키는 2NF를 깨뜨리지 않습니다. 2NF는 "열이 다중 값 키의 일부에만 의존하는 경우 해당 열을 별도의 테이블로 제거하십시오"라고 말합니다.

그들은 널이 널이 있더라도 모든 것을 하나의 큰 테이블로 갖는 것이 더 낫다고 규정합니다.

정규화 규칙을 따르는 한 한 테이블에 여러 열이있는 것이 유효합니다. SQL 및 정규화의 이점을 활용하려는 경우 분석없이 테이블을 병합하는 것은 올바르지 않습니다.

나는 메모리 제약이 정규화와 직접적인 상관 관계를 가지고 있음에 동의합니다. Relation Normal Forms는 수학적 개념이며 메모리와 관련이 없습니다.

정규화는 메모리 나 디스크를 저장할뿐만 아니라 무결성을 추가하기위한 것입니다. 결국 하드웨어와 무관 한 수학적 개념입니다.

간단한 예 : 학교 정보를 다음과 같이 유지한다고 가정하십시오.

Rec 1 : 미국 캘리포니아 주 노스 리지 고등학교

Rec 2 : 사우스 토론토 브레이브스 고등학교, 온타리오, 캐나다

시스템이 온타리오 (Ontario) 어디에 있는지 물어 보면 캐나다에 있다는 것을 알 수 있습니다. 며칠 후 두 번째 행을 삭제하고 시스템에 동일한 질문을하면 아무 것도 얻지 못합니다. 이 예에서는 디스크 공간이나 메모리 또는 CPU의 양이 중요하지 않으면 답을 얻지 못합니다.

이것은 하나의 비정상 정규화 관계가 방지하는 데 도움이됩니다.

편집 : 아래 의견에 따라 토론토 단어를 온타리오로 변경했습니다.

더 많은 것들이 변할수록 더 똑같이 유지됩니다. 모퉁이를 자르거나 모범 사례를 모르거나 따르기를 원하지 않는 게으른 개발자가 항상있었습니다. 더 작은 응용 프로그램에서 많은 시간을 할애 할 수 있습니다.

COBOL에서 영감을 얻은 데이터 구조를 초기 RDBMS 또는 dBase였던 신의 엉망으로 만들었습니다. 이제는 ORM과 "코드 우선"입니다. 결국, 이것들은 모두 사람들이 당신이 원하는 것과해야 할 일에 대해 열심히 생각하는 시간을 허비하지 않고 작업 시스템을 얻는 데 도움이되는 은총을 찾는 유일한 방법입니다. 서두르는 것은 항상 문제였으며 항상 문제가 될 것입니다.

올바른 디자인을하기 위해 시간을 내야하는 좋은 감각과 행운을 가진 사람들에게는 데이터 모델이 항상 가장 논리적 인 출발점이 될 것입니다. 데이터베이스에 들어가는 것은 비즈니스가 관심을 갖는 것들 (유형 및 무형)에 대한 정보입니다. 무엇 훨씬 빠르게 이상의 변경 사항에 대한 귀하의 비즈니스 염려 하는 방법 당신의 사업이 운영하고 있습니다. 이것이 데이터베이스가 일반적으로 코드보다 훨씬 안정적인 이유입니다.

데이터베이스는 모든 시스템의 올바른 토대이며, 토대를 올바르게 배치하는 데 시간이 걸리면 장기적으로 혜택을 누릴 수 있습니다. 즉, 정규화는 모든 OLTP 유형 응용 프로그램에서 항상 중요하고 유용한 단계입니다.

메모리 제약이 정규화와 직접적인 상관 관계가 있음에 동의합니다 ...

메모리 제약은 여전히 ​​중요합니다. 수량은 문제가 아니며 속도는 문제입니다.

• CPU는 현재 더 빨라지지 않습니다 (초당 사이클이 아닌 더 많은 코어를 얻습니다)
• 최신 CPU 아키텍처는 각 프로세서 ( NUMA )에 별도의 메모리를 제공하여 속도 제한을 극복하려고합니다 .
• 온다이 캐시 크기는 기본 메모리와 비슷한 속도로 증가하지 않습니다.
• 메모리 처리량은 대부분의 사람들이 기대하는만큼 높지 않습니다. QPI 는 초당 25GB입니다.

이 근거 중 일부는 TIINTINT를 INT보다 언제 사용합니까? 유용하다고 생각 될 수도 있습니다. 또한 SQLCAT 팀 의 @ThomasKejser ( 블로그 ) 의 데이터베이스를 따르는 것이 좋습니다 . 데이터베이스 성능 향상의 날카로운 가장자리에 있기 때문입니다. CPU 캐시 및 메모리 액세스 패턴의 영향 에 대한 최근 게시물 과 Extreme DW Scale의 관계형 모델링에 대한 SQLBits 프레젠테이션 이 좋은 예입니다.

제 생각에는 여전히 정규화와 비정규 화 사이의 균형에 관한 것 입니다. 나는 ORM 프레임 워크가 단지 작업을 수행하는 접근 방식이라는 것에 전적으로 동의하지만, 이것이 비정규 화 추세를 야기하는 프레임 워크라고 생각하지 않습니다 .

그것은 여전히 ​​당신이 시간 효율성을 원하거나 공간 효율성을 원한다는 논쟁입니다. 관계형 데이터베이스 이론이 등장했을 때 디스크 스토리지는 비싸고 사람들은 분명히 이것에 많은 돈을 쓰고 싶지 않기 때문에 그 당시 관계형 데이터베이스는 역경 속에서 확고한 사람입니다

요즘에는 상황이 상당히 다르고 스토리지는 매우 저렴합니다. 따라서 우리는 예전보다 더 많은 중복성을 견딜 수 있습니다. 이것이 BIG_TABLE 접근법이 나타난 이유이기도합니다. 더 많은 시간 효율성을 추구하기 위해서는 공간 효율성이 희생되어야합니다.

그러나 빅 테이블 접근 방식은 이야기의 끝이 아니며 관리 할 PB 볼륨 데이터 측면에서 여전히 시간과 공간의 균형입니다. 일부 개발자는 공간 효율성으로 균형을 찾기 시작했습니다. 구조와 같은 BIG-TABLE에서 일부 데이터를 정규화하기 위해 수행되는 작업입니다.

한마디로, 정규화 접근법은 확실히 죽지 않았지만 이전과 비교할 때 분명히 간과됩니다.

CJ Date는 귀하의 질문에 대답합니다-정규화 (예비) 비디오는 무료입니다.

http://shop.oreilly.com/product/0636920025900.do

짧은 대답 : 정규화는 수학적으로 올바른 일을하는 방법입니다. 제대로 정규화하지 않으면 데이터 모델이 잘못되었습니다.