مخطط Wiki عالية الأداء

Question

أنا أستخدم MS SQL Server 2005.

ما هو أفضل مخطط لنظام مثل Wiki؟ حيث يقوم المستخدمون في تحرير / مراجعة التقديم والنظام تتبع هذه الطلبات.

دعنا نقول أننا نقوم بنظام بسيط يستند إلى الويكي. سوف تتبع كل مراجعة بالإضافة إلى وجهات النظر وأحدث نشاط كل مراجعة. في شاشات أخرى، سيقوم النظام بإدراج "أحدث التقديمات" و "الأكثر عرضة"، بالإضافة إلى البحث حسب العنوان.

مخططي الحالي (وأنا أعرف سيئها) يستخدم طاولة واحدة. عندما أحتاج إلى رؤية "أحدث التقديمات" أنا فرز حسب "أحدث"، Group by "Documenttitle"، ثم اتخاذ سجلات N أولا. أفترض الكثير من التجمع (خاصة التجمع على NVARCHAR) هو الأخبار السيئة. للحصول على الإدراج الأكثر تعاوضا، أفعل أيضا نفس الشيء: الترتيب حسب المشاهدات، المجموعة حسب الاسم، خذ سجلات N الأولى. معظم الوقت، سأقوم أيضا بعمل "حيث اسم المستند مثل"٪ "٪ هنا٪".

مخططي الحالي هو "الإصدار 1"، انظر أدناه:النص البديل http://www.anaimi.com/junk/schemaquestion.png.

أفترض أن هذا غير مقبول. لذلك أحاول التوصل إلى تصميم آخر / أكثر أداء. كيف يبدو لك الإصدار 2؟ في الإصدار الثاني، أحصل على ميزة التجميع على WikiHeadID وهو رقم - أفترض أن التجميع عبر رقم أفضل من NVARCHAR.

أو الحالة القصوى التي هي الإصدار 3، حيث لن أفعل أي مجموعة، ولكن لديها العديد من العيوب مثل القيم المكررة، والحفاظ على هذه القيم في التعليمات البرمجية، إلخ.

أو هل هناك مخطط أفضل / معروف لهذه الأنظمة؟

شكرا.

(انتقل من ServerFault - أعتقد أن سؤال التنمية أكثر من سؤال تكنولوجيا المعلومات)

Answer 1

أولا (وخارج الفضول) كيف يشير المخطط الحالي إلى ما هو الإصدار الحالي؟ هل لديك فقط إدخالات "Wikidocument" متعددة مع نفس الوثيقة؟

أنا أيضا غير واضح حول سبب الحاجة إلى "عدم النشاط" على مستوى الإصدار. لا أرى كيف يناسب "عدم النشاط" بمفهوم "الإصدار" عظم Wikis، يتم كتابة "الإصدارات" مرة واحدة: إذا قمت بتعديل إصدار، فأنت تقوم بإنشاء الجديد الإصدار، لذلك فإن مفهوم قيمة نوع آخر تحديث على الإصدار لا معنى له - إنه حقا "تاتير".

حقا، المخطط "الطبيعي" لتصميمك هو # 2. شخصيا، أنا قليلا من محبي تطبيع AXIOM DB القديم حتى يؤلمني، ثم تنظف حتى يعمل ". # 2 عبارة عن تصميم منظف وأجهزة أجمل (بسيطة، مع عدم وجود ازدواجية)، وإذا لم يكن لديك أي سبب عاجل للإشارة إلى الإصدار 3، فلن أزعجني.

في نهاية المطاف، يتعلق الأمر بذلك: هل تقلق بشأن تصميم "المزيد من الأداء" لأنك لاحظت مشاكل في الأداء، أو لأنك افترضت ربما لدينا بعض؟ لا يوجد سبب حقيقي # 2 لا ينبغي أن يؤدي جيدا. التجميع ليس بالضرورة الأخبار السيئة في SQL Server - في الواقع، إذا كان هناك فهرس تغطية مناسب للاستعلام، فيمكنه إجراء جيد للغاية لأنه يمكن أن ينتقل فقط إلى مستوى معين في الفهرس للعثور على القيم المجمعة، ثم استخدم الأعمدة المتبقية من الفهرس لاستخدامها إلى MIN / MAX / أيا كان. Grouping By Nvarchar غير سيء بشكل خاص - إذا لم يلاحظ أن تكون مشكلة، فلا تقلق بشأنها، على الرغم من (غير ثنائي) يمكن أن تجعلها صعبة بعض الشيء - ولكن في الإصدار 2، حيث تحتاج إلى المجموعة بواسطتك يمكنك أن تفعل ذلك بواسطة WikiHeadid، أليس كذلك؟

شيء واحد قد يجعل الحياة أسهل، إذا كنت تفعل الكثير من العمليات على الإصدار الحالي (كما أفترض أنك سوف تفعل)، لإضافة FK مرة أخرى من جدول الرأس إلى جدول الجسم، مما يشير إلى الإصدار الحالي. إذا كنت ترغب في عرض الإصدارات الحالية مع أعلى عدد من الزيارات، مع رقم 2 كما هو الحال الآن قد يكون:

SELECT TOP ...
FROM WikiHead
INNER JOIN 
  (SELECT WikiHeadId, MAX(WikiBodyVersion) /* or LastUpdated? */ AS Latest 
   FROM WikiBody GROUP BY WikiHeadId) AS LatestVersions
INNER JOIN WikiBody ON 
  (Latest.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiBody.WikiBodyVersion = LatestVersions.Latest)
ORDER BY 
  Views DESC

أو بدلا من ذلك

...
INNER JOIN WikiBody ON 
  (WikiHead.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiBody.WikiBodyVersion = 
    (SELECT MAX(WikiBodyVersion) FROM WikiBody WHERE WikiBody.WikiHeadId = WikiHead.WikiHeadId)
...

كلاهما icky. إذا كان Wikihead يحتفظ بمؤشر إلى الإصدار الحالي، فهذا فقط

...    
INNER JOIN WikiBody ON 
  (WikiHead.WikiHeadId = WikiBody.WikiHeadId)
  AND (WikiHead.Latest = WikiBody.WikiBodyVersion)
...

أو أيا كان، مما قد يكون إنكارا مفيدا لأنه يجعل حياتك أسهل، وليس للأداء.

Answer 2

يفحص هذه خارج.

انها مخطط قاعدة البيانات ل ميدياويكي, ، ما الذي يستند إلى ويكيبيديا.

تبدو موثقة جيدا وستكون قراءتها مثيرة للاهتمام لك.

من هذا صفحة.