앱용 데이터베이스를 설정하는 더 좋은 방법은 무엇입니까? 표준화와 실제 비교

Question

데이터베이스 백업 응용 프로그램의 경우이 설정을 고려하십시오. (제 경우에는 DB가 MySQL이고 앱이 Ruby (Rails 3)에 있지만이 질문에 대해 중요하지 않다고 생각합니다)

웨어 하우스 용 앱이 있다고 가정 해 봅니다.

카테고리와 상태가있는 항목이 여러 개 있습니다. 몇 가지 상태를했을 부분이 예를 들어 테이블에 대한

같은 : 재고, 같은 단종, 이월 및 여러 범주 : 등이 하드웨어, 자동차, 의료,

또한 나는 다른 테이블이 그 과 같은 상태 및 범주가 필요합니다. 공급 업체 : 승인, 폐업, 신규 주문 : Open, processes, shipped, cancelled. 여기에 기타

는 질문 :

내가 제대로 내 DB를 정상화하기를 원한다면 생각 - 나는 범주, categories_types, 상태, statuses_types라는 테이블을 가질 것이다.

그런 다음 모든 테이블을 해당 테이블에 저장하고 모든 유형의 부품과 같은 특정 유형의 모든 카테고리에는 category_type에 대한 외래 키가 있습니다. 유형과 동일합니다.

이것은 정규화 된 방식입니다.

그러나 나는 사람들이 특정 카테고리에 대해 별도의 테이블을 생성하는 것을 종종 봅니다. 예를 들어 과 같이 part_categories, vendor_categories, order_statuses, part_status라는 테이블이 있습니다. 이것은 덜 정규화 된 DB이지만 많은 테이블을 처리 할 때 더 명확해질 것입니다.

어떤 접근 방식이 더 나은 방법입니까? 귀하의 경험에서 단점은 무엇입니까 & 무엇입니까? 나는 보통 첫 번째 설정과 함께 간다. 그러나 나는 두 번째 것을 자주 보며 내 접근 방식을 의심하기 시작했다.

감사합니다.

Answer 1

필자의 경험에 따르면, 열거 된 이름의 테이블은 필연적으로 결국 본격적인 모델로 진화합니다. 일반적으로 부울 플래그를 추가하거나 위의 대답에서 언급 한 것처럼 참조 유형 또는 유효한 날짜 범위를 시작합니다.

관계형 관점에서 모든 상태 열거 형을 하나의 테이블에 넣거나 별도의 테이블로 분리하는 접근 방식은 다른 것보다 "더"표준화되지 않습니다. 그러나 유형 이론적 인 관점에서 볼 때, part_categories와 vendor_categories를 별도의 테이블에 넣는 것이 더 합리적입니다. 왜냐하면 모델에 코드가 없어도 실수로 공급 업체 카테고리를 파트와 연관시키지 않아도되기 때문입니다 .

모두 동일한 테이블에 넣으면 결국 Rails에는 유형 및 ID 열을 자동으로 처리하는 다형성 연결이라는 멋진 기능이 있습니다. 두 가지 접근 방식 사이에서 합리적인 타협입니다.

가장 중요한 것은, 열거 형은 결국 자신의 모델 라이프를 취할 것이라고 주장 할 것입니다.이 경우, 다양한 테이블에서 모든 것을 찾고 자신의 테이블에 리 시드하는 매우 지저분한 작업이 있습니다. . 테이블은 싸다. 왜 그들과 검소합니까?

Answer 2

이 방법은 데이터와 상호 작용하는 방식에 달려 있다고 생각합니다. 두 번째 접근 방식의 이점은 특정 개체 (공급 업체, 품목, 주문)와 연결된 범주 및 상태를 쉽게 파악할 수 있다는 것입니다. 첫 번째 방법을 사용하는 경우 카테고리 및 상태 테이블에 유형 식별자가 있어야 행이 관련된 카테고리 또는 상태 (공급 업체, 아이템, 주문)를 식별해야합니다.

첫 번째 방법의 이점은 새로운 개체에 대한 상태와 범주를 추가하는 것이 더 쉽고 두 테이블 만 있으면 간단하다는 것입니다. 특정 카테고리 또는 상태에 추가 정보를 추가하려는 경우 문제가 발생합니다. 예를 들어 주문 동상에 effective_date가 있어야하지만 항목 동상에 effective_date가 있으면 안됩니다. 이 시점에 이르면 두 번째 방법으로 이동하거나 속성이 적용되지 않는 다른 상태에 대해 null이되는 effective_date를 추가해야합니다.

또 다른 접근법은 상태 및 카테고리 테이블을 작성하지 않고 원래 테이블에 상태 및 카테고리 값을 저장하는 것입니다. MySQL 또는 Rails에서 열거 형 (ENUM)을 사용하여이를 수행 할 수 있습니다.MySQL에서 ENUM은 데이터베이스에 정수로 저장되지만 '처리됨', '발송 됨'또는 '취소됨'과 같은 단어 값으로 해석됩니다. 이점은 상태가 자주 변경되지 않으면 할 일이 한 번 줄어들어 데이터베이스와 Ruby 모델을 더 쉽게 읽을 수 있다는 것입니다. Ruby에서 ENUM은 단순히 키 (정수)와 값 (문자열)이 연결된 상수 목록 일 수 있습니다. 정수 값을 사용하여 응용 프로그램 측면에서 데이터베이스와 단어 값을 쿼리하고 업데이트 할 수 있습니다.

두 방법 모두 합법적이라고 생각합니다. 귀하가 취하는 경로는 귀하의 필요에 따라 다릅니다. 데이터베이스에 데이터를 저장하도록 설정 한 다음 상태 및 카테고리와 상호 작용하는 방식을 분석하면 접근 방식이 다를 수 있습니다. 어떤 방법으로 더 빠르고 쉽게 쿼리 할 수 ​​있습니까? 어느 것이 더 쉽게 업데이트하거나 수정할 수 있습니까? 얼마나 자주 읽습니까? 얼마나 자주 쓰나요? 마지막으로, 당신이 민첩하다는 것을 명심하십시오! 단순한 마이그레이션과 일부 리팩토링을 통해 어느 방법을 다른 방법으로 변환 할 수 있습니다. 이제는 응용 프로그램에 대해 가장 단순한 접근 방법이 미래에 사용할 수있는 최선의 방법이 아닐 수도 있습니다. 그것이 민첩함에 대한 큰 이유입니다!