더 효율적인 방법 : 여러 MySQL 테이블 또는 하나의 큰 테이블?

더 효율적인 방법 : 여러 MySQL 테이블 또는 하나의 큰 테이블?

---

MySQL 데이터베이스에 다양한 사용자 세부 정보를 저장합니다. 원래는 데이터가 UserId와 연결되어 있고 필요에 따라 데이터를 표시하고 조작하는 복잡한 호출을 통해 출력하는 것을 의미하는 다양한 테이블에 설정되었습니다. 새로운 시스템을 설정하면 이러한 모든 테이블을 하나의 큰 관련 콘텐츠 테이블로 결합하는 것이 거의 합리적입니다.

• 이것이 도움이 될까요 아니면 방해가 될까요?
• 전화, 업데이트 또는 검색 / 조작시 속도 고려 사항?

다음은 내 테이블 구조의 일부 예입니다.

• users-사용자 ID, 사용자 이름, 이메일, 암호화 된 비밀번호, 등록 날짜, IP
• user_details-쿠키 데이터, 이름, 주소, 연락처 정보, 소속, 인구 통계 데이터
• user_activity-기여, 마지막 온라인, 마지막보기
• user_settings-프로필 표시 설정
• user_interests-타겟팅 가능한 변수 광고
• user_levels-액세스 권한
• user_stats-조회수, 집계

---

편집 : 지금까지 모든 답변을 찬성했으며 모두 본질적으로 내 질문에 대답하는 요소가 있습니다.

대부분의 테이블은 비정규 화의 주된 이유 인 1 : 1 관계를 가지고 있습니다.

이러한 셀의 많은 부분이 비어있을 가능성이있는 경우 테이블이 100 개 이상의 열에 걸쳐 있으면 문제가 있습니까?

---

여러 테이블은 다음과 같은 방법 / 사례에 도움이됩니다.

(a) 다른 사람들이 다른 테이블을 포함하는 응용 프로그램을 개발하려는 경우 테이블을 분할하는 것이 좋습니다.

(b) 데이터 수집의 다른 부분에 대해 다른 사람에게 다른 종류의 권한을 부여하려는 경우 분할하는 것이 더 편리 할 수 ​​있습니다. (물론 뷰를 정의하고 적절한 권한을 부여하는 방법을 살펴볼 수 있습니다.)

(c) 특히 개발 중에 데이터를 다른 위치로 이동하려면 테이블을 사용하여 파일 크기를 줄이는 것이 좋습니다.

(d) 더 작은 공간은 단일 엔티티의 특정 데이터 수집에 대한 애플리케이션을 개발하는 동안 편안함을 제공 할 수 있습니다.

(e) 가능성이 있습니다. 단일 값 데이터로 생각한 것이 미래에 실제로 여러 값이 될 수 있습니다. 예를 들어 신용 한도는 현재 단일 값 필드입니다. 그러나 내일 값을 (시작일, 종료일, 신용 값)으로 변경할 수 있습니다. 이제 분할 테이블이 유용 할 수 있습니다.

내 투표는 데이터가 적절하게 분할 된 여러 테이블에 대한 것입니다.

행운을 빕니다.

---

테이블 결합을 비정규 화라고합니다.

JOIN유지 관리 지옥을 만드는 대신 더 빠르게 실행 되도록 몇 가지 쿼리를 만드는 데 도움이 될 수도 있고 그렇지 않을 수도 있습니다 .

MySQL단지 사용 가능한 JOIN즉, 방법 NESTED LOOPS.

즉, 구동 테이블의 각 레코드 MySQL에 대해 루프의 구동 테이블에서 일치하는 레코드를 찾습니다.

레코드를 찾는 것은 순수한 레코드 스캔보다 수십 배가 걸릴 수있는 상당한 비용이 드는 작업입니다.

모든 레코드를 하나의 테이블로 이동하면이 작업을 제거하는 데 도움이되지만 테이블 자체가 커지고 테이블 스캔이 더 오래 걸립니다.

다른 테이블에 많은 레코드가있는 경우 테이블 스캔이 증가하면 순차적으로 스캔되는 레코드의 이점이 과중해질 수 있습니다.

반면에 유지 보수 지옥은 보장됩니다.

---

모두 1 : 1 관계인가요? 즉, 사용자가 다른 사용자 레벨에 속할 수 있거나 사용자 관심사가 사용자 관심 테이블에서 여러 레코드로 표시되는 경우 해당 테이블을 병합하는 것은 즉시 문제가되지 않습니다.

