languages을 user 테이블에 넣고 사용자가 원하는만큼 많은 정보를 가질 수 있도록 저장하는 것이 가장 좋은 방법인지 궁금합니다. 이 필드는 직렬화 된 데이터를 사용하지 않고 집중적으로 검색됩니다. Mysql 테이블에 임의의 값을 저장하는 가장 좋은 방법
exemple 4 언어를 항목 최대 사용자 테이블에 LANG1, LANG2을 위해 내가 항목 수를 limtating 생각했다 ..
이를 달성하기 위해 더 좋은 방법이 있나요?는 database normalization을 불렀다. 특히 당신은 당신이 3 개 테이블을 필요 "Many to Many" association
를 매핑해야합니다.
User(id, name)
Language (id, language_name)
User_Language(id,id_user,id_language)
SELECT l.language_name
FROM User u
JOIN user_language ul ON (u.id=ul.id_user)
JOIN Language l ON (l.id = ul.id_language)
WHERE u.id = 3
편집 :
두 가지가 @silkAdmin을 발견하는 것이 중요합니다. 첫 번째 것은 @ BryceAtNetwork23에서 지적했듯이, User_Language 테이블에 ID를 넣을 필요가 없습니다. 두 번째는 joins, 특히 MySQL Joins에 대해 알아야합니다 (SQL은 다른 DB 엔진에서 달라지기 때문입니다). 당신이 조금 더 파고 후에는 간단하게 할 수있는, 이전 쿼리에서 사용자 테이블에 가입하는 것도 필요하지 않은 것을 볼 수있을 것이다 :
SELECT l.language_name
FROM user_language ul
JOIN Language l ON (l.id = ul.id_language)
WHERE ul.user_id = 3
하지만 확인하기 위해 첫 번째 대답에 추가 너에게 쉬운 일.
은 언어 테이블
를 사용하여 왜 내 대답은 내가 할 줄 방법을 반영한다. 요청한 것을 성취 할 수있는 방법이 많이 있습니다. 그, 나 자신을 설명했다.
극단적으로 생각해 봅시다. 첫 번째 극단은 위에서 말한 것처럼 사용자 테이블에 언어를 저장하는 것입니다. 예를 들어, 열을 가지고 값을 세미콜론으로 구분할 수 있습니다. 이 같은 것
User: (1, "John", "spanish;english;japanese")
이점은 어떤 조인도 필요 없다는 것입니다.사용자의 ID를 감안할 때 언어를 얻을 수 있습니다. 단점은이를 검색하는 것이 정말 고통 스럽다는 것입니다. 언어 "스페인어"로 모든 사용자를 얻는 방법? (결론은 데이터 색인을 생성 할 수 없다는 것입니다.) 오래된 단점 중 하나는 디스크 공간의 과다 사용입니다. DBs와 Normalization이 발명되었을 때, 디스크 공간은 실제로 값 비쌌습니다. 따라서 다음 내용을 저장하십시오.
User: (1, "John", "spanish;english;japanese")
User: (2, "Mary", "spanish;english")
용납 할 수없는 내용이었습니다. 그래서, 어떤 남자가 와서 말 : "이봐, 우리는으로 바꿀 수의이 ID를 사용하자, 그래서": 10.000 사용자와 언어의 몇 백에 대한
User: (1, "John", "1;2;3")
User: (2, "Mary", "1;2")
Language (1,"spanish")
Language (2,"english")
, 즉 디스크 사용에 큰 개선이다 (어쩌면 우리 시대에 이것은 더 이상 사실이 아니며, 나중에 나올 것입니다.) 디스크 문제는 해결되었지만 검색 문제는 여전히 있습니다. 다시 말하지만, "스페인어"라는 언어로 모든 사용자를 얻는 방법은 무엇입니까? 이 디자인을 사용하면 users 테이블을 반복하고 언어 열을 가져 와서 ";" ID 1을 찾으십시오.
그래서 우리는 전에 보여준 접근 방식을 사용하기 시작했습니다.
그래서 지금까지는 그렇게 좋았습니다. 꽤 좋은 설명)
큰 면책 조항은
나는이 작업을 수행하는 방법은 여러 가지가 있으며, 전에 말했듯이. 그것은 당신의 사건과 당신이 무엇을 원하는지에 달려 있습니다. 그 칼럼의 관점에서 검색하고 싶다면 (예를 들어, 영어를 말하는 사용자를 제공하십시오), 제가 대답 한 부분에서 말한 디자인을 고려해야합니다.
현재 데이터를 비정규 화하려고하는 no-sql 데이터베이스 (변경 될 수 있음)라고하는 데이터 솔루션의 "새로운 물결"이 있습니다. 스키마의 과도한 정규화에 대해 우려하는 경우이를 살펴 봐야합니다. 나는 MongoDB와 CouchDB를 추천한다. 시작하기 쉽기 때문이다.
은 약 2 조인의 성능에 대해 걱정하지 마십시오
을 결합한다. 성능 문제가 있다면이 문제가 아닙니다. 이러한 목적으로 DB 엔진이 생성됩니다. 좋은 메모리 캐시 및 인덱스 최적화를 사용하면 원활하게 작동합니다.
예, 가장 좋은 방법은 열 lang_id 및 user_id과 추가 테이블을 사용하는 것입니다. 여기서 사용자/언어 연관 (행당 하나)을 원하는 수만큼 저장할 수 있습니다.
나는 당신이 두 개의 테이블을 고려해한다고 생각합니다. 하나는 users이고 다른 하나는 languages입니다. 유지 관리가 더 쉽고 이러한 테이블에 joins을 사용하는 것이 더 쉽습니다.
만들기 테이블 user_languages 제약
user_id int,
language_id int,
: 당신이 원하는대로 등의 제약으로
PRIMARY KEY (user_id, language_id),
FOREIGN KEY (language_id) REFERENCES language(id),
FOREIGN KEY (user_id) REFERENCES users(id)
은, 사용자가 많은 언어로 할당 할 수 있습니다.
나는 이것을 달성하는 가장 좋은 방법은 USER 테이블, USER_LANGUAGES 테이블 및 LANGUAGES 테이블을 갖는 것이라고 생각한다. 이렇게하면 사용자는 원하는만큼의 언어를 사용할 수 있습니다.
USER
user_id int
user_name varchar
USER_LANGUAGES
user_id int
lang_id int
LANGUAGES
lang_id int
lang_name varchar
사용자는 사용자 기반 필드를 저장합니다. LANGUAGES는 각 언어 (영어, 독일어 등)에 데이터를 저장합니다. USER_LANGUAGES은 사용자가 어떤 언어를 알고 있는지에 대한 연관을 저장합니다.
실제로 USER_LANGUAGE에는 ID 입력란이 필요하지 않습니다. id_user 및 id_language 필드 (함께 연결된 키)는 고유성을 보장합니다. – Aaron
네,하지만 좋은 습관입니다. 나는 그 join에서 user 테이블을 필요로하지 않는다. 그러나 설명을 위해서 나는 그것을 추가했다. – santiagobasulto
@santiagobasulto 상세한 답변을 보내 주셔서 감사합니다. 조인을 사용하는 방법을 알고 있지만 성능을 염두에두고 다른 방법이 없을 때만 사용하려고합니다. 언어 표를 사용하는 이유는 무엇입니까? 사용자 언어 테이블이 충분해야합니다 (id_language를 enum 필드로 대체). – silkAdmin