ماذا تعني كلمة "أصلي" في سياق تقنيتين مرتبطتين؟

Question

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

علاوة على ذلك، تم التأكيد على أنه إذا لم تتمكن من إنشاء شيء ما عبر DAO، فهو بحكم التعريف ليس "أصليًا" لـ Jet.

بالنسبة لي، يبدو أن تعريف "المواطن" هذا في غير محله.هناك عدد من كائنات Jet التي، لأسباب تاريخية وسياسية لشركة Microsoft، تم حذفها من DAO أو تم تنفيذها جزئيًا فقط (CHECK القيود، وأنواع البيانات ذات العرض الثابت، و DECIMAL نوع البيانات، وأنواع البيانات القابلة للضغط، وما إلى ذلك) ولكن تم تضمينها في SQL الخاص بـ Jet لغة تعريف البيانات (دي دي إل).يخبرني الحدس وحده أن Jet SQL DDL يجب اعتباره "أصليًا" لمحرك Jet.

لذلك سؤالي هو:لماذا تعتبر التكنولوجيا التي تبدو خارجية (DAO) "أصلية" وتعتبر التكنولوجيا الأخرى التي تبدو داخلية (SQL DDL) "غير أصلية"؟هل يجب أن أزعج نفسي بشأن ما إذا كان الشيء "محليًا" أم غير ذلك؟

Answer 1

ربما أكون مخطئًا هنا، لكنني دائمًا فهمت الأمر على النحو التالي:

• محرك قاعدة بيانات MS Jet هو بكل الأحوال محرك قاعدة بيانات (ضعيف القوة أم لا)
• إنها واجهة "أصلية" للعالم الخارجي وهي لهجة SQL

بينما:

• DAO هي إحدى طبقات تجريد قاعدة بيانات Microsoft، وهي مصممة للاستخدام في بيئة COM مثل البرمجة النصية لـ VBA أو Windows
• تم تطويره باستخدام Access (والذي يمكن النظر إليه على أنه واجهة مستخدم / أداة إعداد التقارير لـ MS Jet، نظرًا لأن MS Jet يمكن أن يوجد بدون MS Access)، وهو مدمج بقوة مع كل من MS Jet وMS Access، ومع ذلك فهو في نفس الفئة التي سيكون فيها ADO

Answer 2

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

تم تقديم Jet في أوائل التسعينيات مع Access.بين الإصدارين 1 و2، استحوذت MS على Foxpro ودمجت تقنية "Rushmore" الخاصة بها في Jet.في مكان ما خلال هذا الإطار الزمني، قام MS بتطوير DAO كطبقة واجهة لـ Jet.لا أعرف على وجه اليقين أن DAO كان له وجود على الإطلاق بخلاف طبقة واجهة البيانات التي تستخدم Jet للوصول إلى جميع البيانات، ولكن هذا ما بدا لي.كان Jet خيارًا جيدًا إلى حد ما لهذا لأنه باستخدام ODBC وISAMs القابلة للتثبيت، يمكنه جعل أي من تنسيقات قواعد البيانات الشائعة في ذلك الوقت تبدو وتتصرف في تطبيقك بنفس الطريقة التي تبدو بها بيانات Jet الأصلية وتتصرف.في تلك الأيام، كان dBase ومتغيراته وParadox يهيمنون على سوق قواعد بيانات سطح المكتب.كانت هذه كلها محركات قاعدة بيانات لسطح المكتب، وليست قواعد بيانات الخادم.كان الوصول إلى قواعد بيانات الخادم بشكل عام من خلال ODBC، ولكنه لم يكن في ذلك الوقت مهمًا لمطوري تطبيقات قاعدة بيانات سطح المكتب.تمكنت Jet من الاتصال بمصادر بيانات ODBC بشكل جيد إلى حد ما واستخدامها بكفاءة كبيرة، على الرغم من أنها قد ترتكب أخطاء في بعض الأحيان (وهذا هو سبب تقديم ODBCDirect إلى Jet، والذي من شأنه تجاوز جوانب معينة من محرك معالجة البيانات الخاص بـ Jet).

الآن، بالتوازي مع ظهور Access/Jet/DAO، كانت Visual Basic هي المنتج الرائج لتطوير تطبيقات Windows بشكل عام، وقبل ازدهار الويب، كانت لغة VB هي لغات البرمجة الأكثر استخدامًا في العالم.قدمت DAO وJet لمطوري VB واجهة لجميع أنواع مخازن البيانات، وتم دمج أدوات تطوير VB بشكل جيد معهم.وهكذا، بعد ODBC، أصبحت DAO طبقة واجهة البيانات الرئيسية لـ MS، وذلك باستخدام محرك Jet للعمل مع جميع أنواع البيانات.

وبطبيعة الحال، كان لهذا مشاكله وكان أيضًا مقيدًا جدًا لأن Jet/DAO (و VB) كانت جميعها أدوات موجهة لسطح المكتب.بحلول منتصف وأواخر التسعينات، كانت MS تحاول التوسع من مزود برامج سطح المكتب ونظام تشغيل سطح المكتب وأدوات التطوير إلى مزود برامج المؤسسة.لذا، كان MS بحاجة إلى تطوير واجهات بيانات أكثر قوة، مثل ODBC لخوادم قواعد البيانات، ولكن مع جميع الميزات الحديثة التي توفرها قواعد بيانات الخوادم الأحدث.كان OLEDB هو الحل لذلك باستخدام ADO كطبقة الواجهة أعلى OLEDB (تمامًا كما أن DAO هي طبقة الواجهة أعلى Jet).بينما كان هدف DAO هو توفير الوصول إلى الكثير من مخازن البيانات عبر محرك قاعدة بيانات Jet، كان OLEDB عبارة عن طبقة واجهة بيانات أكثر حيادية مثل ODBC، وطبقة تجريد قاعدة البيانات، وكان ADO هو الواجهة لطبقة واجهة البيانات المحايدة تلك.

