음식 데이터베이스를 만드는 더 좋은 방법은 무엇입니까?

Question

저는 현대 요리에 사용되는 모든 기본 재료가 들어있는 관계 데이터베이스를 만드는 프로젝트를 진행했습니다. 당신이 상상할 수 있듯이 수천 가지 항목이있을 것입니다. 나는 많은 SQL 경험이 없기 때문에 재료를 저장하는 겉으로보기에 효율적인 방법에 도달하는 데 어려움을 겪고있다. 여기 가면 http://en.wikipedia.org/wiki/Outline_of_food_preparation#General_ingredients으로 현재 데이터베이스에 넣으려고하는 목록을 볼 수 있습니다.

현재 데이터베이스에는 음식의 주 카테고리와 하위 카테고리에 대한 테이블이 있습니다. 곡물을위한 테이블과 밀을위한 다른 테이블. 처음에이 작업을 수행 한 것은 괜찮은 것 같았지만 몇 가지 하위 카테고리가 추가 될 것임을 깨달았습니다. 해당 위키 목록의 각 항목에 대해 더 많은 테이블과 더 많은 테이블을 만들어야합니다. 이 테이블이 너무 많아서 프로젝트가 매우 비효율적이게 느껴집니다. 내 데이터베이스를 만드는 더 좋은 방법이 있습니까? 아니면 올바른 방향으로 가고 있습니까? 여기 내 테이블의 컬럼의 예는 다음과 같습니다

id INT(11),name VARCHAR(45),parent INT(11),img VARCHAR(45),desc VARCHAR(45) 

부모 INT (11) 부모 테이블이 무엇이든에 외국의 열쇠가 될 것입니다, 그래서 나는 그들이 모든 방법을 연결합니다 생각. 모든 조언을 부탁드립니다! ~ 감사합니다

Answer 1

내가 먼저 별도의 테이블에 모든 저장 권하고 싶지 않다 - 그것은 당신에게

가 대신하지만, 난 당신이 두 가지 옵션이 있습니다 생각하는 미친 :-) 드라이브 것이다.

옵션 1 (인접성 (adjacency) 목록 모델) - FoodId으로 FoodName, ParentFoodId, 저장하려는 AnyOtherAttributes을 하나의 Foods 테이블을 사용하는 것이 좋습니다. 이것은 데이터를 저장하는 것이 가장 쉽지만 결과를 반환하기 위해 좀 더 번거로운 일이 될 수 있습니다. 같은 테이블에서 여러 번 반환하여 수준을 반환해야하기 때문입니다.

옵션 2 (중첩 세트 모델) -이 옵션은 여전히 ​​Foods 테이블을 가지지 만 ParentFoodId 대신 2 개의 열, left_index 및 right_index가 있습니다. 이것은 아마도 처음에는 이해하기가 조금 더 복잡하지만, 몇 가지 알 수없는 중첩 된 부모 - 자식 관계가있는 경우 쿼리하기가 더 쉽습니다.

약간의 추가 설명은이 문서에서 살펴 보자 :

http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

행운을 빕니다.