.NET Data Storage - قاعدة البيانات مقابل ملف واحد

Question

لديّ تطبيق C# يسمح للمستخدم بإدخال معلومات حول العملاء ومواقع الوظائف. المعلومات أساسية للغاية.

• العميل: الاسم ، الرقم ، العنوان ، البريد الإلكتروني ، موقع العمل المرتبط به.
• موقع العمل: الاسم ، الموقع.

فيما يلي المواصفات التي أحتاجها لهذا البرنامج.

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

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

Answer 1

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

للحصول على قاعدة بيانات خفيفة ، أقترح sqlite (وضوحا 'sql lite' ؛)). يمكنك Google للحصول على دروس حول كيفية إعداده ، ثم كيفية التواصل معها عبر رمز C# الخاص بك. لقد وجدت أيضًا إشارة إلى هذه C# Wrapper for SQLite ، والتي قد تكون قادرة على القيام بالكثير من العمل من أجلك!

Answer 2

اقتراحي هو استخدام sqlite. يمكنك العثور عليها هنا: http://sqlite.org/. ويمكنك العثور على إصدار C# Wrapper هنا: http://sqlite.phxsoftware.com/

SQLite خفيفة الوزن للغاية ولديها بعض الأشياء القوية لمحرك خفيف الوزن. خيار آخر يمكنك البحث فيه هو Microsoft Access.

Answer 3

You're asking the wrong question again :)

The better question is "how do I build an application that lets me change the data storage implementation?"

If you apply the repository pattern and properly interface it you can build interchangable persistence layers. So you could start with one implementation and change it as-needed wihtout needing to re-engineer the business or application layers.

---

Once you have a repository interface you could try implementations in a lot of differnt approaches:

Flat File - You could persist the data as XML, and provided that it's not a lot of data you could store the full contents in-memory (just read the file at startup, write the file at shutdown). With in-memory XML you can get very high throughput without concern for database indexes, etc.

Distributable DB - SQLite or SQL Compact work great; they offer many DB benefits, and require no installation

Local DB - SQL Express is a good middle-ground between a lightweight and full-featured DB. Access, when used carefully, can suffice. The main benefit is that it's included with MS Office (although not installed by default), and some IT groups are more comfortable having Access installed on machines than SQL Express.

Full DB - MySql, SQL Server, PostGreSQL, et al.

---

Given your specific requirements I would advise you towards an XML-based flat file--with the only condition being that you are OK with the memory-usage of the application directly correlating to the size of the file (since your data is text, even with the weight of XML, this would take a lot of entries to become very large).

Here's the pros/cons--listed by your requirements:

Cons

• No limit on amount of data entered.
  • using in-memory XML would mean your application would not scale. It could easily handle a 10MB data-file, 100MB shouldn't be an issue (unless your system is low on RAM), above that you have to seriously question "can I afford this much memory?".

Pros

• Single user per application. No concurrent activity or multiple users.
  • XML can be read into memory and held by the process (AppDomain, really). It's perfectly suited for single-user scenarios where concurrency is a very narrow concern.
• Allow user entries/data to be exported to an external file that can be easily shared between applications/users.
  • XML is perfect for exporting, and also easy to import to Excel, databases, etc...
• Allows for user queries to display customers based on different combinations of customer information/job site information.
  • Linq-to-XML is your friend :D
• The data will never be viewed or manipulated outside of the application.
  • ....then holding it entirely in-memory doesn't cause any issues
• The program will be running almost always, minimized to the task bar.
  • so loading the XML at startup, and writing at shutdown will be acceptible (if the file is very large it could take a while)
• Startup time is not very important, however I would like the queries to be considerably fast
  • Reading the XML would be relatively slow at startup; but when it's loaded in-memory it will be hard to beat. Any given DB will require that the DB engine be started, that interop/cross-process/cross-network calls be made, that the results be loaded from disk (if not cached by the engine), etc...

Answer 4

ماذا عن sqlite؟ يبدو أنه مناسب لتطبيقك.

يمكنك استخدام System.Data.Sqlite كما الغلاف .NET.

Answer 5

يمكنك الحصول على SQL Server Express مجانًا. أود أن أقول إن السؤال ليس كثيرًا لماذا يجب أن تستخدم قاعدة بيانات ، لماذا لا ينبغي عليك ذلك؟ هذا النوع من المشكلات هو بالضبط ماهية قواعد البيانات ، وخادم SQL هو قاعدة بيانات قوية للغاية وتستخدم على نطاق واسع ، لذلك إذا كنت ستذهب لبعض الحلول الأخرى أنت تحتاج إلى توفير سبب وجيه لأنك لن تذهب مع قاعدة بيانات.

Answer 6

ستكون قاعدة البيانات مناسبة بشكل جيد. sqlite جيد كما ذكر الآخرون.

يمكنك أيضًا استخدام مثيل محلي لـ SQL Server Express للاستفادة من التكامل المحسّن مع قطع أخرى من مكدس تطوير Microsoft (نظرًا لأنك ذكرت C#).

الخيار الثالث هو قاعدة بيانات مستندات مثل غراب أسود والتي قد تتناسب من أصوات بياناتك.

تعديل
الخيار الرابع هو المحاولة قابس الضوء عندما يخرج بيتا في غضون أيام قليلة. (8-23-2010)
/تعديل

سيكون هناك دائمًا قيود على تخزين البيانات (المساحة الفارغة للقرص الثابت). وفقًا لـ Wikipedia ، يقتصر SQL Express على 10 غيغابايت ل SQL Server Express 2008 R2