PHP, MySQL, Jquery templating 및 JSON을 사용하여 매우 간단한 할 일 목록 응용 프로그램을 만들려고합니다. 그러나 내 스키마는 JSON의 작업을 복잡하게하는 것으로 보입니다.
가장 좋은 방법은 무엇입니까?
또는
답변:
내가 한동안 들었던 농담이 있습니다.
Q 기본 코더는 어떻게 10으로 계산됩니까?
A 1,2,3,4,5,6,7,8,9,10Q C 코더는 10으로 어떻게 계산됩니까? 0,1,2,3,4,5,6,7,8,9
Q DBA는 어떻게 10으로 계산됩니까? 0, 1, 많은
이 농담의 진실은 일단 데이터베이스 구조 (열 또는 테이블)에 동일한 것 ( 두 개 이상)이 있으면 잘못하고 있다는 것입니다.
다음과 같은 스키마 :
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
다른 사람이 가지고 있다면 세 번째 전화 번호를 어디에 두어야합니까?
테이블 자체에도 동일하게 적용됩니다. 또한 "각 목록의 새 테이블"이 암시하는 것처럼 런타임에 스키마를 수정하는 것은 나쁜 일입니다. (관련 : MVC4 : 런타임에 모델을 만드는 방법? )
따라서 해결책은 두 개의 테이블로 구성된 할 일 목록을 만드는 것입니다. 리스트와 아이템이라는 두 가지가 있습니다.
따라서 이것을 반영하는 테이블 구조를 만들어 봅시다.
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
목록에는 ID (목록의 기본 키)와 이름이 있습니다. 작업에는 id (기본 키)와 listid (외래 키) 및 작업 설명이 있습니다. 외래 키는 다른 테이블의 기본 키와 다시 관련됩니다.
이것이 소프트웨어 및 테이블 구조를 지원하기위한 다양한 요구 사항의 모든 가능성을 포함하지는 않는다고 지적합니다. 완료, 기한, 반복 등 ... 이들은 테이블을 설계 할 때 고려해야 할 모든 추가 구조입니다. 즉, 테이블 구조가 적절하게 정규화되지 않았거나 정규화되지 않았기 때문에 작성한 상충 관계를 실현하지 않으면 나중에 많은 두통이 생길 것입니다.
이제 이것을 관계형 데이터베이스로 작성하는 것과 관련이 있습니다. 그러나 이것이 유일한 유형의 데이터베이스는 아닙니다. 목록을 문서로 생각 하면 문서 스타일의 nosql 데이터베이스도 잘못된 접근 방식을 제공 할 수 있습니다.
너무 깊이 파고 들지는 않지만 소파에 할 일 목록에 대한 수많은 자습서가 있습니다. 검색과 함께 제공된 하나 는 CouchDB의 간단한 작업 목록 응용 프로그램입니다 . 또 다른 것은 couchdb 위키에서 제안 된 할 일 목록 스키마를 보여줍니다 .
소파에 적합한 접근 방식에서 각 목록은 데이터베이스에 저장된 JSON 문서입니다. 목록을 JSON 객체에 넣고 데이터베이스에 넣습니다. 그런 다음 데이터베이스에서 읽습니다.
JSON은 다음과 같습니다.
[
{"task":"get milk","who":"Scott","dueDate":"2013-05-19","done":false},
{"task":"get broccoli","who":"Elisabeth","dueDate":"2013-05-21","done":false},
{"task":"get garlic","who":"Trish","dueDate":"2013-05-30","done":false},
{"task":"get eggs","who":"Josh","dueDate":"2013-05-15","done":true}
]
( 스택 오버플 로에서 json 파일로 쇼핑 목록 작성에서 ).
또는 뭔가 접근하고 있습니다. 소파가 문서의 일부로 유지하는 다른 기록이 있습니다.
문제는 잘못된 접근 방법이 아니며 문서 데이터베이스의 할 일 목록이 수행 하는 방법 에 대한 개념 오버 헤드가 적어 수행하려는 작업에 완벽하게 적합 할 수 있다는 것입니다.
옵션 2는 일반적인 마스터 / 세부 설정입니다. 그것은 아마도 당신이 원하는 것입니다. 항목 ID를 목록 테이블에 넣고 조인하십시오. 스키마는 JSON에 영향을 미치지 않아야합니다. 검색어는 다음과 같습니다.
select lists.name as list_name, items.name as item_name
from items
join lists on (lists.id = items.list_id)
UI 표현 또는 데이터 전송을 UI에 직접 저장하여 데이터를 저장하려는 방법과 관련이 없습니다. 두 가지를 분리하고 일부 미들웨어 논리를 사용하여 두 가지를 결혼함으로써 다른쪽에 치명적인 영향을주지 않고 한쪽을 쉽게 변경할 수 있습니다.
데이터 스토리지 관점에서, 일반적인 부품이 자체 테이블로 분해되어 반복을 피하고 데이터베이스 팽창을 최소화하는 일반적인 정규화 된 데이터 패턴을 따르는 옵션 2를 사용할 수 있습니다.
뷰 관점에서 데이터베이스 쿼리를 사용하여 관련 데이터를 결과 집합에 결합한 다음 해당 결과를 반복하고 UI 요구에 해당하는 json 응답을 생성하면됩니다. 가능한 한 UI에 데이터를 공급하여 가능한 한 UI 요구 사항에 가장 잘 맞아 웹 페이지에 추가 스크립팅 논리가 필요하지 않습니다.