it-swarm.asia

هل يجب أن يكون المطورون قادرين على الاستعلام عن قواعد بيانات الإنتاج؟

هل يجب منح المطورين إذنًا للاستعلام عن قواعد بيانات الإنتاج (SELECT/للقراءة فقط)؟ في المكان السابق الذي عملت فيه ، كان لدى فريق التطوير db_datareader وظيفة؛ حيث أعمل الآن ، لا يمكن لفريق التطوير الاتصال بمثيل الإنتاج.

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

ما الأسباب الجيدة لعدم السماح للمطورين بالاستعلام عن الإنتاج (باستثناء ببساطة عدم رغبتهم في الوصول إلى قراءة البيانات الحساسة)؟

164
Tom Hunter

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

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

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

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

153
ConcernedOfTunbridgeWells

لا.

للمطورين لا ينبغي الوصول إلى أنظمة قاعدة بيانات الإنتاج للأسباب التالية:

  1. التوفر والأداء : امتلاك حقوق للقراءة فقط لقاعدة بيانات هو not غير ضار. يمكن للاستعلام المكتوب بشكل سيئ:

    1. قفل الجداول ، ومنع العمليات الحرجة الأخرى.
    2. قم بتفريغ ذاكرة التخزين المؤقت للبيانات ، مما يجبر العمليات الأخرى على إعادة قراءة البيانات من القرص.
    3. فرض ضرائب على طبقة التخزين الخاصة بك ، مما يؤثر على الخدمات الأخرى التي تشترك في التخزين.
  2. الأمان : قد تحتوي قاعدة بيانات الإنتاج على معلومات حساسة مثل:

    • تجزئات كلمة المرور
    • معلومات الفواتير
    • معلومات تعريف شخصية أخرى

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

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

    "ولكن هذا ينطبق على DBAs أيضًا! يمكنهم فعل ذلك!" بالضبط. تريد أقل عدد ممكن من المستخدمين الخارقين بقدر الإمكان.

نعم.

للمطورين ينبغي الوصول إلى أنظمة الإنتاج.

لدينا في شركتي أربعة فرق تتعامل مع قواعد بيانات الإنتاج. هم انهم:

  1. المطورين ، الذين يصممون ويكتبون المخطط والرمز لقواعد البيانات. ليس لديهم وصول إلى قواعد البيانات في الإنتاج. ومع ذلك ، فإنهم يجلسون أحيانًا مع المسؤولين أو يدعمون الأشخاص ويساعدونهم على النظر إلى شيء ما في الحياة.
  2. المسؤولون ، الذين ينشرون ويراقبون ويديرون قواعد البيانات في الإنتاج.
  3. دعم الأشخاص ، الذين يحققون في مشكلات الإنتاج الحساسة للوقت ويقدمون التعليقات للمطورين حتى يتمكنوا من تطوير الإصلاحات.
  4. أفراد ذكاء الأعمال ، الذين يستخرجون البيانات من قواعد بيانات الإنتاج باستخدام إما نسخ محدثة بانتظام من قواعد البيانات هذه أو مقتطفات مكتوبة بعناية و QA-ed (عادة ما يصممها المسؤولون ).

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

فمثلا:

  • ليس لديك فريق دعم. من سيعرف إلى أين يتجه إلى تصحيح مشكلة الإنتاج الحساسة للوقت؟ مطوريك. منحهم " كسر الزجاج " الوصول.
  • ليس لديك فريق BI. المشرفون ليس لديهم أو يريدون أي شيء يتعلق بالتقارير أو المقتطفات. من الذي سيقوم باستكشاف الأخطاء وإصلاحها في التقرير الذي يشاهده المسؤولون التنفيذيون كل صباح؟ مطوريك. امنحهم وصولاً محدودًا لتصحيح هذه التقارير والمستخلصات.
  • ليس لديك فريق إداري. أنت في شركة صغيرة جدًا أو شركة ناشئة ، لذا قل مرحبًا لـ "DBA العرضي". يتضاعف المطورون لديك كمشرفين ، وبالتالي يحتاجون إلى وصول كامل إلى الإنتاج.
136
Nick Chammas

سيكون الأداء سببًا كبيرًا.

