0

데이터베이스 테이블 디자인에 대한 제안이 필요한 상황이 있습니다.이 시나리오에서 올바른 MySQL 테이블 디자인/관계

나는 (정확히 말하면 CakePHP의) PHP에서 응용 프로그램을 개발하고

배경. xml 파일을 업로드 할 때 파일을 구문 분석하고 데이터베이스에 데이터를 저장합니다. 이러한 XML은 파일 또는 URL 피드 일 수 있으며 이러한 데이터는 다양한 공급 업체에서 구입할 수 있습니다. 그것은 소스 URL의 다양한 장소 데이터를 수집하기위한 것입니다, 장소는이 장소에 대한

문제

초기 테이블 구조는 다음과 같습니다 호텔, 영화관, 학교, 레스토랑 같은 것을 할 수 있습니다. 테이블은 초기에 일반 정보를 저장하도록 지정됩니다.

다른 출처의 데이터가 많을수록 다양한 유형의 장소에 많은 특성이 있다는 것을 깨달았습니다. 학교를 가지고 있지만 attributes.Restaurant의 다른 세트는 다른 특성을 갖습니다 필요가 없습니다으로

예를 를 들어 호텔은

price_for_one_day, types_of_accommodation, Number_of_rooms etc 

곳과 같은 몇 가지 속성을 가질 수있다.

내 첫번째 생각은 vanue_attribute_names라는 두 개의 테이블을 만드는 것입니다 내가 하나를 만들려면 새로운 속성과의 관계와 속성 테이블에서 값을 감지한다면

##table venue_attribute_names 
_____________________________ 
id 
name 

##table venue_attributes 
________________________ 
id 
venue_id 
venue_attribute_name_id 
value 

을 Venue_attributes. 그러나 이것이 올바른 접근법이 아닌지 의심 스럽다. 나는 이것을위한 다른 접근법이있을 수 있다고 생각한다. 게다가 테이블이 커지면 조인 및 SQL 쿼리가 증가하여 성능 문제가 발생할 수 있습니다.

가능한 모든 속성을 사용하여 가능한 가장 넓은 테이블을 만들고 있습니까? 저에게 알려주세요. 내가 참조 할 수있는 링크가 있으면 따라갈 수 있습니다. 감사합니다.

답변

0

관계형 데이터베이스를 사용한다면 그만한 것입니다. 나열한 옵션은 그들이 제공 할 수있는 것입니다.

상황에 따라 MongoDB (또는 다른 문서 지향 NoSql 시스템)이 좋은 옵션이 될 수 있습니다. 이 db 시스템은 서로 다른 속성을 가진 레코드가 많은 경우 매우 유용합니다.

+0

다른 데이터베이스를 선택하는 것은 현재 옵션이 아닙니다. 많은 개발이 있었고 디자인을 제외하고는 거의 완료되었습니다. 내가 설명한 것은 응용 프로그램의 일부이며 더 많은 정보가 있습니다. –

+0

MongoDb에 모든 것을 넣을 필요는 없습니다. XML로 얻은 것을 MongoDb에 저장하고 나머지 응용 프로그램에 대해서는 서비스 (-class)로 액세스 할 수있게하십시오. – BetaRide

2

이것은 놀랍게도 일반적인 문제입니다.

설명하는 디자인은 일반적으로 "엔티티/속성/값"또는 EAV로 알려져 있습니다. 해당 데이터에 대한 스키마가 무엇인지 미리 알 필요없이 모든 종류의 데이터를 저장할 수있는 이점이 있습니다. 그것은 쿼리하기 어렵다는 단점을 가지고 있습니다 - 주어진 위치에 모든 호텔을 찾는 것을 상상해보십시오. 일일 객실료는 $ 100 ~ $ 150이며, 이름은 "Waldorf"로 시작합니다. 모든 속성에 대해 쿼리를 작성하고 부울 논리를 신속하게 적용하는 것이 원하는 것보다 더 어려워집니다. 또한 "hotel_name은 null이 아니어야"또는 "daily_room_rate가 숫자 여야합니다."와 같이 데이터베이스 수준의 일관성 검사를 쉽게 적용 할 수 없습니다.

걱정하지 않으셔도 디자인이 작동 할 수 있습니다.

두 번째 옵션은 일반적인 관계형 구조에 "공통"필드를 저장하지만 일종의 문서 (예 : supports XML)에 변형 데이터를 저장하는 것입니다. 따라서 XML 스키마를 정의하고 XPath 등을 사용하여 쿼리 할 수 ​​있습니다.

이 방법을 사용하면 스키마 제약 조건을 적용 할 수 있으므로 EAV보다 데이터 무결성이 향상됩니다. 다루는 각 유형의 데이터에 대한 스키마를 만들어야한다는 것을 의미합니다. 그건 괜찮을거야. 매주 수십개의 새로운 장소 유형을 추가하지 않는다고 생각해.

XML 쿼리를 사용하면 성능이 까다로울 수 있으며 일반 툴링 및 개발 방식을 사용하면 "단순한 SQL"보다 빌드하기가 더 어려워집니다.

마지막 옵션은 관계형 데이터베이스를 사용하고 싶다면 단순히 글 머리 기호를 물고 "순수한"SQL을 사용하는 것입니다. 공통 속성을 가진 "마스터"테이블과 레스토랑 속성을 가진 "레스토랑"테이블, 호텔 속성이있는 "호텔"테이블을 만들 수 있습니다. 이는 관리 가능한 장소 유형의 번호를 가지고 있고 예측할 수 없을 정도로 잘 자르지 않는 한 작동합니다.

마지막으로 NoSQL 옵션을 살펴볼 수 있습니다.

+0

감사합니다. 데이터를 XML 파일이나 일부 파일에 저장할 수 있다는 것을 알고는 있지만 결코 그런 식으로 사용하지는 않았지만 데이터베이스에 파일에 데이터를 저장하는 것은 잘못된 생각이라고 항상 생각합니다. 나는 어떤 경우에 내가 틀렸다는 것을 알았다. 내가 원하는 것을 얻을 수 있는지 말하고 옵션을 시도 할 것입니다. –