답변:
응용 프로그램이 수행하는 작업, 데이터 모양, 성능 기대치 등을 알지 못하면 특정 데이터베이스 디자인이 나쁜지 여부를 말하는 것은 불가능합니다. 일반적으로 정규화 (어느 정도까지)가 모범 사례로 여겨지지만 성능상의 이유로 데이터베이스 영역을 비정규 화하는 것이 일반적입니다. 따라서 대부분의 사람들이 처음 시작할 때보 다 많은 양의 데이터 없이도 토론이 가능합니다.
"최상의"데이터베이스 구조가 특정 객체 모델, 상속 수준 등에 따라 달라 지므로 관계형 매핑에 객체화 할 수있는 많은 접근 방식을 추가하십시오.
하나의 크기를 모든 접근 방식에 맞추면 ORM 지속성 라이브러리는 거의 항상 주어진 상황에 대해 최적이 아닌 데이터베이스 구조를 생성하며 주어진 상황에 대해 나쁜 습관으로 보일 수있는 몇 가지를 사용 합니다 .
분명히 정규화 된 ORM을 작성할 수는 있지만 주 테이블에 삽입 할 때마다 다양한 조회 테이블을 스캔하여 값이 존재했는지, 키를 얻었는지 여부, 관련 인서트를 수행하지 마십시오.
(수동으로 할 때 유효한 값만 포함하는 드롭 다운을 제시 했으므로 이러한 룩업을 수행 할 필요가 없다는 것을 알면서이 중 일부를 단축 할 수 있습니다. 행복한 키를 사용할 수 있습니다. ORM은 UI를 제어하지 않으므로 이러한 가정을 유효하게 만들 수 없습니다.)
그러나 기억해야 할 것은 데이터베이스 성능이나 데이터 무결성을 최적화하지 않고 개발 속도를 최적화한다는 것 입니다. 데이터의 특정 구조가 중요한 경우 객체 / RDBMS 매핑을 직접 코딩하거나 최소한 사용 가능한 모든 라이브러리에 대한 세부 평가를 수행하고 필요에 가장 적합한 라이브러리를 선택해야합니다 ( 존재하는 경우).
본질적으로 요구 사항과 잘 구성된 데이터, 데이터베이스 성능 및 개발 속도 간의 균형을 유지해야합니다. 많은 트레이드 오프와 마찬가지로 세 가지를 모두 선택할 수는 없습니다.
ORM이 비정규 화 또는 잘못된 데이터베이스 설계를 촉진한다는 데 동의하지 않습니다. 실제로, 내가 본 최악의 설계 데이터베이스는 ORM없이 수행되었습니다. 난수 필드의 값을 기반으로 관계를 만드는 대신 행 ID를 기반으로 적절한 관계를 갖는 것이 간단 해 지므로 데이터베이스 설계가 향상됩니다.
아마도 정규화를 촉진하지는 않지만 테이블 / 객체 및 관계를 쉽게 만들 수있는 ORM을 통해 거의 그것을 홍보 할 수 있습니다. ORM에서는 주소가있는 "위치"테이블을 만들고 직원 테이블에 주소를 추가하는 대신 직원을 해당 위치에 연결하는 것이 그리 어렵지 않습니다. 그러나 ORM이 없으면 위치를 분리한다는 것은 위치에 액세스 할 때마다 참여해야한다는 것을 의미합니다.
내 대답은 : 아니요, 나는 그렇게 생각하지 않습니다 . 사실 다른 방법으로도 좋은 ORM 은 경험이 거의없는 사람들에 대해 좋은 데이터베이스 디자인을 장려 합니다.