فيما يتعلق بمسألة DDL "الأصلي"، فالحقيقة أنه قبل Jet 4 كان هناك دعم ضعيف جدًا لـ SQL DDL.أي أن هناك ميزات لـ Jet لا يمكن التحكم فيها عبر SQL DDL.وبدلاً من ذلك، كان عليك استخدام DAO للتحكم في هذه الميزات.في حين أن مبرمجي محرك قاعدة بيانات Jet يتضمن بالتأكيد أمثلة DDL إلى جانب أمثلة DAO، فإن أمثلة DAO قادرة على فعل الكثير لأن Jet DDL SQL لم يدعم مطلقًا كافة ميزات قواعد بيانات Jet.

لقد حدث الانهيار الذي يبدو مربكًا جدًا بسبب سياسات مرض التصلب العصبي المتعدد الداخلية.بحلول عام 1999، عندما قدمت MS Access 2000 (مع الإصدار الجديد من Jet، 4.0)، أرادت MS إيقاف DAO لصالح ADO.جعل MS ADO طبقة واجهة البيانات الافتراضية في Access حتى عندما لم يكن من المنطقي استخدام ADO (أي أن مخزن البيانات الخاص بك كان Jet).وكجزء من هذا الجهد، لم تقم MS بتحديث DAO بشكل كامل لدمج الدعم لكافة الميزات الجديدة لـ Jet 4 - وبدلاً من ذلك بذلوا جهودهم على هذه الجبهة في ADO.وكانت النتيجة أن طبقة واجهة البيانات الأصلية لـ Jet، DAO، تفتقر إلى دعم ميزات Jet التي توفرها طبقة الواجهة المحايدة لقاعدة البيانات، ADO.كان هذا، في رأيي، شكلاً معينًا من أشكال الغباء من جانب مايكروسوفت.لم يكن MS يعمد إلى تحديث طبقة الواجهة الأصلية لـ Jet من أجل إجبارك على استخدام الواجهة غير الأصلية.لذلك، بدلاً من DAO->Jet، كان عليك استخدام ADO->OLEDB->Jet، حتى بالنسبة لبعض الأشياء التي كانت جوانب أصلية لمحرك قاعدة بيانات Jet (مثل بعض أنواع البيانات للحقول).

كان هدف Microsoft هو القضاء على DAO بالكامل، وفي الحقيقة قتل Jet نفسها.لقد أرادوا أن ينتقل العملاء إلى SQL Server.

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

مع خروج ADO من النافذة، كان لدى MS فجوة في منتصف خط إنتاجها.لم يكن مطور VB الكلاسيكي أو مطور Access يرى فائدة كبيرة في .NET، لأن نموذج الوصول إلى البيانات بالكامل لم يكن مناسبًا.وهكذا، مع إصدار Access 2002، عكس MS مساره وأعاد DAO إلى مكانه كطبقة واجهة البيانات الافتراضية لبيانات Jet (وجميع مخازن البيانات الأخرى التي يمكن لـ Jet العمل معها عبر، على سبيل المثال، ODBC، وما إلى ذلك).لسوء الحظ، بينما كان MS الآن يتجاهل ADO للاستخدام مع Jet، لم يختاروا إصلاح الإصدار المعطل من DAO المصاحب له.ربما لم يفعلوا ذلك لأنه في هذه المرحلة تم اتخاذ القرار بتقسيم Jet 4 الحالي إلى محرك قاعدة بيانات مملوك لمجموعة تطوير Access.أصبح هذا في النهاية ACE وهو، لجميع المقاصد والأغراض، Jet 4.5.تم إصدار نسخة جديدة من DAO (على الرغم من أنها مخفية قليلاً باسمها سهل الاستخدام وهو "مكتبة كائنات محرك قاعدة بيانات Microsoft Office 12.0 Access" بينما أصبح اسم DLL الآن ACEDAO.DLL).لا أعرف مدى إضافة الميزات المفقودة في DAO 3.6 (إصدار Jet 4) إلى إصدار ACE من DAO.لا أعرف لأنني لا أعرف يحتاج أي من هذه الميزات لذلك لا أعرف حتى ما هي.

على أية حال، في هذه المرحلة، هناك الآن تطوير مستمر على Jet (لقد وعدونا بأن Jet 4 هو النهاية) وعلى طبقة واجهة البيانات الأصلية الخاصة به (DAO، ​​الذي وعدنا به أيضًا قد مات) .هذا التطوير المستمر موجود الآن ضمن مجموعة تطبيقات Access في Microsoft (على عكس Windows، حيث تمت صيانة Jet 4 سابقًا).

أضافت Microsoft أوضاع التوافق في Access لاستخدام ما يسمونه وضع ANSI-92 SQL.من المفترض أن يسمح لك هذا بكتابة SQL "متوافق" مع لهجة SQL Server.حسنًا، إنه يدعم بعض الأشياء (يمكنك استخدام أحرف البدل الخاصة بـ SQL Server واستخدام () للجداول المشتقة بدلاً من [].باسم مستعار)، ولكنه ليس قريبًا جدًا من TSQL.ولكن خارج Access، الطريقة الوحيدة لاستخدام وضع SQL "ANSI-92" هي استخدام ADO للاتصال بـ Jet.لا يزال DAO نفسه يستخدم لهجة SQL القديمة لـ Jet.يوضح هذا أن Jet لا يوفر الدعم لهذا الوضع نفسه، ولكن يتم توفيره بواسطة طبقات أعلى Jet.