MySql 데이터베이스에있는 대부분의 테이블은 EAV tables이 아닙니다. 나는 SQL Antipatterns을 읽었으며이 테이블을 재 설계하는 가장 좋은 방법을 결정하려고합니다. 스프링 폼에서보다 쉽게 참조 할 수 있고 데이터 무결성을 향상시킬 수 있다는 이점을 알고 있습니다.EAV 테이블을 다시 디자인하는 방법
EAV table에는 비용이 발생할 수있는 선택적 속성이 있습니다. 코드에는 현재 55 가지 옵션이 있으며 그 수는 계속 증가하고 있습니다. 비용 당 평균 속성 수는 2.719이고 가장 많은 단일 비용은 39 가지 속성을 사용했습니다.
55+ 옵션이있는 테이블을 만드는 것이이 상황에 이상적입니까, 아니면 테이블 크기로 유지해야 할 다음 사람이 적합할까요?
EAV 트리플을 예를 들어로 저장할 수있는 대체 (비 SQL) 디자인으로 document-oriented storage을 조사하기에 좋은 시간 인 것 같습니다. JSON 데이터는 MongoDB입니다. 이 스키마를 정의하지 않으므로 쿼리 구문은 SQL과 다르지만 경우에 따라 훨씬 강력 할 수 있습니다. 예를 들어 RDF를 사용하여 linked-data 스토어를 만들기 위해 최근에 이런 종류의 설정을 사용한 프레젠테이션을 보았습니다. 그런 다음 RDF를 사용하여 다른 서비스의 전체로드를 지탱하는 공통 계층을 형성했습니다. REST, webservices, XMLRPC 등등.이 모든 것을 표준화 된 데이터로 쉽게 수행 할 수 있습니다.
this question을 참조하십시오. 이것이 좋은 아이디어인지 더 자세히 생각해보십시오.
제안 및 링크에 감사드립니다. 비 SQL 데이터베이스를 사용하는 것이 우리 스키마의 한 테이블에 좋은 아이디어일까요? 그게 ORM과 잘 맞을까요? –
필드를 가져 오기 위해 REST를 사용하여 하나의 테이블에 대해이 작업을 수행 할 것입니다. 감사! –
특정 하위 세트의 옵션 만 함께 사용하는 경우, 여러 가지 테이블 상속 중 하나를 사용하여 서브 테이블로 리팩토링 할 수 있습니다. – Hiro2k
감사합니다. 나는 그것에 대해 생각해 보았습니다. 그러나 많은 비용 유형이 필드를 포함 할 수도 있고 포함하지 않을 수도 있기 때문에 매번 어려운 작업을 시작할 것입니다. 나는 앉아서 잘 작동하는지 알아보기 위해 그것을 써야 할 수도 있습니다. –