تخزين الوثائق النقط في قاعدة البيانات - أي عيوب ؟

Question

متطلبات بلدي نظام إدارة الوثائق هي:

1. يجب أن تكون آمنة من السرقة عن طريق نسخ بسيطة من الدلائل والملفات وما إلى ذلك.
2. يجب أن تكون آمنة ضد الفيروسات التقليدية العدوى (العدوى المادية الملف)
3. يجب أن تكون سريعة لاسترداد
4. مستودع يجب أن لا تكون مرئية عارضة (الدليل) تصفح المستخدمين وما إلى ذلك.

لقد قررت لتخزين جميع الوثائق (و الصور الممسوحة ضوئيا) كما النقط في قاعدة البيانات حتى الآن تجربتي الرائعة واسترجاع الوثائق هو تمام الوضوح سريع كذلك - أنه يلبي جميع المعايير من فوق بل هناك زوجين من المزايا الإضافية مثل autostoring الوثائق جنبا إلى جنب مع الكيان صلته, سهلة وسريعة الإعلان عن محتويات إزالة جميع أنواع أنشطة المستخدم حول فتح تسمية المستندات الخ.الخ.

سؤالي هو: - هل هناك أي مخاطر جدية أو الأشياء التي أشرفت مع هذا التصميم و التنفيذ ؟

تحرير ملاحظة:DB هي كيو, مقابض النقط بشكل جيد جدا و جداول جيدا بشكل استثنائي.في بيئة متعددة المستخدمين.

Answer 1

عندما DB الخاص بك تنمو أكبر وأكبر أنها سوف تصبح أكثر صعوبة النسخ الاحتياطي.استعادة نسخة احتياطية من الجدول مع أكثر من 100 جيجابايت من البيانات لا شيء يجعلك سعيدة.

شيء آخر هو أن كل طاولة إدارة المهام الحصول على أبطأ وأبطأ كما dataset ينمو.
ولكن يمكن التغلب على ذلك عن طريق جعل جدول البيانات فقط تحتوي على حقول 2:معرف النقطة.

استرجاع البيانات (عن طريق مفتاح أساسي) من المرجح أن تصبح مشكلة طويلة بعد ضرب الحائط مع النسخ الاحتياطي قاعدة البيانات.

Answer 2

العيب الرئيسي أنني كثيرا ما نسمع من استخدام النقط التي فوق حجم معين, ملف النظام هو أكثر من ذلك بكثير كفاءة في تخزين واسترجاع الملفات الكبيرة.يبدو وكأنه كنت قد اتخذت بالفعل هذا الحساب من خلال قائمة من المتطلبات.

هناك جيد الإشارة (PDF) هنا التي تغطي إيجابيات وسلبيات من النقط.

Answer 3

من تجربتي بعض المسائل:

1. السرعة مقابل وجود الملفات على نظام الملفات.

2. التخزين المؤقت.المنظمة البحرية الدولية ملقم ويب سوف نقوم بعمل أفضل من التخزين المؤقت محتويات ثابتة.DB سوف تفعل عمل جيد جدا, ولكن إذا كان DB هو أيضا تسليم جميع أنواع أخرى من الاستفسارات ، لا تتوقع تلك المستندات الكبيرة البقاء مؤقتا لفترة طويلة.لك بشكل أساسي إلى نقل الملفات مرتين.مرة واحدة من DB إلى ملقم ويب ثم ملقم ويب العميل.

3. القيود الذاكرة.في عملي الأخير كان لدينا 40MB PDF في قاعدة البيانات ، وأبقى على جافا OutOfMemoryErrors في ملف السجل.لقد أدركت في نهاية المطاف أن كل 80MB PDF قراءة في كومة ليس مرة واحدة فقط بل مرتين بفضل الإعداد في السبات ORM (إذا كان كائن غير قابلة للتغيير ، يجعل نسخة للتحرير في الذاكرة).مرة PDF كان المتدفقة إلى المستخدم ، كومة تم تنظيفها ، ولكن كان ضربة كبيرة لامتصاص 80MB للخروج من كومة مرة واحدة فقط إلى تيار وثيقة.تعرف الكود وكيف الذاكرة يتم استخدامها!

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

Answer 4

لقد بدأت البحث في SQL Server 2008 FILESTREAMing عن النقط و تشغيل عبر ضخمة القيد (IMO)--أنها لا تعمل إلا مع الأمن المتكاملة.إذا كنت لا تستخدم مصادقة Windows للاتصال DB server, أنت غير قادر على قراءة/كتابة النقط.العديد من بيئات التطبيقات لا يمكن استخدام مصادقة windows.بالتأكيد ليس في بيئات غير متجانسة.

أفضل حل لتخزين النقط يجب أن يكون موجودا.ما هي أفضل الممارسات ؟

Answer 5

هذا المادة يغطي معظم القضايا.إذا كنت تستخدم SQL Server 2008, تحقق من استخدام new FILESTREAM نوع كما نوقش من قبل بول راندال هنا.

Answer 6

ذلك يعتمد على databasetype.أوراكل أو SQLServer?يكون على بينة من عيب واحد - استعادة وثيقة واحدة.

Answer 7

آسف - الجواب عرضت يستند إلى SQL Server حتى الجزء الصيانة غير مناسب.ولكن ملف I/O هو إنجاز على مستوى الأجهزة و أي قاعدة بيانات يضيف المزيد من خطوات المعالجة.

قاعدة البيانات سوف تفرض الحمل الزائد عند استرداد الوثيقة.عندما يكون الملف على القرص أنت بطيء أو سريع مثل I/O على الملقم.أنت بالتأكيد أن إدارة ميتا في قاعدة البيانات ، ولكن في النهاية كنت تريد UNC الملف وتوجيه المستخدم إلى المصدر والحصول على للخروج من الطريق.

من صيانة منظور الإدارة سوف تحد نفسك إلى سان عند التعامل مع MS SQL Server.حلول مثل Documentum اتخاذ نهج مختلف مع بسيطة التخزين على القرص يسمح لك لتنفيذ حل تخزين النحو الذي تراه مناسبا.

تحرير

اسمحوا لي توضيح بياني - مع SQL Server لديك خيارات محدودة عندما تتجاوز سعة التخزين الفعلية من مربع.هذا هو في الواقع واحدة من أكبر نقاط الضعف في Sharepoint التي لم تكن قادرة على ببساطة إرفاق أي نوع من التخزين على الشبكة.

Answer 8

من ما لقد شهدت تخزين محتوى الملفات كما النقط في كل من SQL Server و Oracle و يعمل على ما يرام مع قاعدة بيانات صغيرة مع عدد قليل من المستخدمين المسجلين.ECM نظام منفصل لهم استخدام خدمات منفصلة عن تدفق المحتوى.اعتمادا على حجم الملفات موارد الخادم يمكن أن تكون أثرت في وقت واحد مع استرجاع الملفات الكبيرة.أرشيف قواعد البيانات مع مجموعات كبيرة من الملفات يصبح مشكلة بسبب الوقت لاستعادة وعدم القدرة على استرجاع الوثائق شكل الأرشيف.

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

قد ترغب في التحقيق في نظام إدارة المحتوى مع API من نوع ما, بدلا من إعادة اختراع العجلة.