موس - أيهما تختار - أكثر من 120 عمودًا إضافيًا، أم قائمة مرتبطة منفصلة؟

Question

لدي مشكلة في التصميم يمكنني الاستفادة من بعض التعليقات بشأنها، لذا آمل أن يتمكن زملائي من خبراء SharePoint من مساعدتي في حل هذه المشكلة.

أنا أدير مجموعة من المشاريع في قائمة MOSS واحدة (القائمة 1)، حيث سيتم التعامل مع عمود "اسم المشروع" على أنه "مفتاح أساسي" (على الأقل في ذهني) للقوائم ذات الصلة.سيكون كل مشروع مرتبطًا به بمجموعة من التسليمات المحددة (ما يصل إلى 37 نشاطًا منفصلاً طوال عمر كل مشروع)، وسيتتبع كل تسليم نشاطًا مهمًا واحدًا يوصى بإكماله خلال المشروع.

كان تفكيري الأولي هو تحديد التسليمات الـ 37 في "قائمة بحث" منفصلة (القائمة 2)، بحيث لا يكون لكل تسليم "اسم تسليم" فحسب، بل أيضًا:

"url" - الارتباط بـ Wiki غير المنفصل ، حيث يمكن للمستخدم العثور على مزيد من المعلومات حول كيفية تحقيق "الوصف" القابل للتسليم خادم منفصل للحصول على أي تفاصيل) "مرحلة المشروع" - لمساعدتنا في التصفية وفرز التسليمات بالترتيب الذي يجب إكماله "دور" - لتحديد دور المشروع الأساسي الذي يمتلك إكمال ما يمكن تسليمه

بعد ذلك، سأقوم بإنشاء عناصر فردية في قائمة أخرى (القائمة 3)، يرتبط كل منها بـ (1) المشروع و(2) عنصر "القالب" في "قائمة البحث عن التسليمات"، حتى نتمكن من تتبع هذه العناصر الإضافية لكل- حقول المشروع/لكل تسليم:

"تاريخ الانتهاء" - التاريخ الذي تم فيه الانتهاء من التسليم (إن وجدت) "كيف يتم التخلص منه" - قائمة منسدلة ، يمكن للمستخدم اختيار حالات مثل "مكتملة" أو "تأجيل" أو "N/A" أو "لا تزال" في العملية "ملاحظات" - نص حرة لتسجيل المزيد من التفسيرات/الأساس المنطقي لما تم القيام به ولماذا

المشكلة الرئيسية الوحيدة في هذا الأسلوب هي أن إرشادات أفضل ممارسات Microsoft لا تشجع بشدة قوائم MOSS التي تحتوي على أكثر من 2000 عنصر في القائمة.حتى لو لم نضيف المزيد من التسليمات إلى كل مشروع، أخشى أننا سوف نتوسع إلى ما هو أبعد من 54 مشروعًا (وهو العدد "المسموح لي" = 2000/37) في وقت قصير جدًا.من الممكن من الناحية النظرية إنشاء مثيلات متعددة من List3، ولكن يبدو لي كابوسًا للأتمتة (مع نمو مجموعة المشاريع المتعقبة الخاصة بي).

البديل الأول الذي يمكنني التفكير فيه هو التحديد المسبق لـ 37 عمودًا إضافيًا في قائمة المشاريع، بالإضافة إلى الأعمدة (37 × 3) اللازمة لتمكين حقول "التاريخ" و"التصرف" و"الملاحظات" التي سيحتاج المستخدمون إليها المسار لكل تسليم.بالإضافة إلى الاضطرار إلى إدارة تكوين/تصميم هش لكل نموذج من نماذج SPD وصفحات أجزاء الويب التي أرغب في استخدامها "لتجميل" واجهة المستخدم لكل إدخال البيانات وإدارة البيانات.

