자주 추가/제거되는 열 저장

Question

내 웹 앱에 대한 사용자 정의/설정을 저장하는 데는 두 가지 아이디어가 있습니다. 이 작업을 수행하는 데 더 많은 방법이있을 수 있으며 새로운 아이디어에 대해 개방적입니다. 당신이 비정상적으로 변경 될 수 있습니다 설정/사용자 정의를 저장하기위한 추천 방법

? 예를 들어 이번 주에는 사용자가 할 수있는 12 가지 맞춤 설정이 있습니다. 다음 주에 우리는 짧은 시간에 새로운 것을 추가 할 것입니다.

그래서, 수 :

1. 스토어 기본 키로 사용자 계정과 열로 설정 (등 VARCHAR, 등의 int로서 VARCHAR로 user_image_url, time_offset, background_color). 새로운 설정이있을 때마다 또 다른 열을 추가해야한다는 생각이 맘에 들지 않지만이 열이 가장 쉽고 빠르며 가장 명백한 방법이라고 생각합니다.
2. 계정 ID, 설정 ID 및 설정 값만 varchar로 저장하는 테이블을 만듭니다. 그래서 (account_id, setting_id, value) values (1, 2, 'http://logos.com/yourlogo.png')과 같은 것입니다. 생각은 setting_id을 저장하는 settings 테이블과 결합하는 것입니다. 이것 (내가 볼 수있는)의 큰 단점은 모든 설정이 동일한 유형 (varchar)이어야한다는 것입니다. 나중에 엉덩이에 물린다면 확실하지 않습니다.

고마워요! 동적 "성긴"값

Answer 1

는, 두 번째 버전은 값들을 저장하는 실행 가능한 방법이다. 이를 엔티티 속성 값 모델 (EAV)이라고합니다. 나는 하이브리드 배열에서 잘 작동한다는 것을 알았다. 즉, 모든 사용자 또는 대부분의 사용자가 공유하는 많은 공통 정보가있는 사용자 당 하나의 레코드입니다. 그런 다음 특수 설정이있는 별도의 테이블.

는 EAV 모델과 많은 문제가 있습니다. 큰 데이터 세트에서는 성능이 문제가 될 수 있습니다. 엔티티 ID와 속성 이름 (또는 ID)이 여러 행에 걸쳐 반복되기 때문에 테이블의 크기가 훨씬 더 큽니다. 그러나 Wordpress와 같은 일부 중요한 시스템에서는이 방법을 사용합니다.

하나의 큰 이점은 4096 속성 이상을 가질 수 있다는 것입니다 - 그리고 4096은 MySQL을위한 최대 열 수 있습니다. 나는 당신이 그 많은 세팅을 가질지는 의심 스럽지만, 필요하다면이 한계를 극복 할 수 있다는 것을 아는 것은 좋은 일이다 (그리고 다른 많은 데이터베이스에서는 한계가 더 낮다). 일반적으로 varcharfloat (일종의) 및 datetime을 - -

마지막으로, 당신은 여러 열을함으로써 유형의 문제를 해결할 수 있습니다 따라 유형 열이. 그렇게하면 값을 직접 저장할 수 있습니다. varchar 경로로 이동하는 경우 YYYY-MM-DD의 ISO 형식으로 날짜를 저장하십시오 (원하는 경우 하이픈을 생략 할 수 있음).

Answer 2

옵션 1 관계형 데이터베이스 설계의 첫 번째 정규 양식에 위배됩니다. 옵션 2가 가장 좋은 방법입니다. - 웹에서 사용할 첫 번째 정규 양식의 가능한 많은 설명이 있습니다이 내가 찾은 가장 간단 : http://www.andrewrollins.com/2009/08/11/database-normalization-first-second-and-third-normal-forms/ 그것은 주로에 따라