إيجابيات وسلبيات محرك قاعدة بيانات Access.الحياة بعد SQLite

Question

سألت أ سؤال منذ فترة حول قاعدة البيانات المحلية التي كانت مناسبة لموقفي.كنت بحاجة للوصول إلى قاعدة البيانات من كل من كود .NET وVB6.وكانت الاستجابة الساحقة هي SQLite.ومع ذلك، قررت التخلي عن SQLite، لأن موفر OLE DB الوحيد له يفرض رسومًا على كل نسخة منشورة من برنامجي.ويتطلب أيضًا تشغيل إجراء التنشيط على كل جهاز كمبيوتر.

بعد تقييم الخيارات الأخرى (إصدار SQL Server المضغوط - موفر OLE DB الذي يعمل بالكاد، Firebird - لا تريد أن تدفع مقابل برنامج تشغيل آخر، وما إلى ذلك ...)، توصلت إلى استنتاج مفاده أن الخيار الوحيد القابل للتطبيق هو استخدام . ملفات MDB التي تم إنشاؤها بواسطة Microsoft Access (أو محرك Jet).

لم أستخدمه منذ أواخر التسعينات، لذا لدي الأسئلة التالية لأولئك الذين لديهم خبرة به.

1. هل قاموا بحل المشكلة حيث قد تفسد قاعدة البيانات بين الحين والآخر.
2. هل تم الوصول إلى MDB من c# عبر موفر ADO.NET OLEDB أم أن هناك حلًا أصليًا (لا يبدو أنني أستطيع العثور عليه).
3. هل هناك بديل قابل للتطبيق لمحرر SQL السيئ حقًا في Access؟

شكرًا.

Answer 1

بدلاً من "الرجوع" إلى Access، سألتزم باستخدام SQLite واستخدم موفر System.Data.SQLite للوصول إلى بيانات SQLite ضمن كود .NET.

بعد ذلك، سأقوم فقط بإنشاء فئة .NET للتشغيل المتداخل لـ COM بسيطة لاستخدامها بواسطة VB6 والتي تتضمن أي وظيفة مطلوبة للوصول إلى بيانات SQLite.أخيرًا، ما عليك سوى الرجوع إليه واستخدامه ككائن COM قياسي من مشاريع VB6 الخاصة بك.

ربما تكون معرفتي ببرنامج Access قديمة بعض الشيء ومتحيزة بسبب التجارب السيئة، ولكن في حدود المعقول سأحاول تجربة معظم الخيارات الأخرى قبل اللجوء إلى مسار الوصول.

Answer 2

هل فكرت SQL Server 2008 الإصدار السريع (على عكس SQL Server CE)؟

1) شخصيًا، وجدت أن تلف قواعد بيانات Access في معظم الأوقات كان بسبب تعليمات برمجية لم يتم تنظيفها بعد ذلك، أو بسبب وجود بطاقة شبكة خاطئة.

2)

string connectionString = @“Provider = Microsoft.Jet.OLEDB.4.0; " + 
                          @"Data Source = C:\data\northwind.mdb; " +
                          @"User Id = guest; Password = abc123”


using (OleDbConnection oleDbConnection = New OleDbConnection())
{
    oleDbConnection.ConnectionString = connectionString;

    oleDbConnection.Open();

    ...
}

3) SQL Server 2008 Express Edition

Answer 3

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

لا أتوقع أن يكون SQLite مختلفًا، أو أسوأ من ذلك.

سيؤدي تشغيل JetComp.exe بشكل دوري (تنزيل من Microsoft) إلى إصلاح العديد من المشكلات وجداول الفهرس المضغوطة وما شابه.النسخ الاحتياطية مهمة بغض النظر عما تستخدمه.

لا تحتاج إلى MS Access على الإطلاق لاستخدام Jet MDBs.هناك بعض أدوات الطرف الثالث لتصميم مخطط قاعدة البيانات وإجراء الاستعلامات التفاعلية، سواء من خلال سطر الأوامر أو واجهة المستخدم الرسومية.

Answer 4

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

Answer 5

يمكنك أيضًا المحاولة SQL في أي مكان يعمل على أنظمة تشغيل مختلفة وله مساحة صغيرة.تناسبني :)

Answer 6

سأل AngryHacker:

س1.هل قاموا بحل المشكلة حيث قد تفسد قاعدة البيانات بين الحين والآخر.

إيه، ماذا؟

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

أعتقد أن معظم الأشخاص الذين يعانون من الفساد هم أولئك الذين يحاولون مشاركة ملف MDB بين العديد من المستخدمين (سواء كانوا منقسمين أو غير منقسمين).نظرًا لأنك لا تفكر في استخدام Access، فهذه ليست مشكلة حقًا.

س2.هل تم الوصول إلى MDB من c# عبر موفر ADO.NET OLEDB أم أن هناك حلًا أصليًا (لا يبدو أنني أستطيع العثور عليه).

سيكون الحل الأصلي هو DAO، ولكنه COM، لذا قد لا ترغب في استخدامه.من لغة C#، أود أن أقول إن OLEDB هو أفضل رهان لك، ولكن هذا ليس مجال خبرتي، لذا تعامل مع الأمر بحذر.أعتقد أن مايكل كابلان أبلغ أن موفر Jet ADO/OLEDB كان آمنًا لمؤشر الترابط، في حين أن DAO ليس كذلك.هذا لا يعني أنه أوصى بـ ADO/OLEDB بدلاً من DAO، لكن تعليقاته جاءت أيضًا في سياق Access، وليس C#.

س3.هل هناك بديل قابل للتطبيق لمحرر SQL السيئ حقًا في Access؟

لماذا تستخدم ذلك عندما لا تستخدم Access فعليًا؟يمكنك استخدام أي محرر SQL تريده طالما أنك تختبر أن SQL الذي تكتبه متوافق مع لهجة SQL الخاصة بـ Jet.

أنا، شخصيًا، لا أرى ما هي المشكلة في محرر SQL الخاص بـ Access (بخلاف عدم القدرة على تعيين حجم الخط)، ولكن بعد ذلك، أكتب الكثير من SQL باستخدام QBE ولا ألقي نظرة على الإطلاق عرض SQL.

Answer 7

للإجابة على سؤالك بخصوص محرر SQL السيئ حقًا في Access - أوافق على ذلك تمامًا.الخط كريه الرائحة، يقوم MSAccess دائمًا بإعادة تنسيق الاستعلام بشكل سيئ، ويضيف أحيانًا أحرفًا تعريفية تكسر SQL الخاص بي، وأخيرًا ولكن الأسوأ، إذا لم يتمكن من تحليل SQL، فلن يسمح لك بالوصول إليه!

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

يعد الكود الخارجي رائعًا أيضًا لأنه يمكنك إنشاء مجموعة من حالات الاختبار، وتحديد قيم الإرجاع المتوقعة، وما إلى ذلك.