관리자가 프로그램으로 양식을 작성하고 사용자가 양식에 데이터를 입력 할 수있는 시스템을 구축하고자합니다. 또한 관리자는 선택 가능한 객관식 질문조차도 양식에 필드 이름을 입력 할 수 있어야합니다. 생성 된 모든 양식 유형에 대해 거대한 텍스트 블록을 작성하고 양식 필드, 이름, 선택 사항 등을 배열이나 개체에서 직렬화하는 등의 해결책이 있습니다. 나는 다른 텍스트 블록에 직렬화 된 배열로 사용자의 답변을 보관하고 배열의 각 위치에 배열을 할당합니다.동적 데이터베이스 필드를 유지하는 가장 좋은 방법은 무엇입니까?
이 문제에 대한 더 나은 방법이 있습니까?
EAV data model이 여기에 귀하의 목적에 부합 할 수 있습니다. 참조 무결성이 부족하고 데이터를 검색하기 위해 긴 쿼리 (반환하려는 모든 특성에는 다른 JOIN이 필요함)와 같은 몇 가지 단점을 고려하여 유연성을 고려해야합니다.
데이터베이스에 "필드"와 같은 테이블을 만들 수 있습니까? 각 필드에는 유형과 텍스트가 있습니다. 그런 다음 options라는 테이블을 가지며 옵션에 대한 다른 텍스트 필드와 "fields"테이블로 다시 향하는 fk를 포함합니다. fields 테이블에 fk가있는 양식 테이블이있을 수도 있습니다. 앱 코드에서 필드를보고 옵션을 가져와야하는지 결정할 수 있습니다. 이는 관계형 데이터베이스 접근 방식입니다. Mongo와 같은 일부 객체 데이터베이스는이 점을 훨씬 잘 처리 할 수 있습니다.
은 요약하면 :
표 : 양식 칼럼 : Form_ID PK
테이블 : 필드 칼럼 : FIELD_ID PK 칼럼 : 텍스트 칼럼 : 유형 칼럼 : Form_ID (FK)
을 표 : 옵션 열 : Option_ID 열 : 텍스트 열 : Field_ID (FK)
여기에 갈 수있는 방법이 많이 있습니다. 관계형 데이터베이스로 작업하기 때문에 한 가지 옵션은 Entity-Attribute-Value model입니다. 사실상이 방법은 데이터 구조를 미리 정의 된 스키마 (열)에서 행으로 전환합니다. 이러한 유연성에는 많은 단점이 있으며, 종종이 "회전 된"데이터 중 일부를보다 전통적인 테이블 형식으로 표현하기 위해 많은 뷰를 작성하게됩니다.
일부 관계형 데이터베이스는 SQL 형식 기능을 제공하지 않으므로 해당 솔루션을 찾을 수 있습니다. 예를 들어 PostgreSQL에는 hstore 유형이 있습니다.이 유형을 사용하면 키 - 값 쌍을 단일 값으로 저장할 수 있습니다. 귀하의 질문에 PostgreSQL을 언급하지 않았다는 것을 알았지 만, 당신이 알고있는 것만 큼, 그들은 9.2를위한 네이티브 JSON 데이터 유형과 함수 모음으로 작업하고 있습니다. 기능적 인덱스와 함께, Redis 또는 MongoDB와 같은 기능이없는 관계형/noSQL 하이브리드 가능성을 제공 할 수 있습니다.
나는이 바보 표준 Q & A 형식의 물건에 짜증을 내기 시작했다. 미안하지만이 정보에 대해 최소한의 경험이있는 사람으로부터이 정보가 필요했습니다. 조금만 스크롤하면 사람들이 나를 도왔습니다. 어떤 것이 더 좋고 다른 사람들이 짜증나는지에 대한 불필요한 논의가 없었습니다. 또한 이것은 답변자 중 한 명이 '데이터베이스로하지 마십시오, 더 좋은 방법이 있습니다'라고 말할 수있는 지점 일 수 있습니다. 그리고 저 역시 중요합니다. 나는 대답 마감과 같은이 나치가 S.O. 떨어지기 시작합니다. 태양처럼 위대한 공동체를 깨지 마십시오. – gkaykck