يتفاعل العميل مع قاعدة البيانات.
من موقع http://corchaosis.ru ، مؤلف الصورة جوناثان تيونج.
بالإضافة إلى كوني مبرمجًا (معظمهم من دلفي + جميع أنواع نظم إدارة قواعد البيانات المختلفة ، مؤخرًا ORAKL ، + القليل من PHP) ، لدي هواية - شراء وبيع الشقق. أشتري شقة في مرحلة البناء من مطور موثوق إلى حد ما بسعر لذيذ (على سبيل المثال ، هذا المطور الآن هو Airplane ، والشقق بالقرب من مترو Nekrasovka معروضة للبيع) ، وانتظر تسليم المنزل (غالبًا بعد عامين ، مع عروض غير مكلفة يحدث هذا) ، أقوم بذلك تم تجديده وبيعه مقابل 95-100٪ من سعر السوق.
لذلك ، (مثل أي شخص آخر) واجهت مشكلة افتقار RosReestr للمعاملات.
مشكلة افتقار Rosreestr للمعاملات التجارية
في برمجة "المعاملات" ، وفي العقارات هي "التعامل مع بديل" (وأيضًا ، كجزء منه ، "الاتفاق على صندوق ودائع آمن") ، وكل شيء أكثر تعقيدًا هناك. أنا أخبرك.
جاء فاسيا لرؤية الشقة التي تبيعها بيتيا. وقد أحب Vasya كل شيء كثيرًا ، بما في ذلك السعر ، لكن Vasya ليس لديه مال. هكذا تبدأ قصتنا.
يمتلك Vasya ممتلكاته الخاصة ، والتي تحتوي على بعض القيم التي ليست ضرورية له بشكل خاص - عاش لومونوسوف في المنزل المجاور ، ويبلغ ارتفاع السقف سبعة أمتار ونصف متر ، وهناك قاعدة لزراعة الفاكهة وسوق بستاني قريب ، يمكنك المشي إلى Aeroexpress ، وهناك قبو 1 متر فوق الشقة يوجد علية مناسبة للملاحظات الفلكية. يدرك فاسيا أن هذه الميزات تزيد من سعر شقته ، ولكن ليس لنفسه. وقرر شراء شقة بيتيا وبيع شقته. ولكن لبيعها من أجل شراء شقة بيتي ، وليس فقط. في لغة أصحاب العقارات ، يسمى هذا - "يتم تحديد البديل".
الآن دعونا نلقي نظرة على هذا الموقف من منظور بيتيا. الحقيقة هي أن بيتيا ليس مهتمًا أيضًا بالجلوس على انخفاض الأموال ، فهو يبيع شقة من أجل شراء شقة في مدينة فالينور الجان ، لكنه لم يبحث بعد في أي منها. في لغة أصحاب العقارات ، يسمى هذا "التعامل مع بديل".
يمتلك اثنان من الجان من Middle-earth ، Maglor و Maedhros ، عقارات مناسبة (وفقًا لمعايير Petit) في مدينة Valinor ، والتي يتم بيعها بشكل عاجل ، حيث يتم إرسالهم لخدمة Melkor. في لغة أصحاب العقارات ، يسمى هذا "البيع المجاني".
لذلك ، يجد Vasya عميل Seryozha. الآن ، يجد بيتيا خيارين مناسبين له في مدينة فالينور. نذهب إلى تسجيل الصفقة. من أجل البساطة ، دعنا نقول أنه لا أحد من أطراف الصفقة يستخدم الرهن العقاري وليس لديه مساهم أقلية. وبالتالي ، يجب الآن تنفيذ الإجراءات التالية:
1. يعطي Seryozha المال لبيتيا.
2. يسلم فاسيا شقته لسريوزا.
3. بيتيا يسلم شقته لفاسيا.
4. إما ماغلور أو مايدروس ، يسلمون شقتهم في فالينور إلى بيت ويتلقون أموال سيريوزا.
5. يذهب مالكور ومايدروس إلى موردور لخدمة ملكور.
سيكون من المثالي إرسال البرنامج النصي التالي إلى Rosreestr لتنفيذه:
ابدأ المعاملة امنح شقة Vasya إلى Seryozha.
أعط شقة بيتيا لفاسيا.
ابدأ
بمنح شقة Malkor إلى
Petya امنح أموال Seryozha إلى Malkor IF_
ERROR: امنح
شقة Maedhros إلى
Petya امنح أموال Seryozha إلى Maedhros في
النهاية
ارتكاب المعاملة
هذا نص مبسط لمعاملة مع بديل ، بافتراض أن جميع الشقق بها مالك بالغ (وقادر) ، وأن أسعارها متساوية ، وأن مدفوعات أصحاب العقارات (إن وجدت) تُدفع خارج مراحل المعاملة.
ومع ذلك ، لا يدعم Rosreestr المعاملات. سيتم تنفيذ جميع الإجراءات بشكل تسلسلي ومستقل ، واحدة تلو الأخرى ، دون التراجع عن المعاملة بأكملها إذا لم يتم إكمال أحدها. الحد الأقصى الذي يمكن تحقيقه - نظرًا لأن Rosreestr و MFC لا يعملان مع تحويل النقود - هو وضع الأموال في صندوق ودائع آمن ، مع شروط الوصول إليها لـ Vasya و Petit و Seryozha (إذا لم يتم تسجيل أي معاملة على الإطلاق) والجهات الفاعلة الأخرى ، عند تقديمهم للعقود المسجلة بواسطة Rosreestr. (وبالمناسبة ، لا تتحقق البنوك بشكل مستقل من صحة العقود ، أي أنها تثق في صحة الأوراق المالية للمشاركين في المعاملة).
بالإضافة إلى مخاطر التنفيذ غير الكامل للمعاملة ، هناك مشكلة أخرى تتمثل في أنه إذا تمكن المشاركون الآخرون من الانتقال إلى مسكنهم الجديد دون انتظار التسجيل الكامل (مرحبًا ، مسألة الدفع الناقص لفواتير الخدمات!) ، فلن يذهب ماغلور ومايدروس لخدمة Melkor قريبًا ، وربما لن يتمكن Maglor امسك Silmarils في يديه ، ببساطة لن يكون لديه الوقت. يتم تنفيذ المعاملات العقارية بالتتابع ، وستستغرق كل معاملة 9 أيام عمل على الأقل لإكمالها.
بالإضافة إلى ذلك ، لا يدعم Rosreestr رهن المساكن قيد الإنشاء بموجب DDU ، ولكن يمكن أن يكون هذا إجراءً أوليًا فيما يتعلق بعقود مستقبلية بسيطة.
الآن دعنا ننتقل إلى عيوب وأمنياتي بشأن نظم إدارة قواعد البيانات
1) الأول هو عدم وجود نظام للتحكم في الإصدار. إذا أجريت من جانب دلفي تطويرًا في صندوق الحماية الخاص بي ، ولم تظهر التغييرات التي أجريتها في المبرمجين الآخرين حتى لحظة التزامهم ، فلن يكون الأمر كذلك مع نظام إدارة قواعد البيانات. وحتى لو وثقوا بي مع وصول كامل (على الأقل في إطار العمل الضروري للمهمة الموكلة إلي) إلى قاعدة البيانات القتالية ، وهذا يحدث ، لا يمكنني تطويره. بينما أقوم بتصحيح كل شيء سوف ينهار. ما هو هذا العصر الحجري ؟؟؟ Sandbox للمطورين.
2) والثاني هو عدم وجود جداول معيارية محددة مسبقًا تصف العالم الحقيقي. كل شركة عملت فيها لها تنسيق جدول خاص بها يصف الأسماء (بالروسية و (على الأقل) الإنجليزية ، في حالات روسية مختلفة) لمدة اثني عشر شهرًا!
3) ثالثًا - وهنا سأستخدم مصطلحات Orakl - لا توجد طريقة لاستدعاء نص بسيط للإدراج أو التحديث باستخدام Returning ، كما نسميه Select. ربما هذه ليست مشاكل Orakl ، ولكن مشاكل تقاطع Delphi + Oracle.
4) رابعًا - الحاجة إلى تخصيص سلطة للإجراءات والوظائف التي أقوم بإنشائها حيث لا أريد القيام بذلك. لا أرغب في تعيين سلطة المستخدم الخاصة بالإجراء والوظيفة ثم تغييرها. لماذا ، إذا لم أكتب Grants بشكل صريح ، فلن يتمكن النظام بنفسه من النظر إلى الكائنات المعنية ، ووفقًا لحقوق التصرف معها ، يمنح أو لا يمنح مستخدمين معينين الحق في استدعاء الوظيفة؟ أنا مستعد لكتابة كلمة رئيسية واحدة لذلك عند كتابة الوظائف والإجراءات. أو ، والأفضل من ذلك ، السماح للمستخدم ببدء التنفيذ ، وإذا قاده فرع الخوارزمية إلى طلب لا يمتلك المستخدم حقوقًا بشأنه ، فسيتم التخلص منه مع وجود خطأ.