اتصال قاعدة البيانات
يُعدّ اتصال قاعدة البيانات أداةً في علوم الحاسوب تُمكّن برامج العميل من التواصل مع برامج خادم قاعدة البيانات ، سواءً كانت على نفس الجهاز أم لا. ويُعدّ هذا الاتصال ضروريًا لإرسال الأوامر واستقبال الإجابات، والتي عادةً ما تكون على شكل مجموعة نتائج.
تُعدّ الاتصالات مفهومًا أساسيًا في البرمجة التي تركز على البيانات . ولأن بعض محركات إدارة قواعد البيانات تتطلب وقتًا طويلًا للاتصال، فقد تم ابتكار تجميع الاتصالات لتحسين الأداء. لا يمكن تنفيذ أي أمر على قاعدة بيانات دون وجود اتصال "مفتوح ومتاح" بها.
تُنشأ الاتصالات بتزويد برنامج تشغيل أو موفر أساسي بسلسلة اتصال ، وهي طريقة للوصول إلى قاعدة بيانات أو خادم محدد، بالإضافة إلى بيانات اعتماد مصادقة المستخدم (على سبيل المثال، Server= sql_box; Database= Common; User ID= uid; Pwd= password; ). بمجرد إنشاء الاتصال، يمكن فتحه وإغلاقه حسب الرغبة، كما يمكن ضبط خصائصه (مثل مدة مهلة الأمر، أو نوع المعاملة ، إن وجدت). تتكون سلسلة الاتصال من مجموعة من أزواج المفاتيح والقيم وفقًا لواجهة الوصول إلى البيانات وموفر البيانات المستخدم.
تسمح العديد من قواعد البيانات (مثل PostgreSQL ) بتنفيذ عملية واحدة فقط في كل مرة على كل اتصال. فإذا تم إرسال طلب بيانات ( عبارة SQL Select ) إلى قاعدة البيانات، وتم إرجاع مجموعة نتائج، يبقى الاتصال مفتوحًا ولكنه غير متاح لإجراء عمليات أخرى حتى ينتهي العميل من معالجة مجموعة النتائج. أما قواعد البيانات الأخرى، مثل SQL Server 2005 (والإصدارات الأحدث)، فلا تفرض هذا القيد. ومع ذلك، فإن قواعد البيانات التي تسمح بتنفيذ عمليات متعددة لكل اتصال عادةً ما تتكبد عبئًا إضافيًا أكبر بكثير من تلك التي تسمح بتنفيذ عملية واحدة فقط في كل مرة.
تجميع
تُعدّ اتصالات قواعد البيانات محدودة ومكلفة ، وقد يستغرق إنشاؤها وقتًا طويلاً بشكل غير متناسب مع العمليات التي تُجرى عليها. لذا، من غير الفعال أن يقوم التطبيق بإنشاء اتصال قاعدة بيانات واستخدامه وإغلاقه كلما احتاج إلى تحديث قاعدة البيانات.
تُعدّ تقنية تجميع الاتصالات أسلوبًا مصممًا للتخفيف من هذه المشكلة. إذ يُمكن إنشاء مجموعة من اتصالات قواعد البيانات ثم مشاركتها بين التطبيقات التي تحتاج إلى الوصول إلى قاعدة البيانات.
The connection object obtained from the connection pool is often a wrapper around the actual database connection. The wrapper understands its relationship with the pool, and hides the details of the pool from the application. For example, the wrapper object can implement a "close" method that can be called just like the "close" method on the database connection. Unlike the method on the database connection, the method on the wrapper may not actually close the database connection, but instead return it to the pool. The application need not be aware of the connection pooling when it calls the methods on the wrapper object.
This approach encourages the practice of opening a connection in an application only when needed, and closing it as soon as the work is done, rather than holding a connection open for the entire life of the application. In this manner, a relatively small number of connections can service a large number of requests. This is also called multiplexing.
In a client/server architecture, on the other hand, a persistent connection is typically used so that server state can be managed. This "state" includes server-side cursors, temporary products, connection-specific functional settings, and so on.
An application failure occurs when the connection pool overflows. This can occur if all of the connections in the pool are in use when an application requests a connection. For example, the application may use a connection for too long when too many clients attempt to access the web site or one or more operations are blocked or simply inefficient.
See also
References
- IDbConnection Interface on MSDN
- Managing and Monitoring .NET Connections whitepaper.
- Getting and Staying Connected whitepaper.
- Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) Addison Wesley, William Vaughn, ISBN 978-0321243621
External links
- Databases