البديل الآخر الذي اقترحه علي أحد الأشخاص هو إنشاء مواقع فرعية لكل مشروع، وسرد تسليمات المشروع في قائمة واحدة في الموقع الفرعي للمشروع.يبدو الأمر ثقيلًا للغاية بالنسبة لي، وأنا أعتبر هذا بمثابة الملاذ الأخير فقط.

كيف يمكن لأي منكم تنفيذ ذلك في MOSS (دون الاعتماد على قاعدة بيانات خارجية، أو أي كود يجب تثبيته على الخادم)؟هل هناك خدعة ما لإنجاز هذا العمل، وهي ليست واضحة من خلال وظيفة قائمة MOSS المعتادة؟هل هناك بعض الميزات المخفية في MOSS التي يجب أن أستخدمها؟بعض الجوانب الأنيقة في SharePoint Designer التي لم أكتشفها بعد؟أنا يملك للاعتقاد بأن العديد من الآخرين واجهوا نفس هذا القيد، واكتشفوا ذلك بعض طريقة لجعلها تعمل.سأكون ممتنًا لأية أفكار يمكن أن تقترحها أيها الأشخاص - شكرًا مقدمًا!

Answer 1

في تجربتي، فإن الذهاب إلى أكثر من 2000 عنصر لكل حاوية (قائمة، مجلد، عنصر مفهرس) ليس نهاية العالم.لكن ما هو أسوأ من ذلك هو أنك إذا بدأت في استخدام قوائم متعددة مرتبطة ببعضها البعض (عادةً من خلال عمليات البحث).ثم يصبح الأمر مؤلمًا للغاية عندما تريد تصفية طفل بناءً على قيمة في الأصل الخاص به والتي لا تشكل جزءًا من البحث.يمكن أن يكون إعداد التقارير حول هذه البيانات بطيئًا جدًا إذا كان لديك الكثير من السجلات المشاركة في عملية الانضمام.

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

Answer 2

تنص أفضل ممارسات Microsoft على أنه، لأسباب تتعلق بالأداء، يجب ألا يكون لديك أكثر من 2000 عنصر في ملف منظر;من الممكن أن يكون لديك ملايين العناصر في القائمة، ولكن يجب عليك تحديد طرق العرض الخاصة بك بعناية واستخدام أعمدة الفهرس لإرجاع أقل من 2000 عنصر فقط في المرة الواحدة.

إذا كانت بيانات قائمتك لا تتغير كثيرًا ولديك قدر كبير من الذاكرة المتوفرة على الخادم، فمن المفيد النظر إلى PortalSiteMapProvider للاستعلام عن القوائم.يمكن العثور على مزيد من المعلومات حول الطرق المختلفة للاستعلام عن القوائم ومستند معلومات مقارن كامل هنا.

هتافات!

Answer 3

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

والمشورة MS هو يبدأ أداء تعاني إذا كنت تستخدم أكثر من 50،000 مجموعات الموقع، لذلك هناك بعض المرونة هناك. مواقع فرعية يمكن أن تصبح بسرعة لا يمكن السيطرة عليها عند تخزين العديد من الوثائق كما لا توجد وسيلة جيدة لنقل موقع فرعي بين قواعد بيانات المحتوى عندما تنمو قاعدة بيانات محتوى كبيرة جدا.

وأعتقد أن مجموعة الموقع في العمارة مشروع تعطيك المزيد من المرونة وabvoid القضايا سيئة مع القوائم بحث معقدة. وسوف تعتمد على استخدام بعض ذكي إلى حد ما من جزء الويب نتائج البحث ولكن.

Answer 4

و"MOSS القوائم مع> 2000 البنود في قائمة"

وهذه ليست مشكلة كما هو بالضبط ما كنت تظهر في طريقة عرض. أعتقد MOSS ليس plattform تطوير لإضافة زارة التربية والتعليم العناصر المعقدة مع المزيد من المجالات. يجب أن أقوم به تطبيق SQLSERVER ASP.NEt العادي