أفضل طريقة (مجانية) لتخزين البيانات؟ماذا عن التحديثات لنظام الملفات؟

Question

لدي فكرة عن كيفية حل هذه المشكلة، ولكني أردت معرفة ما إذا كان هناك شيء أسهل وأكثر قابلية للتوسيع لمشكلتي.

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

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

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

هل يوجد مثل هذا المخطط في C#؟مثل، إذا كان لدي فئة عبارة عن مجموعة من كائنات String وInt، ثم أضفت كائن سلسلة آخر إلى البنية، فكيف يمكنني إلغاء تسلسل كائن من القرص، ثم إضافة السلسلة إليه؟هل أحتاج إلى الاستقالة من وجود إصدارات متعددة من فئات البيانات، ومصنع يأخذ دفق إلغاء التسلسل ويتعامل مع إلغاء التسلسل بناءً على بعض معلومات الإصدار المخزنة في فئة أساسية؟أم أن فئة مثل القاموس مثالية لتخزين هذا النوع من المعلومات، حيث إنها ستقوم بإلغاء تسلسل جميع الحقول الموجودة على القرص تلقائيًا، وإذا كانت هناك حقول جديدة مضافة، يمكنني فقط التقاط الاستثناءات واستبدالها بسلاسل و Ints فارغة لتلك القيم؟

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

شكرًا!

Answer 1

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

فيما يلي قائمة سريعة بالتطبيقات التي أعرفها لـ C#/.NET:

• شبكة بروتوبوف
• بروتو#
• jskeet's dotnet-protobufs

Answer 2

سكليتي هو ما تريد.إنها قاعدة بيانات سريعة وقابلة للتضمين وذات ملف واحد ولها روابط لمعظم اللغات.

فيما يتعلق بقابلية التوسعة، يمكنك تخزين نماذجك بالسمات الافتراضية، ومن ثم الحصول على جدول منفصل لامتدادات السمات للتغييرات المستقبلية.

بعد عام أو عامين، إذا كان الكود لا يزال قيد الاستخدام، فسوف يسعدك أن 1) لن يضطر المطورون الآخرون إلى تعلم بنية تعليمات برمجية مخصصة للحفاظ على الكود، 2) يمكنك تصدير وعرض وتعديل البيانات باستخدام أدوات قاعدة البيانات القياسية (يوجد برنامج تشغيل ODBC لملفات sqlite وأدوات استعلام متنوعة)، و3) ستتمكن من الارتقاء إلى قاعدة بيانات مع الحد الأدنى من تغييرات التعليمات البرمجية.

Answer 3

مجرد كلمة تحذير بسيطة، SQLLite، Protocol Buffers، mmap وما إلى ذلك... كلها جيدة جدًا ولكن يجب عليك إنشاء نموذج أولي واختبار كل تطبيق والتأكد من أنك لن تواجه نفس مشكلات الأداء أو اختناقات مختلفة.

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

Answer 4

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

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

Answer 5

أنا لست مبرمجًا في لغة C# ولكني أحب استدعاء mmap() ورأيت أن هناك مشروعًا يقوم بهذا الشيء لـ C#.

يرى Mmap

تكون الملفات المنظمة ذات أداء عالٍ إذا تم تخصيصها لتطبيق معين ولكن يصعب إدارتها ومصدر تعليمات برمجية يصعب إعادة استخدامه.الحل الأفضل هو تنفيذ يشبه الذاكرة الافتراضية.

• يمكن إدارة ما يصل إلى 4 جيجابايت من المعلومات.
• يمكن تحسين المساحة لتناسب حجم البيانات الحقيقي.
• يمكن عرض جميع البيانات كمصفوفة واحدة ويمكن الوصول إليها من خلال عمليات القراءة/الكتابة.
• لا حاجة إلى هيكلة للتخزين ولكن مجرد الاستخدام والتخزين.
• يمكن تخزينها مؤقتا.قابلة لإعادة الاستخدام بدرجة كبيرة.

Answer 6

لذا استخدم sqllite للأسباب التالية:
1.لا تحتاج إلى قراءة/كتابة قاعدة البيانات بأكملها من القرص في كل مرة
2.من السهل جدًا الإضافة إليها حتى لو لم تترك عددًا كافيًا من العناصر النائبة في البداية
3.أسهل للبحث بناء على أي شيء تريده
4.تم تصميم أسهل لتغيير البيانات بطرق تتجاوز التطبيق

مشاكل مع نهج القاموس
1.ما لم تقم بإنشاء قاموس ذكي، فستحتاج إلى قراءة/كتابة قاعدة البيانات بأكملها في كل مرة (ما لم تقم بتصميم بنية البيانات بعناية، سيكون من الصعب جدًا الحفاظ على التوافق مع الإصدارات السابقة)
----- أ) إذا لم تترك عددًا كافيًا من الأماكن، وداعًا
2.يبدو كما لو كان عليك إجراء بحث خطي عبر جميع الصور من أجل البحث عن إحدى سمات الالتقاط
3.هل يمكن أن تكون الصورة في أكثر من مجموعة؟هل يمكن أن تكون الصورة تحت أكثر من شخص؟هل يمكن لشخصين أن يكونا في نفس المجموعة؟مع القواميس يمكن أن تصبح هذه الأشياء مشعرة....

باستخدام جدول قاعدة البيانات، إذا حصلت على سمة جديدة، يمكنك فقط قول Alter Table Picture Add Attribute DataType.وطالما أنك لم تضع قاعدة تنص على أن السمة يجب أن تكون لها قيمة، فلا يزال بإمكانك تحميل الإصدارات الأقدم وحفظها.وفي الوقت نفسه، يمكن للإصدارات الأحدث استخدام السمات الجديدة.

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

ربما ينبغي أن يكون الجدول الخاص بك
الصورة (معرف الصورة، معرف المجموعة؟، مسار الملف، معلمة الالتقاط 1، معلمة الالتقاط 2، إلخ..)

إذا كنت تريد المزيد من المرونة ، فيمكنك إنشاء جدول CaptureParameter (PictureId ، parameTername ، Parametervalue) ...أنصح بعدم القيام بذلك لأنه أقل كفاءة بكثير من مجرد وضعها في جدول واحد (ناهيك عن أن الاستعلامات لاسترداد/البحث في معلمات الالتقاط ستكون أكثر تعقيدًا).

الشخص (PersonID، أي سمات شخص مثل الاسم/إلخ.)
المجموعة (معرف المجموعة، اسم المجموعة، معرف الشخص؟)
مجموعة الأشخاص؟ (معرف الشخص، معرف المجموعة)
PictureGroup؟ (معرف المجموعة، معرف الصورة)