قاعدة البيانات ليست مجرد مستودع للبيانات

استخدام قاعدة البيانات فقط لتخزين البيانات هو نفس استدعاء Unix واجهة للعمل مع الملفات. لذلك ، أود أن أذكرك بوظائف قاعدة البيانات المعروفة وليست جدًا التي أود رؤيتها في كثير من الأحيان في تطبيقات القتال القائمة على الويب.

TL ؛ د

فيما يلي سيتمحور حول المصادقة والمستخدمين وحقوق الوصول وتكامل البيانات و FDW والتسجيل والإحصائيات. لا جديد.

ملاحظات

• أعني Ruby on Rails و Postgres ، ولكن معظم المراجع مقبولة جيدًا في اللغات الأخرى و DBMS.
• لن أقول أي شيء جديد ، كل هذا تم وصفه منذ فترة طويلة في الوثائق والمقالات. أريد فقط أن أذكر مرة أخرى بالأدوات وأين يمكن تطبيقها لجعل الحياة أفضل قليلاً.

مصادقة الأقران / الهوية

شيء صحي للغاية ، والذي لا يستخدمه أحد تقريبًا. يقوم بتعيين مستخدم Unix إلى مستخدم قاعدة بيانات. في الحالة الأولى ، يتم تعيين المستخدم المحلي ، وفي الحالة الثانية ، المستخدم البعيد. الربح هو أنه يمكنك التخلص من المضيف واسم المستخدم وكلمة المرور من التكوين (ويمكن أيضًا التخلص من اسم قاعدة البيانات) ، ولكن كل شيء سيعمل كما كان من قبل. بالإضافة إلى ذلك ، سيكون من الملائم أكثر الدخول إلى وحدة التحكم لتصحيح الأخطاء مباشرةً (فقط psql من الوحدة الطرفية بدلاً من كل هذه -h -U -W -d وما إلى ذلك).

وثائق PG حول الأقران والهوية .

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

أمثلة على الاستخدام

الأمان لا يمكنك إزالة كلمة المرور من قاعدة البيانات والاتصال بها من البيئة المحلية أو من مكان آخر. لا توجد كلمة مرور ولا يوجد شيء للسحب.

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

حقوق الوصول

في Unix ، يفكر الجميع بها ويبدون منحرفين جدًا في العمل من الجذر أو في 'chmod 777' . ولكن كل شيء في قاعدة البيانات مختلف بطريقة أو بأخرى. الخارق وانطلق. على الرغم من أن كل شيء لا يوجد أقل (وربما أكثر) بارد.

هناك تسلسل هرمي لوراثة الدور (يشبه إلى حد ما المجموعة في Unix) ، وهناك وصول لمستويات مختلفة: إلى كائنات محددة (مثل أذونات الملف) ، sudoers محددة (مثل القواعد في sudoers ) ، حتى إلى خطوط محددة . باختصار ، كل شيء موجود. استخدمه.

مجالات التطبيق

في الإصدار الأدنى ، مع نظير / معرف أعلاه ، يمكنك فصل المستخدم لعمليات الترحيل / النشر والمستخدم للتشغيل اليومي للتطبيق. هذا ، على الأقل ، سيحمي ضد مكالمات DDL في وقت التشغيل. بالطبع ، هناك العديد من حالات تعديل هيكل قاعدة البيانات "على الساخن". هذه هي نشر وقت التعطل صفر ، والإصلاحات المختلفة ، وإعادة بناء الفهارس مع التوافق (وأحيانًا بدون). ولكن ، بشكل عام ، لا ينبغي تطبيق DDL.

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

قيد النزاهة

في Rails 5 ، على الأقل بطريقة ما ، بدأ العمل مع المرجع وتكامل البيانات. ولكن ، في الحالة العامة ، يعتقد العديد من المطورين أن التحقق من الصحة في النموذج أو ضواحيه يكفي للحفاظ على الحالة المتسقة للبيانات. للأسف ، هذا ليس صحيحا على الإطلاق.

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

غلاف البيانات الخارجية

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

باستخدام FDW

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

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

ومع ذلك ، يمكنك الاتصال بالنوع الغريب من MS Access وتختفي المشاكل المتعلقة بالقيود المفروضة على استخدام العلاقات في النماذج. بعد كل شيء ، إذا كان لديك اتصالان أو أكثر ، فلن تقوم بربط قاعدتين على مستوى تطبيق الويب ، على الرغم من أن ORM (على وجه الخصوص ، ActiveRecord) سيحاول بصدق القيام بذلك ... وسوف يسقط. وعلى مستوى قاعدة البيانات ، يمكن القيام بذلك ، في بعض الحالات ، تقريبًا بدون نفقات عامة.

تسجيل الدخول

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

تذكر أيضًا عن N + 1. لن تقول قاعدة البيانات أي شيء عنها. استخدم أدوات الطرف الثالث. على سبيل المثال ، الرصاصة والحس السليم.

الإحصائيات

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

وأحيانًا يمكنك استخدام الإحصائيات لحساب تقريبي. نادرًا ما يكون مفيدًا ، ولكن بشكل مناسب تمامًا ، لأن PG ليست Oracle ولا يتم count الجدول بأكمله في O (1) ، على الرغم من أنني أريد ذلك حقًا.

النهاية

شكرا للقراءة. إذا لم يكن الأمر صعبًا ، أجب عن السؤال أدناه. في ضوء مقالة حديثة حول GQL ، بدلاً من SQL ، بدأت تزعجني كثيرًا.