필드, EAV 등의 MySQL 다중 값

Question

미안 제목을 더 잘 설명 할 수 없습니다. 나는 여전히 내가 처리하고있는 것의 이름을 모른다.

부동산 사이트에 대한 검색 시스템을 개발 중이며 검색 페이지의 필터로 사용되는 일부 필드가 여러 값일 수 있다는 사실을 잊어 버릴 때까지 제대로 작동했습니다. . 제가 의미하는 바는 제가 세일 및 렌트 분야뿐 아니라 주거용 및 상업용 (다른 분야들도) 분야가 하나뿐이라는 것입니다. 문제는 부동산이 판매되거나 임대되거나 주거용이거나 상업용 일 수 있다는 것입니다. 산업.

내가 할 수 있다고 생각한 것은 그걸 자신의 테이블로 옮기는 것입니다. 문제는 값 이름을 표시하고 양식을 채우며 제약 조건으로 사용되는 각 필드의 가능한 값을 나열하는 또 다른 테이블이 있다는 것입니다.

그래서 이제는 무수히 많은 테이블이 붙어 있습니다. .

속성에 대한 테이블, 값에 대한 테이블 및 이러한 값을 속성에 조인하는 테이블입니다.

필터가없는 일반적인 검색 쿼리 (필터가 많고 조인이 많음) 저는 7 개의 내부 조인입니다.

결과를 제한하고 쿼리의 SELECT 부분에서 값을 반환하기 위해 조인을 사용하는 데 매우 어려움을 겪고 있습니다.

이 문제로 인해 지난 2 일 동안 정신적으로 피로감을 느끼게 된 것에 대해 감사드립니다.

편집 :

나는이 순간에 다음과 같은 테이블 :

속성
properties_images
properties_listings
properties_options
properties_purposes
res_geo_address
res_geo_cities
res_geo_neighb orhoods
res_geo_states
res_property_options
res_property_type_age
res_property_type_listing
res_property_type_property
res_property_type_purpose
res_property_type_purpose_property

속성 테이블 기본 속성 테이블 속성을 설명 colums 소수있다.

res_ (예외 화상 단지 이미지 레코드가 포함되어있다) -

속성 _ 표

은 속성 테이블 및 res_property_ 테이블 (등록 정보에 대한 하나의 값에 대해 하나 using이 IDS)을 해소하는데 사용된다 테이블은 대부분의 ID와 값 이름을 나열합니다. (예외는 res_geo 테이블입니다)

현재로서는 쿼리가 작동하지 않습니다. 솔직히 말해서 나는 현재의 설정을 설명하기가 어렵다는 그런 복잡함에 도달했습니다.

배열이있는 필드가있는 테이블을 쿼리하고 쉽게 검색 할 수 있다면 간단합니다.

EDIT 2가

화상 위 조인의 일이다. 어떻게하면 속성을 쿼리 할 수 ​​있습니까? 항상 연결된 모든 목록 이름의 concat을 검색하지만 선택적으로 특정 목록 ID 그룹의 속성을 제한 할 수 있습니까?

Property가 Entity 주어진에 적용 할 수있는 다양한 속성을 정의

  Entity 
      ^
      | 
    EntityPropertyValue 
      | 
      | 
Property<----  PropertyValue 
^     | 
    |      | 
    --------------------- 

가, PropertyValue가 주어진 Property에 유효한 값을 정의하고, EntityPropertyValue 정의 :이 경우

Answer 1

당신이 설명하는 것입니다 주어진 Entity 주어진 속성에 대한 가치, 그럼 당신은 정확히 정확히 EAV입니다 (단어 Attribute을 Property으로 대체하면 은에 정확히 EAV가됩니다).

본 아키텍처에는 본질적으로 잘못된 것이 없으며 유효한 (가능한 경우 만 유효) 일부 상황이 있습니다. 상황이 EAV의 좋은 후보 인 것처럼 들립니다.

문제는 사용자가 특정 속성에 대해 여러 값을 지정할 수있게 허용 할 때 특히 쿼리를 어렵게 만들 수 있다는 점입니다. 이렇게하면 잠재적 인 데카르트 제품을 고려해야하므로 결과 세트를 구성하기가 어려워집니다. 문제가있는 실제 검색어를 보지 않고도 더 이상의 조언을 드릴 수는 없습니다. 질문을 수정하고 내 대답에 의견을 게시하십시오. 수정 한 후 수정하고 조언을 추가하십시오. 그러나 단순히 "무수한 테이블"을 갖는 것이 반드시 나쁜 것은 아니며 매개 변수가 주어지는 올바른 디자인 선택과 같다고 말할 수 있습니다. 당신이 모든에 대한 정수 키를 사용하는 아주 나쁜 충고의 피해자, '판매'와 같은 값을 가진 단 하나의 진짜 열이 있어도 간단한 테이블처럼

Answer 2

등 '임대'

, 소리 귀하 테이블 RES_PROPERTY_TYPE_LISTING은 "TypeCode"라는 단 하나의 열만 가져야합니다 ("code"는 문자 기본 키를 사용할 때 매우 오래된 규약입니다). 이는 기본 키입니다.

정수 우리는 단지이 가입 제거했습니다, 빠른 조인을 확인하고 빠른 가입한다는 생각에 대해서는

ID_PROPERTY TypeCode 
----------- --------- 
    1   Sale 
    1   Rent 
    2   Rent 

는 하나입니다 PROPERTIES_LISTINGS은 다음과 같습니다 때문에

이제, 하나 개의 테이블을 드롭 수 당신은 할 필요가 없습니다. 나머지 JOIN은 여전히 ​​정수이므로 10,000 trx/초를 치면 안전합니다. 이전에는 그 차이를 볼 수 없기 때문입니다.

행운을 빈다.