مشتری با پایگاه داده تعامل دارد.
از سایت ، توسط جاناتان تیونگ.
علاوه بر این که من یک برنامه نویس هستم (عمدتاً دلفی + انواع DBMS های مختلف، اخیراً ORACLE، + کمی PHP)، یک سرگرمی هم دارم - خرید و فروش آپارتمان. من یک آپارتمان در مرحله ساخت و ساز از یک توسعه دهنده کم و بیش قابل اعتماد با قیمت مناسب خریداری می کنم (به عنوان مثال، اکنون Samolet چنین توسعه دهنده ای است، آپارتمان های نزدیک ایستگاه مترو Nekrasovka به فروش می رسد)، منتظر تحویل خانه باشید (اغلب دو سال‌ها بعد، این اتفاق با پیشنهادهای ارزان‌قیمت می‌افتد)، آن را بازسازی می‌کنم و سپس آن را به 95 تا 100 درصد قیمت بازار می‌فروشم.
بنابراین، من (مانند هر کس دیگری) با مشکل عدم امکان تراکنش RosReestr مواجه شدم.
مشکل فقدان تراکنش های معاملاتی Rosreestr
در برنامه نویسی "معامله" و در املاک و مستغلات "معامله با جایگزین" (و همچنین، به عنوان بخشی از آن، "قرارداد صندوق امانات")، و کمی پیچیده تر است. دارم بهت میگم.
واسیا آمد تا آپارتمانی را که پتیا می فروخت مشاهده کند. و واسیا واقعا همه چیز را دوست داشت، از جمله قیمت، اما واسیا پولی ندارد. داستان ما اینگونه آغاز می شود.
واسیا دارایی خود را دارد که دارای ارزش هایی است که برای او ضروری نیست - لومونوسوف در خانه همسایه زندگی می کرد ، ارتفاع سقف هفت و نیم متر است ، پایه میوه و سبزیجات و بازار سادوود وجود دارد. در همان نزدیکی، می توانید در Aeroexpress راه بروید، زیر آپارتمان یک زیرزمین با ارتفاع 1 متر وجود دارد، یک اتاق زیر شیروانی در بالای آپارتمان وجود دارد که برای مشاهدات نجومی مناسب است. واسیا می داند که این ویژگی ها قیمت آپارتمان او را افزایش می دهد، اما نه برای خودش. و او تصمیم می گیرد آپارتمان پتیا را بخرد و آپارتمان خود را بفروشد. اما فروش دقیقاً به منظور خرید آپارتمان پتیا و نه فقط. در زبان مشاوران املاک، به این می گویند «یک جایگزین انتخاب شده است».
حالا بیایید از سمت پتیا به این وضعیت نگاه کنیم. واقعیت این است که پتیا نیز علاقه ای به نشستن روی پول های استهلاک ندارد، او آپارتمان را می فروشد تا برای خود آپارتمانی در شهر الف ها والینور بخرد، اما هنوز به کدام یک نگاه نکرده است. در زبان مشاوران املاک، به این "معامله با یک جایگزین" می گویند.
دو الف از سرزمین میانه، ماگلور و مائدروس، دارای املاک و مستغلات مناسب (بر اساس معیارهای پتیا) در شهر والینور هستند که فوراً فروخته می شوند، زیرا می خواهند به ملکور خدمت کنند. در زبان مشاوران املاک به این "فروش رایگان" می گویند.
بنابراین، واسیا یک مشتری پیدا می کند، Seryozha. حالا پتیا دو گزینه مناسب برای او در شهر والینور پیدا می کند. ما در شرف نهایی کردن معامله هستیم. برای سادگی فرض می کنیم که هیچ یک از طرفین معامله از رهن استفاده نمی کنند و افراد صغیر را به عنوان مالک سهام ندارند. بنابراین، اکنون باید اقدامات زیر انجام شود:
1. سریوژا به پتیا پول می دهد.
2. واسیا آپارتمان خود را به سریوژا می دهد.
3. پتیا آپارتمان خود را به واسیا می دهد.
4. یا Maglor یا Maedhros آپارتمان خود را در Valinor به پتا منتقل می کنند و پول Seryozha را دریافت می کنند.
5. مالکور و مائدروس برای خدمت به ملکور به موردور می روند.
ایده آل است که اسکریپت زیر را برای اجرا به Rosreestr ارسال کنید:
شروع معامله
آپارتمان واسیا را به سریوژا بدهید.
آپارتمان پتیا را به واسیا بدهید.
شروع
آپارتمان مالکور را به پتیا بدهید
پول سریوژا را به مالکور بدهید
IF_ERROR:
آپارتمان مائدروس را به پتیا بدهید
پول سریوژا را به مائدروس بدهید
پایان
انجام معامله
این یک اسکریپت تراکنش ساده با یک جایگزین است که فرض می‌کند همه آپارتمان‌ها یک مالک بزرگسال (و توانا) دارند، ارزش‌هایشان برابر است و به مشاوران املاک (در صورت وجود) بدون توجه به مراحل معامله پرداخت می‌شود.
با این حال، Rosreestr از تراکنشی پشتیبانی نمی کند. همه اقدامات به صورت متوالی و مستقل، یکی پس از دیگری انجام می شود، بدون اینکه در صورت شکست یکی از آنها، کل تراکنش به عقب برگردد. حداکثر چیزی که می توان به دست آورد - با توجه به اینکه Rosreestr و MFC با انتقال پول نقد کار نمی کنند - سپرده گذاری پول در یک صندوق امانات با شرایط دسترسی به آن توسط Vasya، Petya، Seryozha (در صورت عدم معامله) است. به هیچ وجه ثبت شده است)، و سایر بازیگران، پس از ارائه قراردادهای ثبت شده توسط Rosreestr. (و اتفاقاً بانک ها به طور مستقل صحت قراردادها را تأیید نمی کنند ، یعنی به صحت اوراق طرفین معامله اعتماد دارند).
علاوه بر خطرات تکمیل ناقص تراکنش، مشکل دیگر این است که اگر سایر شرکت‌کنندگان بتوانند بدون انتظار برای ثبت نام کامل به خانه جدید خود نقل مکان کنند (سلام، موضوع کم‌پرداخت قبوض آب و برق!)، ماگلور و مائدروس به زودی به در خدمت ملکور باشید، و شاید ماگلور نتواند این کار را انجام دهد و به سادگی فرصتی برای نگه داشتن سیلماریل ها در دستانش نداشته باشد. معاملات ملکی به صورت متوالی انجام می شود و اجرای هر معامله حداقل 9 روز کاری به طول می انجامد.
علاوه بر این، Rosreestr از محدودیت مسکن در حال ساخت تحت DDU پشتیبانی نمی کند، اما می تواند، این یک اقدام ابتدایی در رابطه با معاملات آتی ساده است.
حالا بیایید به کاستی ها و خواسته های من در مورد DBMS بپردازیم
1) اولین مورد عدم وجود سیستم کنترل نسخه است. اگر در سمت دلفی من در sandbox خودم توسعه می‌دهم و تغییراتی که ایجاد می‌کنم تا زمانی که برنامه‌نویسان متعهد نشده باشند برای برنامه‌نویسان دیگر ظاهر نمی‌شوند، در DBMS اینطور نیست. و حتی اگر دسترسی کامل (حداقل در محدوده آنچه برای وظیفه ای که به من محول شده است) به پایگاه داده رزمی اعتماد داشته باشم و این اتفاق بیفتد، نمی توانم روی آن توسعه دهم. در حالی که من در حال رفع اشکال هستم، همه چیز خراب می شود. این چه جور عصر حجریه؟؟؟ یک سندباکس برای توسعه دهندگان بسازید.
2) دوم عدم وجود جداول استاندارد از پیش تعریف شده برای توصیف دنیای واقعی است. هر شرکتی که من برای آن کار کرده‌ام، فرمت جدول مخصوص به خود را دارد که نام دوازده ماه (به روسی و (حداقل) انگلیسی، در موارد مختلف روسی را توصیف می‌کند!
3) سوم - و در اینجا من از اصطلاحات اوراکل استفاده خواهم کرد - هیچ راهی برای فراخوانی یک اسکریپت ساده Insert یا Update که از Returning استفاده می کند وجود ندارد، همان روشی که ما Select را صدا می زنیم. شاید اینها مشکلات اوراکل نباشد، بلکه مشکلاتی در رابط دلفی + اوراکل باشد.
4) چهارم - نیاز به تخصیص قدرت به رویه ها و عملکردهایی که ایجاد می کنم در جایی که نمی خواهم این کار را انجام دهم. من نمی خواهم مجوزهای کاربر را برای رویه ها و توابع تنظیم و سپس تغییر دهم. چرا، اگر من به صراحت Grants را ننوشتم، نمی‌توانستم خود سیستم به اشیاء درگیر نگاه کند و مطابق با حقوق اقدام با آنها، به کاربران خاصی حق فراخوانی یک تابع را بدهد یا نه؟ من حاضرم هنگام نوشتن توابع و رویه ها یک کلمه کلیدی برای این بنویسم. یا حتی بهتر از آن، اجازه دهید کاربر اجرا را شروع کند و اگر شاخه الگوریتم او را به درخواستی برساند که کاربر حقی برای آن ندارد، با خطا آن را بیرون می اندازد.
منبع: www.habr.com