2009-07-18 3 views
4

나는 최근에 EAV 데이터베이스 구조에 크게 의존하는 시스템을 계승했으며 성능 측면에서 정말로 어려움을 겪고있다.eav를 nhibernate/orm 할 수 있습니까?

내가하고 싶은 일은 nhibernate 또는 다른 적합한 ORM 제품을 사용하여 행을 속성에 매핑 할 수있는 방식으로 엔티티에 매핑하는 것입니다. 그런 다음 데이터베이스를 리팩터링하여 관계형으로 만들 수 있습니다. 이것이 가능한지 아는 사람 있습니까? 예를 들어 주시면 감사하겠습니다. :)

그것은 다음과 같이 보입니다, 구조 당신에게 느낌을 제공합니다 :

엔티티 (ENTITYID) EntityVarchar (ENTITYID, VarcharValue) EntityFloat (ENTITYID, VarcharValue)

등 . Customer 엔티티가 있으면 Customer.Varchar [ "Name"] 대신 이름을 얻기 위해 Customer.Name을 말하고 싶습니다.

우리 시스템에서는 EAV 모델을 사용할 필요가 없으며 데이터 구조의 런타임 변경을 허용하지 않으므로 어쨌든 나쁜 생각입니다.

답변

1

나는 이것이 그렇게 쉽지 않을 것이라고 생각합니다. 데이터베이스 스키마를 읽고 적절한 매핑과 클래스를 생성 할 수있는 생성기가 있지만 기존의 eav db에 대한 액세스 계층 만 생성됩니다. 이 db의 관계형 버전을 생성하려면 데이터를 읽고 db에 설정된 값의 속성을 포함하는 새 도메인 객체를 만들어야합니다. 이것은 eav db에있는 모든 특성을 포함하는 하나의 큰 테이블을 생성 할 가능성이 높습니다. 따라서 기존 데이터를 손으로 분석하고 응용 프로그램의 필요성을 고려하여 관계형 DB 모델을 만드는 것이 더 나은 방법이라고 생각합니다. 특히 테이블 상속은 여기에 친구가되어야합니다. 그런 다음 두 스키마에 대한 액세스 계층을 만든 후에도 데이터 마이그레이션을위한 매핑을 작성해야합니다.

+0

nHibernate를 사용하면 db 스키마와 1 : 1 매핑이 아닌 방식으로 엔티티를 클래스에 매핑 할 수 있으므로 자신을 데이터베이스에 강하게 결합 할 필요가 없습니다. 여러 개의 행을 매핑 할 때 한 가지 방법 만 볼 수 있습니다. 하나의 객체에 대해 각 속성에 대해 하나씩. 일반적으로 단일 객체에 대한 데이터가 포함 된 행이 하나 있습니다. – spooner

+0

알아,하지만 이미 언급 한 것 외의 다른 방법으로 원하는 것을 할 수있는 가능성은 없다. 당신은 many-to-one의 filter-prop를 사용할 수 있지만, 아무 것도 도움이되지 않을 것입니다. 어쨌든 이것이 성능 문제를 해결하는 데 도움이되지 않는다고 생각합니다. 어쩌면 내가 틀렸어.하지만 당신이 관계형 또는 혼합 스키마로 eav를 리팩터링하는 것을 고려하고 있다고 이해함에 따라. 가방/세트에 희귀 한 소품 만 eav로 보관한다면 필요할 때만 실을 수있는 게으름 뱅이가 될 수 있습니다. – zoidbeck

+0

문제는 우리가 정말로 속성 가방을 필요로하지 않는다는 것입니다. 새로운 속성을 추가하는 것은 개발자뿐입니다. 사용자가 모델을 확장 할 것을 기대하지 않습니다. 기본적으로 내가 상속 한 시스템은이 EAV 구조가있는 프레임 워크에서 만들어졌습니다. 우리는 완전히 표준화 된 모델을 원합니다. 도메인 모델을 기준으로 데이터베이스 작업을 시작할 수있을 때 제안한 방식으로 매핑을 수행 할 수 있기를 바랬습니다. 당신이 말하는 것은 불가능합니다. 이것은 수치 스럽습니다. 다른 유일한 해결책은 손으로 만들어진 DAL 인 것 같습니다. – spooner

관련 문제