Anket için veritabanı tasarımı [kapalı]

Cevapların bir veritabanında depolandığı bir anket oluşturmam gerekiyor. Bunu veritabanında, özellikle de gerekli olan tablolarda uygulamanın en iyi yolunun ne olacağını merak ediyorum. Anket farklı türde sorular içerir. Örneğin: yorumlar için metin alanları, çoktan seçmeli sorular ve birden fazla yanıt içerebilecek olası sorular (yani, uygun olan tüm seçenekleri işaretleyin).

İki olası çözüm buldum:

1. Her anket gönderimi için cevapları içeren dev bir tablo oluşturun. Her sütun anketteki bir cevaba karşılık gelir. ör. Anket Kimliği, Cevap1, Cevap2, Cevap3

   Bu ankette çok fazla soru olduğundan ve anket değişecekse çok esnek görünmediğinden bunun en iyi yol olduğunu düşünmüyorum.

2. Düşündüğüm diğer şey bir Soru tablosu ve Cevap tablosu oluşturmaktı. Soru tablosu, anket için tüm soruları içerecektir. Cevap tablosu, her satır bir soruya bağlanan anketteki bireysel cevapları içerecektir.

   Basit bir örnek:

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID, UserID , QuestionID , Answer

   tblUser : Kullanıcı Kimliği, KullanıcıAdı

   Bununla ilgili sorunum, Cevap tablosunu oldukça büyük hale getirecek tonlarca cevap olabilmesidir. Performans söz konusu olduğunda bu kadar harika olduğundan emin değilim.

Herhangi bir fikir ve öneriyi takdir ediyorum.

2 numaralı modelinizin iyi olduğunu düşünüyorum, ancak soruları ve önceden hazırlanmış cevapları (sunulan cevaplar) saklayan ve farklı anketlerde yeniden kullanılmalarına izin veren daha karmaşık modele göz atabilirsiniz.

- Bir ankette birçok soru olabilir; bir soru birçok ankette (yeniden) kullanılabilir.
- Birçok soru için bir (önceden hazırlanmış) cevap verilebilir. Bir sorunun birçok cevabı olabilir. Bir sorunun farklı anketlerde farklı yanıtları olabilir. Farklı anketlerde farklı sorulara cevap verilebilir. Varsayılan bir "Diğer" yanıtı vardır, bir kişi diğerini seçerse, yanıtı Answer.OtherText'e kaydedilir.
- Bir kişi birçok ankete katılabilir, bir kişi bir anketteki belirli bir soruyu yalnızca bir kez yanıtlayabilir.

Tasarımım aşağıda gösterilmiştir.

En son oluşturulan komut dosyası https://gist.github.com/durrantm/1e618164fd4acf91e372 adresindedir.

Komut dosyası ve mysql workbench.mwb dosyası da https://github.com/durrantm/survey adresinde mevcuttur.

Kesinlikle seçenek # 2, ayrıca mevcut şemada bir gözetiminiz olabileceğini düşünüyorum, başka bir tablo isteyebilirsiniz:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

Her soru, muhtemelen kullanıcının seçebileceği belirli bir cevap sayısına sahip olacak, ardından gerçek yanıtlar başka bir tabloda izlenecektir.

Veritabanları çok fazla veri depolamak için tasarlanmıştır ve çoğu çok iyi ölçeklenir. Artık sadece yerden tasarruf etmek için daha az normal bir form kullanmaya gerek yoktur .

Genel bir kural olarak, bir kullanıcının değiştirebileceği bir şeye dayalı olarak şemayı değiştirmek (bir ankete soru eklemek gibi) oldukça kötü kokulu kabul edilmelidir. Özellikle büyük miktarda veriyle uğraşırken, ancak dalmadan önce neye bulaştığınızı bilin. Her anket için yalnızca bir "yanıtlar" tablosuna sahip olmak, soru eklemenin veya çıkarmanın potansiyel olarak çok maliyetli olduğu anlamına gelir ve sorudan bağımsız bir şekilde analitik yapmak çok zordur.

İkinci yaklaşımınızın en iyisi olduğunu düşünüyorum, ancak çok fazla ölçek endişeniz olacağından eminseniz, geçmişte benim için işe yarayan bir şey karma bir yaklaşımdır:

1. 2. adımda açıkladığınız gibi soru başına yanıtları depolamak için ayrıntılı yanıt tabloları oluşturun. Bu veriler genellikle uygulamanızdan doğrudan sorgulanmaz, ancak raporlama tabloları için özet veriler oluşturmak için kullanılır. Muhtemelen bu veriler için bir tür arşivleme veya silme işlemi uygulamak isteyebilirsiniz.
2. Ayrıca gerekirse 1'den yanıtlar tablosunu oluşturun. Bu, kullanıcılar sonuçlar için basit bir tablo görmek istediklerinde kullanılabilir.
3. Raporlama amacıyla yapılması gereken herhangi bir analitik için, 1'den alınan verilere dayalı olarak ek özet veriler oluşturmak için işleri planlayın.

Bu kesinlikle uygulanması gereken çok daha fazla iş, bu yüzden bu tablonun büyük ölçekli endişelerle karşılaşacağından emin değilseniz bunu gerçekten tavsiye etmem.

İkinci yaklaşım en iyisidir.

Daha fazla normalleştirmek istiyorsanız, soru türleri için bir tablo oluşturabilirsiniz.

Yapılması gereken basit şeyler:

• Veritabanını yerleştirin ve kendi disklerinde oturum açın, varsayılan olarak tümü C'de değil
• Veritabanını gerektiği kadar büyük oluşturun, böylece veritabanı büyürken duraklamalarınız olmaz

SQL Server Tablosunda 10 milyon satırlık log tablolarımız var.

2 yok.

Yalnızca 4 sütunlu bir tablo için, birkaç milyon satır olsa bile sorun olmamalıdır. Elbette bu, kullandığınız veritabanına bağlı olabilir. SQL Server gibi bir şeyse o zaman sorun olmaz.

Muhtemelen tblAnswer tablosundaki Soru Kimliği alanında bir dizin oluşturmak istersiniz.

Elbette, hangi Veritabanını kullandığınızı ve tahmini hacimleri belirtmeniz gerekir.

Basit bir anket için oldukça eksiksiz görünüyor. Bir müşterinin görüşünü bir metin kutusu aracılığıyla sağlayabileceği 'açık değerler' için bir tablo eklemeyi unutmayın. Bu tabloyu bir yabancı anahtarla cevabınıza bağlayın ve performans için tüm ilişkisel sütunlarınıza dizinleri yerleştirin.

2 numara doğru. Bir performans sorunu tespit edene kadar doğru tasarımı kullanın. Çoğu RDBMS, dar ama çok uzun bir tabloyla sorun yaşamaz.

Kendi başına büyük bir Cevap tablosuna sahip olmak bir problem değildir. Dizinler ve kısıtlamalar iyi tanımlandığı sürece iyi olmalısınız. İkinci şemanız bana güzel görünüyor.

Uygun indeks verildiğinde, ikinci çözümünüz normalleştirilir ve geleneksel bir ilişkisel veritabanı sistemi için iyidir.

Ne kadar büyük olduğunu bilmiyorum ama birkaç milyon cevabı sorunsuz tutmalı.

Tüm formu bir JSON dizesi olarak saklamayı seçebilirsiniz.

İhtiyacınızdan emin değilim, ancak bu yaklaşım bazı durumlarda işe yarayabilir.