فقط لأنهم لا يستطيعون تغيير البيانات لا يعني أنهم لا يستطيعون التأثير على الخادم. يمكن أن يؤدي الاستعلام المكتوب بشكل سيئ إلى ركب بيئة الإنتاج ، وقد يتسبب في مشكلات أخرى (مثل تدفقات tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

هذه وصفة لكارثة. لاحظ أن هذا المنتج ديكارت مع ترتيب حسب ، مما يعني أنه سيتم فرزه في tempDB.

79
JNK

المبدأ هو "الامتياز الأقل" و "الحاجة إلى المعرفة": هل يجتاز المطورون هذا الاختبار؟
خصوصًا عندما يطرق المدققون أو Sarbannes-Oxley.

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

ثم ، هل الوصول مطلوب بشكل دائم؟ يمكن أن يكون لديهم وصول "كسر الزجاج" باستخدام تسجيل دخول SQL أو حساب Windows بديل يتطلب تسجيل الخروج. في حالتنا ، كان مالك البيانات (نأمل أن يقوم بعض رجال الأعمال المحنكين بالتكنولوجيا) ومدير تكنولوجيا المعلومات بالموافقة عليها.

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

هذه تفترض متجر بحجم معقول بالطبع. كلما زاد عدد القبعات يرتدون أقل الفصل بين الواجبات التي يمكنك القيام بها

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

33
gbn

أعتقد أن الجواب ، كما هو الحال مع أشياء كثيرة ، "يعتمد".

قاعدة بيانات ضخمة ERP قاعدة بيانات تحتوي على الكثير من المعلومات الحساسة عن الشركة والعملاء؟ ربما لا (لأسباب تتعلق بالأمان والأداء).

قاعدة بيانات 5 ميجا بايت للإدارة مع واجهة وصول Access التي تتعقب المساهمات في صناديق البيتزا والدونات؟ لن يحدث فرقًا كبيرًا ، على الأقل للوصول للقراءة فقط.

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

20
db2

في بيئة معتادة على مدار الساعة طوال أيام الأسبوع OLTP لا يجب السماح لمطور عادي في الإنتاج. الفترة! إذا ظهر من وقت لآخر سبب معين ، يمكن منح الأذونات عند الطلب. ولكن على أساس معتاد لا.

لقد رأيت العديد من الأسباب لذلك:

  • حدد * من جدول كبير يؤدي إلى:

    • قضايا الأداء (المنتجات الديكارتية) ؛
    • منع المشكلات التي أدت في نهاية المطاف إلى الركوع في الموقع ؛
    • سلسلة الحجب التي تضع النسخ المتماثل في تعليق ؛
    • طلب مجموعة كبيرة من البيانات التي ملأت محرك TempDB الذي .. تخمين ماذا؟ تسبب الجنون الكامل :-)!
    • ارتفاع ضغط الدم لـ DBA المسؤول عن الإنتاج لتلك الليلة ؛
  • قراءة البيانات الحساسة (لا يجب على المطور الوصول إلى معلومات بطاقة الائتمان .. أو أي تفاصيل شخصية للمستخدم) ؛

أنا متأكد من أن هناك المزيد من الأسباب.

20
Marian
  • الأمان: قد تكون هناك معلومات حساسة يتم تطهيرها عند إتاحتها للمطورين.
  • جنون العظمة: قد يعتقد البعض أنه لا يزال بإمكانك تخبط البيانات بمجرد الوصول المحدد.
  • الأداء: يتطلب الاستعلام بعض الموارد لإجراءه ، ولا يمكنك إخباري بأن مطوريك مثاليون عند كتابة الرمز.
19
Paul

زوجان من العناصر للنظر

  • هل البيانات حساسة؟
  • هل المبرمجون جزء من فريق موثوق به أو فريق خارجي؟
  • ما هو حجم البيانات التي يتم الاستعلام عنها من حيث التأثير على الأداء؟
  • ما هو حجم المشروع أو الدولارات المعنية؟
  • ما مدى أهمية وقت التشغيل؟

دولارات صغيرة تحتاج إلى عملية أقل تحتاج إلى تدفق أسرع للتطوير.

الدولارات الأكبر تحتاج إلى المزيد من العملية تحتاج إلى معايير أكثر صرامة لممارسات التنمية.

تكييف ممارساتك مع ما تفعله.

16
Jason Sebring

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

  1. نحن بحاجة إلى الوصول في الوقت الحقيقي لمراقبة عملياتنا اليومية. (على الرغم من أن لدينا لوحة تحكم ، إلا أننا بحاجة إلى أن نكون قادرين على مراقبة الأمور بعمق. وبينما سيكون من الجميل وجود هذه الميزة على لوحة التحكم لدينا ، فقد وجدنا أن ذلك غير عملي.)
  2. نحن بحاجة إلى الوصول في الوقت الفعلي للتحقيق في أي إخفاقات في الإنتاج لأن التأخيرات يمكن أن يكون لها تأثير كبير. (لن أقوم بمناقشة فشلنا هنا. إنهم يأتون بكل أنواعه)
  3. غالبًا ما نحتاج إلى إعداد تقارير مخصصة لمستخدمي الأعمال ، ويجب تحديث هذه المعلومات. (dba's ليس لديهم الوقت للقيام بذلك وليس لدينا الوقت لانتظارهم. على الرغم من أنه ليس مثاليًا ، بالتأكيد).
  4. نحن بحاجة إلى التحقق من عمليات نشر/تصحيحات DDL/DML للإنتاج. (ينشرها DBAs ، ولكننا نعرف فقط كيف يجب تنظيمها. نحن نعرف المزيد عن بنية قاعدة البيانات الخاصة بنا أكثر من DBAs. قد نكون غريبين هنا ، ولكن قاعدة البيانات الخارجية معقدة للغاية لأن أعمالنا معقدة للغاية.)

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

14
user606723

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

11
jl01

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

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

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

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

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

أتمنى أن يساعدك هذا.

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

10
Chris Travers

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

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

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

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

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

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

البيانات هي الجزء الأكثر قيمة في معظم التطبيقات!

9
SoftwareCarpenter

قد يكون الأداء أحد الأسباب.

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

نظام الإنتاج ليس مكانًا مناسبًا للمطورين لتجربته.

8
JSR

يعتمد الأمر على DBA وكيف أنه واثق من المطور. عادة يتم منح المطورين امتيازات الاستعلام (قراءة) لقواعد بيانات الإنتاج. كقاعدة عامة ، المطورين يجب العمل فقط مع قواعد بيانات الاختبار/التطوير.

8
MarlonRibunal

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

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

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

هذه مجرد واحدة من الأشياء التي نقدمها. تحقق منا على http://www.Stackify.com لمعرفة المزيد حول دعم DevOps الحلول.

8
Matt from Stackify

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

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

7
Tom Resing

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

5
Ryan Waldron

لا أبدا!!

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

يجب أن تذهب أي معلومات يحتاجون إليها من خلال DBA الذين يمكنهم تشغيل ما يريدون (تحديد) وإرسال النتائج إليهم. هكذا نفعل في بيئتنا.

1
Ramakant Dadhichi