정규화에 대한 이전 답변과 관련하여 데이터베이스 정규화 규칙은 성능을 완전히 무시하고 깔끔한 데이터베이스 디자인이 무엇인지 만보고 있다고 말해야합니다. 그것은 종종 당신이 성취하고자하는 것이지만, 성능을 추구하기 위해 적극적으로 비정규 화하는 것이 합리적 일 때가 있습니다.

대체로 질문은 테이블에있는 필드의 수와 액세스 빈도에 달려 있습니다. 사용자 활동이 종종 그다지 흥미롭지 않은 경우 성능 및 유지 관리상의 이유로 항상 동일한 기록에 보관하는 것이 성가신 일이 될 수 있습니다 . 예를 들어 설정과 같은 일부 데이터가 자주 액세스되지만 단순히 필드가 너무 많은 경우 테이블을 병합하는 것도 편리하지 않을 수 있습니다. 성능 향상에만 관심이있는 경우 설정을 별도로 유지하고 데이터베이스를 자주 쿼리 할 필요가 없도록 자체 세션 변수에 저장하는 등의 다른 접근 방식을 고려할 수 있습니다.

---

수행 하는 모든 이들 테이블은 한 1-to-1관계는? 예를 들어 각 사용자 행에는 user_stats또는에 해당하는 행이 하나만 user_levels있습니까? 그렇다면 하나의 테이블로 결합하는 것이 합리적 일 수 있습니다. 그러나 관계 가 그렇지 않다면 1 to 1 그것들을 결합 (비정규 화)하는 것은 아마도 말이되지 않을 것입니다.

사용자 레코드가 수십만 또는 수백만 개가 아니라면 별도의 테이블과 하나의 테이블에 두는 것은 성능에 거의 영향을 미치지 않을 것입니다. 실제로 얻을 수있는 유일한 이점은 쿼리를 결합하여 쿼리를 단순화하는 것입니다.

ETA :

If your concern is about having too many columns, then think about what stuff you typically use together and combine those, leaving the rest in a separate table (or several separate tables if needed).

If you look at the way you use the data, my guess is that you'll find that something like 80% of your queries use 20% of that data with the remaining 80% of the data being used only occasionally. Combine that frequently used 20% into one table, and leave the 80% that you don't often use in separate tables and you'll probably have a good compromise.

---

Creating one massive table goes against relational database principals. I wouldn't combine all them into one table. Your going to get multiple instances of repeated data. If your user has three interests for example, you will have 3 rows, with the same user data in just to store the three different interests. Definatly go for the multiple 'normalized' table approach. See this Wiki page for database normalization.

Edit: I have updated my answer, as you have updated your question... I agree with my initial answer even more now since...

a large portion of these cells are likely to remain empty

If for example, a user didn't have any interests, if you normalize then you simple wont have a row in the interest table for that user. If you have everything in one massive table, then you will have columns (and apparently a lot of them) that contain just NULL's.

I have worked for a telephony company where there has been tons of tables, getting data could require many joins. When the performance of reading from these tables was critical then procedures where created that could generate a flat table (i.e. a denormalized table) that would require no joins, calculations etc that reports could point to. These where then used in conjunction with a SQL server agent to run the job at certain intervals (i.e. a weekly view of some stats would run once a week and so on).

---

Why not use the same approach Wordpress does by having a users table with basic user information that everyone has and then adding a "user_meta" table that can basically be any key, value pair associated with the user id. So if you need to find all the meta information for the user you could just add that to your query. You would also not always have to add the extra query if not needed for things like logging in. The benefit to this approach also leaves your table open to adding new features to your users such as storing their twitter handle or each individual interest. You also won't have to deal with a maze of associated ID's because you have one table that rules all metadata and you will limit it to only one association instead of 50.

Wordpress specifically does this to allow for features to be added via plugins, therefore allowing for your project to be more scalable and will not require a complete database overhaul if you need to add a new feature.

---

I think this is one of those "it depends" situation. Having multiple tables is cleaner and probably theoretically better. But when you have to join 6-7 tables to get information about a single user, you might start to rethink that approach.

---

I would say it depends on what the other tables really mean. Does a user_details contain more then 1 more / users and so on. What level on normalization is best suited for your needs depends on your demands.

If you have one table with good index that would probably be faster. But on the other hand probably more difficult to maintain.

To me it look like you could skip User_Details as it probably is 1 to 1 relation with Users. But the rest are probably alot of rows per user?

참고URL : https://stackoverflow.com/questions/1125004/which-is-more-efficient-multiple-mysql-tables-or-one-large-table