특정 IP의 누군가가 투표 한 항목 ID를 추적하고 싶습니다. 그래서 라인을 따라 스키마 :IP 투표 저장 : SQL vs. NoSQL
IP | 투표
IP1 | 563, 342, 343, 654, 12 (항목 ids)
IP2 | 1, 235, 1245, 895, 326
분명히 투표 열의 원 자성을 위반하게되며, 대부분의 사람들은이를 정규화하고 외래 키를 사용하도록 제안 할 것입니다.
하지만 내 문제는 IP 당 1 레코드 만 유지하려고한다는 것입니다. 확장 성이 문제가되고 특정 기간이 지나면 행 수가 심각해질 것이므로 성능이 향상 될 것이라고 생각합니다. 모든 IP1 또는 IP2를 찾기 위해 테이블 전체를 살펴 보는 것은 악몽 일 것입니다.
스키마를 디자인 할 때 초보자이기 때문에 NoSQL과 같은 것이 더 좋을 것입니다. 아니면 거기에 RDBMS 솔루션이 있습니까?
"대부분의 사람들"중 하나 인 사람이 맞습니다. 관계형 무결성과 일관성을 희생시키면서 IP 당 하나의 행을 갖는 것이 어디에서 더 좋을지를 제안하는 스키마는 실제로는 상당히 짧은 순서로 상당한 문제를 일으킬 것입니다. 하지 마. 관계형 데이터베이스는 생각보다 많은 것을 처리 할 수 있습니다. 특히 적절한 인덱싱을 사용하면 더욱 그렇습니다.
NoSQL을 사용해야하는지 여부는 별도의 질문입니다. 주로 개별 IP 주소의 표결에 관심이 있고, 외부 문서에 가입하지 않도록 투표 된 기록을 자체 보유 할 수 있고 조각화에 덜 관심있는 경우 (예 :) 문서 데이터베이스가 적합합니다. 다이 싱 응집체. 당신이 디자인하고있는 것이 무엇인지 모르겠지만, 관계형 접근법이 그것에 충분히 잘 맞을 것으로 생각됩니다.
수천 명의 유권자와 유권자 당 수십 표를 얻었다면, 더 이상 그렇지 않으면 적절한 색인을 작성해도 성능 문제가있을 것이라고 생각합니다. 나는 당신이 언급 한 문서 dabatase에 점점 더 기울고 있습니다. –
user_id/item_id/vote와 같은 간단한 테이블의 경우 땀을 흘리지 않고 수백만 행을 얻을 것으로 기대됩니다. – dmfay
NoSQL 접근 방식을 사용하는 것이 현명한 방법입니까? –
IP 및 표당 한 행씩 적절한 'IPVotes' 테이블을 만드는 지혜롭지 않은 지혜로운 사람이라면 분명히 초보자입니다. –
완전히 :). 이와 비슷한 상황에서 읽을만한 문헌이 있다면 공유 할 수 있습니다. 나는 그것이 많은 사람들을 도울 것이라고 확신합니다. –