ORM을 사용할 때 데이터베이스 디자인에서주의해야 할 사항

ORM (Object Relational Mapper) Wikipedia를 사용하여 데이터베이스에 액세스한다는 것을 알고있을 때주의해야 할 데이터베이스 설계에는 어떤 것이 있습니까? Entity Framework NHibernate 또는 LLBLGenPro도 참조하십시오.

예를 들어 SqlServer의 RPC 호출에 대한 2100 매개 변수 제한에 주목합니다. 복합 기본 키를 사용할 때 LLBLgen을 사용하고 테이블을 조인 할 때 발생하는 문제 는 복합 키에 대한 MSDN 문서를 참조하십시오 .

표준 정규화 기술을 통해 주로 3 차 정규 형식으로 이동합니다. 일부 ORM은 데이터베이스 수준에서 정의 된 관계를 선택할 수 있으므로 수동으로 수행 할 필요가 없습니다.

나는 다른 길로 가고 ORM에 대해 무엇을 알아야하는지 물어볼 것입니다. 다음 사항을 확인하십시오.-쿼리를 어떻게 프로파일 링합니까? -ORM을 재정의하고 고유 한 쿼리를 작성하려면 어떻게해야합니까? -저장된 proc를 대신 사용할 수 있습니까?

데이터베이스는 앱보다 오래 지속되므로 ORM에 구애받지 않아야합니다.

1. ORM이 스키마를 작성하거나 업데이트하지 않도록하십시오. 항상 생성 된 SQL을 템플릿으로 사용하지만 변경하기 전에 검토하십시오 (ORM이 중복 인덱스를 만들고 잘못된 데이터 유형을 사용하는 것을 보았습니다 ... 모든 나쁜 것들)

2. 귀하의 ORM이 할 수없는 일을 인식하십시오. 장고는 한동안 고통 스러웠던 ORM을 통해 그룹을 지원하지 않았다 (여전히 레거시 시스템이 재미있다!). 따라서 ORM에 대한 코드를 작성하는 사람이 아니더라도 ORM의 한계를 인식하는 것은 DBA의 필수 요소입니다.

3. 주기적으로 느린 로그를 잡고 mysqlslowlog를 통해 집계 한 후 상위 10 개 정도를보십시오. 기본적으로 전체 집계 시간이 가장 많이 걸린 쿼리를 표시합니다. 지난 1 개월 동안 평균 1 초 밖에 걸리지 않았지만 50K 번 실행 된 쿼리는 아픈 엄지 손가락과 같은 집계 보고서에 표시됩니다.)

나는 ORM을 완전히 버리는 것만 큼 극단적이라고는 말하지 않을 것입니다. ORM을 사용하는 개발자가 DBA가 아닌 경우 ORM보다 나쁘거나 나쁜 SQL을 작성할 수 있습니다. 결국 DBA는 어떤 일이 일어나는지 지켜 볼 것입니다.

Sequel 및 ActiveRecord for Ruby 와 같은 ORM에 의해 작성된 데이터베이스와는 다른 레거시 데이터베이스에 대해 바로 눈에 띄는 몇 가지 사항이 있습니다 .

1. 라는 모든 테이블에서 기본 키 사용 'id'. 예, 그것은 무시 될 수 있지만 id기본값입니다.
2. 테이블에 복수 이름 사용.
3. 밑줄 ( "snakecase")을 사용하여 표와 필드의 설명적인 이름을 만드는 단어를 구분합니다.
4. _id외래 키 에 추가 된 사용 : 레이아웃은 일반적으로 referenced_table_id입니다.

나는 ORM을 믿지 않았기 때문에 수년 동안 SQL을 직접 작성해 왔지만 지난 2 ~ 3 년 동안 앞서 언급 한 2 개의 ORM을 사용하기 시작했으며 기존 데이터베이스와 얼마나 잘 통합되는지에 깊은 인상을 받았습니다. 규칙을 준수하면 데이터베이스를 얼마나 잘 해독 할 수 있는지, 또는 레거시 DB를 이해하는 데 필요한 힌트를 제공하는 데 시간이 걸립니다.

ORM과 잘 어울리는 스키마를 설계하기위한 일반적인 지침이 있는지는 잘 모르겠지만 표준이 있으면 이점이 있다고 생각합니다. 특히 좋은 OO 언어를 사용하고 일정이 빡빡한 경우 ORM을위한 시간과 장소가 확실히 있습니다.

사용중인 OR 매퍼에 따라 (:))에 따라 달라 지므로 문제가있는 OR 매퍼가 지원하거나 지원하지 않는 DB 기능을 조사하는 데 시간을 투자하십시오.

예를 들어, Microsoft의 OR 맵퍼는 모든 SQL Server의 내장 데이터 유형을 지원하지 않으며, 새로운 / 고급 TSQL 기능 (재귀 쿼리, 최적화 힌트 등)을 지원하지 않습니다.

이론적으로 , 좋은 OR 매퍼는 잘 설계된 관계형 데이터베이스 스키마를 좋은 객체 모델로 극복 할 수있을 정도로 유연해야합니다. 실제로, 우리는 여전히 모든 퍼즐 조각이 제자리에 있기 전에 약간의 갈림이 있습니다. 많은 OR 맵퍼가 고급 맵핑을 지원하지만 복잡한 쿼리 및 성능 문제를 희생시키는 경우가 많습니다.

좋은 db 성능을 유지하고 dba의 온전함을 유지하려면 db 스키마 디자인과 관련하여 모범 사례를 따라야합니다. 먼저 정규화하고 [/ if] 필요한 경우 비정규 화하십시오. 코드 측면에서 객체 모델로 넘어 가지 마십시오 . 경우에도 OR 매퍼 지원 복잡한 상속 모델이 또한 당신 등 데이터베이스 타격 지나치게 복잡한 쿼리에 문제로 실행 위험이 분야이며, 함께 많은 테이블을 병합 기관 프로필, 프로필, 프로필을 그냥 ORM 적용되지 않습니다 당연한 쿼리를 생성했습니다. OR 매퍼 생성 쿼리는 보통 일반 SQL 쿼리와 마찬가지로 조정될 수 있으며 객체 측에서 기능적으로 동등한 두 쿼리 (예 : linq 쿼리)로 인해 SQL 쿼리가 크게 다를 수 있습니다.