سؤال

أنا بدأت مع قاعدة بيانات SQLServer. لذلك يبدو أنه يجب أن تستخدم System.Data.SqlClient مساحة الاسم. ولكن هناك فرصة قد نحتمل أن تغلق قاعدة بيانات SQLServer لدينا وتذهب إلى MySQL أو Oracle. لهذا السبب، سألقي مجموعة من المعايير حول كيفية توصيل تطبيقاتنا .NET لدينا مع قاعدة البيانات، وذلك لجعل من السهل الترحيل إلى نظام قاعدة بيانات مختلفة في المستقبل إذا كنا بحاجة إلى القيام بذلك.

إذن إليك المعايير:

  1. استخدم Orm orm إذا كان ذلك ممكنا (مثل Linq) (لا يوجد LINQ لأنه يدعم SQLServer فقط، ولكن ماذا عن إطار الكيان ودعمه ل Oracle و MySQL؟)
  2. إذا كان orm عبارة عن مقتطف، فاستخدم استعلامات SQL المعلمة.
  3. استخدم الإجراءات المخزنة فقط للتشغيل الطويل أو الإجراءات المعقدة التي تحتاج إلى تنفيذها في قاعدة البيانات.

الذي يقودني إلى بلدي السؤال الرئيسي في متناول اليد. ما الاسم المسم الباحثي الذي يجب أن أستخدمه لقانون دال الخاص بي؟

يبدو لي أن الاختيار بين System.Data.ODBC و System.Data.OleDB:

  • ما هي المفاضلات؟
  • هو واحد يفضل على الآخر؟
  • ما هي أفكارك حول المعايير الثلاثة الأولى؟
هل كانت مفيدة؟

المحلول

system.data.sqlclient.

يتصل ب SQL Server 2000 والإصدارات الأحدث فقط، ولكنك ستحصل على الأداء الأمثل عند الاتصال بتلك قواعد البيانات.

system.data.oledbclient.

يتصل ب SQL 6.5

يمنحك OLEDBClient القدرة على الاتصال بقاعدة بيانات أخرى مثل Oracle أو الوصول إليها. ولكن للعمل مع SQL Server، ستحصل على أداء أفضل باستخدام SQLClient.

ملاحظة: للاتصال بأوراكل، لدى Microsoft أيضا Oracleclient.

system.data.odbcclient.

يتصل قواعد البيانات القديمة فقط، باستخدام برامج تشغيل ODBC. (على سبيل المثال MS Access 97.)

المصدر الأصلي

نصائح أخرى

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

أيضا، فقط للتوضيح، LINQ غير محدد ل SQL Server. هذا هو linq-to-sql. Linq هي تقنية الاستعلام التي يمكنك استخدامها في LinQ-To-SQL و LinQ-To-ensitation و LinQ-To-Objects، وحتى LLBLGen يدعم LinQ.

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

أود فقط استخدام SQLClient وإعادة الكتابة / إعادة إنشاء DAL إذا تغيرت.

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

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

ستجد أن استخدام SQL Server يتمتع SQLClient بشكل أسرع بكثير وأسهل في تطويره من OLEDB و ODBC - ما لم يكن من المحتمل للغاية أن تحتاج إلى دعم منصات متعددة ستجد أن الفوائد تفوق المخاطر التي ستحتاج إلى إعادة كتابةها دال الخاص بك.

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

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

سوف يمنحك Sqlclient إمكانية الوصول الأصلي ويجب أن يكون المزيد من الأداء (لا يتعين عليه القيام بأي عمليات تجريدية / ترجمات).

الشيء الوحيد الذي لديك لتغييره للحصول على عمل OLEDB مقابل ODBC هو سلسلة الاتصال الخاصة بك. يحتوي OLEDB على ذكاء أكثر من جانب العميل بحيث يوفر أداء أفضل.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top