데이터베이스 및 테이블 관리

Question

웹 응용 프로그램을 만들었으며 확장하려고합니다. 내 웹 응용 프로그램에는 사용자가 관리자인지 여부, 페이지의 동적 내용 섹션에 대한 매우 작은 테이블 및 웹 사이트에서 "이벤트"를 추적하기위한 테이블을 추적 할 수있는 권한이있는 사용자 용 테이블이 있습니다.

웹 응용 프로그램 제작 경험이 거의 없기 때문에 전문가가 웹 응용 프로그램 용 데이터베이스 및 테이블 시스템을 만드는 방법에 대해서는 잘 모르겠습니다. 내 웹 응용 프로그램에서는 웹 사이트의 각 구성원 및 메시징 시스템에 대한 사용자 설정을 추가 할 계획입니다. 현재 모든 명령에 대해 쿼리하는 MySQL 데이터베이스와 함께 PHP를 사용하지만 필요한 경우이 옵션을 기꺼이 변경할 수 있습니다. 대인 관계의 메시지 및 각 사용자의 특정 사용자 설정과 같은 콘텐츠를 추적하는 가장 좋은 방법은 무엇입니까? 언제든지 여러 개의 데이터베이스를 갖고 싶습니까? 각 사용자마다 여러 개의 테이블을 갖고 싶을 것입니까? 이것이 어떻게 행해지거나 행해져 야하는지에 관한 정보는 매우 도움이 될 것입니다.

질문의 범위가 넓어서 미안하지만, 테이블 사용에 대한 아이디어가 프로그래머가 가진 아이디어와 동등하지 않다고 생각하기 때문에이 웹 응용 프로그램을 개혁하고 싶습니다. 고맙습니다!

Answer 1

귀하의 질문에 내 보이는 긴, 희망 너무 복잡한 대답입니다. 나는 당신의 모든 질문이 아니더라도 대부분을 다루었다고 생각합니다.

웹 응용 프로그램의 경우 "사용자"라고하는 사용자 테이블, "UserSettings"라는 설정 테이블 또는 설명적인 것과 동일한 메시지, "PrivateMessages"테이블의 메시지를 가질 수 있습니다. 그런 다음 필요한 추가 데이터를 저장하는 하위 테이블이있을 수 있습니다.

사용자 보안은 설계하고 구현하는 것이 까다로운 작업 일 수 있습니다. 그룹 단위로 (많은 사용자를두고 권한을 관리하기가 더 간편한 경우) 또는 작은 사용자 기반으로 개별적으로 할당하기를 원하십니까? 혼자 보안을 위해 4 개 테이블로 끝날 것 :

Users 
UserSettings 
UserGroups 
UserAssignedGroups 

그런 식으로 당신은 사용자 정보, 설정, 그들이에 할당 할 수있는 그룹과 그들이 제대로 분리에 할당을 가질 수 있습니다. 이것은 유연성을 제공하고 표준화 표준을 준수합니다 (DrSAR에서 언급 한 바와 같습니다).

메시지에는 사용자 이름 대신 사용자 ID를 저장하십시오. 예를 들어 PrivateMessages 테이블에서 가장 기본적인 정보를 저장하기 위해 MessageID, SenderUserID, RecipientUserID, Subject, Body 및 DateSent가 있습니다.

이

SELECT * FROM PrivateMessages WHERE RecipientUserID = 123556 

메시지의 테이블 목록과 같은 수 :

PrivateMessages 
MessageReplies 

PrivateMessages 테이블이 할 수있는 사용자가 자신의 수신 메시지를 확인하고자 할 때 그런 식으로, 당신은 말을 테이블을 조회 할 수 있습니다 상위 메시지를 저장하면 MessageReplies 테이블은 후속 회신을 저장할 수 있습니다. 모든 테이블을 하나의 테이블에 저장할 수 있지만 트래픽에 따라 가능하면 하나의 테이블에서 모든 메시지와 응답을 검색하는 재귀 함수를 작성하는 경우 두 테이블 접근 방식이 가장 간단합니다.

내가 너라면 필자는 연필과 종이에 앉아서 내 데이터베이스에서 추적하고 싶은 것을 적어 두었다. 그런 식으로 당신은 당신이 저장하고 싶은 것들 사이에 링크를 그릴 수 있고 그것이 어떻게 함께 올지를 볼 수 있습니다. 나는 물건을 시각화하려고 할 때 도움이됩니다.

Answer 2

웹 응용 프로그램의 범위에는 여러 개의 데이터베이스가 필요하지 않습니다. 그러나 데이터를 효율적으로 저장하려면 여러 테이블이 필요합니다.

사용자 설정의 경우 항상 별도의 테이블을 사용하십시오. 사용자가 로그인을 시도 할 때마다 액세스 (= 검색) 될 것이기 때문에 "메인"사용자 테이블을 최대한 가급적 싶습니다. 상점 ID, 사용자 이름, 암호 (물론 해시 된) 및 인증 할 때 액세스해야합니다. 모든 추가 정보를 별도의 테이블에 넣으십시오. 그렇게하면 로그인이 작은 테이블 만 쿼리하게되고 사용자가 인증되면 ID를 사용하여 보조 테이블의 다른 모든 정보를 얻을 수 있습니다.

메시지는 더 큰 순서이므로 더 까다로울 수 있습니다. 각 사용자마다 수십 또는 수백 개의 메시지가있을 수 있습니다. 애플리케이션의 로직을 기반으로 테이블 구조를 설계해야합니다. 각 사용자에 대한 표는 분명히 실현 가능한 해결책이 아니므로 일반 메시지 표를 살펴 보지만 관리 가능한 크기로 유지하는 절차를 구현하십시오. 예를 들어 X 일보다 오래된 메시지를 "보관 ​​처리"하여 다른 테이블로 옮길 수 있습니다 (사용자가 이전 메시지에 너무 자주 액세스하지 않을 경우 잘 작동 함). 하지만 제가 말씀 드렸듯이, 그것은 당신의 어플리케이션에 달려 있습니다.

행운을 빈다.

Answer 3

Cristian Radu의 의견에 따르면 데이터를 다른 테이블로 분할해야합니다. 희박한 사용자 테이블은 실제로 사용자 당 하나의 고유 한 ID를가집니다. 이 (고유 한) 키는 보조 테이블에서 반복되어야합니다. 그런 다음 외부 키라고합니다. 분명히, 당신은 유일한 열쇠를 원한다. 사용자 이름이 고유 한 것으로 보장 될 수있는 경우 (즉, 이메일 주소로 사용자를 식별해야하는 경우) 사용할 수 있습니다. 사용자 이름이 실제 이름 (예 : Firstname Sirname) 인 경우 해당 보증이 없으며 사용자 키를 유지해야합니다. 마찬가지로, 게시물을 포함하는 테이블은 누가 그것을 작성했는지를 나타내는 고유 한 사용자 ID가있는 필드를 가질 수 있습니다 (그러나 가질 필요는 없습니다).

정규화 개념과 데이터베이스 디자인에 대해 약간 읽으십시오. : //dev.mysql.com/tech-resources/articles/intro-to-normalization.html) 정상화의 n 번째 형태로 수렁에 빠질 필요는 없지만,이 단계에서 당신이 필요로하는 것을 도울 것입니다 밖으로 데이터베이스 디자인.

행운을 빌어 다시보고 여기 ;-)