האיחולים שלי ל-DBMS של העתיד, כמו גם ל-Rosreestr מבחינת טרנזקציונליות

הלקוח מקיים אינטראקציה עם מסד הנתונים.
מתוך האתר http://corchaosis.ru, מאת ג'ונתן טיונג.

חוץ מזה שאני מתכנת (בעיקר דלפי + כל מיני DBMS שונים, לאחרונה ORACLE, + קצת PHP), יש לי תחביב - קנייה ומכירה של דירות. אני קונה דירה בשלב הבנייה מיזם אמין פחות או יותר במחיר טעים (למשל, עכשיו סמולט הוא יזם כזה, דירות ליד תחנת המטרו נקרסובקה עומדות למכירה), אני מחכה למסירת הבית (לעיתים קרובות שנתיים מאוחר יותר, זה קורה עם הצעות זולות), אני עושה את זה כדי לתקן את זה ואז מוכר את זה עבור 95-100% ממחיר השוק שלו.

אז, אני (כמו כולם) נתקלתי בבעיה של חוסר העסקאות של RosReestr.

הבעיה של חוסר האופי העסקתי של העסקאות של רוזריסטר

בתכנות "עסקה" ובנדל"ן זה "התמודד עם אלטרנטיבה" (וגם במסגרתו "הסכם קופת פיקדון"), ושם הדברים קצת יותר מסובכים. אני מספר.

ואסיה הגיעה לצפות בדירה שפטיה מוכרת. ואסיה אהב הכל מאוד, כולל המחיר, אבל לואסיה אין כסף. כך מתחיל הסיפור שלנו.

לוואסיה יש נכס משלו, שיש לו כמה ערכים שאינם נחוצים לו במיוחד - לומונוסוב גר בבית סמוך, גובה התקרה הוא שבעה וחצי מטרים, יש בסיס פירות ושוק סדוב בקרבת מקום. , ניתן ללכת ברגל לאירואקספרס, יש מרתף מתחת לדירה 1 מטר, מעל הדירה יש עליית גג נוחה לתצפיות אסטרונומיות. ואסיה מבין שמאפיינים אלה מייקרים את מחיר הדירה שלו, אבל לא לעצמו. והוא מחליט לקנות את דירתה של פטיה, ולמכור את דירתו. אבל למכור אותה כדי לקנות את הדירה של פטיה, ולא סתם. בשפת המתווכים זה נקרא - "החלופה נבחרת".

עכשיו בואו נסתכל על המצב הזה מהצד של פטיה. העובדה היא שגם פטיה לא מעוניין לשבת על פחת כסף, הוא מוכר דירה על מנת לקנות דירה בעיר האלפים ולינור, אבל הוא עדיין לא בדק איזו. בשפת המתווכים זה נקרא - "התמודד עם חלופה".

לשני גמדונים של הארץ התיכונה, מגלוור ומאדרוס, יש נדל"ן מתאים (הקריטריונים של פטיט) בעיר ולינור, שנמכרת בדחיפות, מכיוון שהם נשלחים לשרת את מלקור. בשפת המתווכים זה נקרא - "מכירה חופשית".

אז, ואסיה מוצאת לקוחה סרז'ה. כעת, פטיה מוצאת שתי אפשרויות מתאימות עבורו בעיר ולינור. אנחנו הולכים לעשות עסקה. נניח לשם הפשטות שאף אחד מהמשתתפים בעסקה אינו משתמש במשכנתא ואין לו בעל מניות מינורי. לפיכך, הפעולות הבאות אמורות להתבצע כעת:
1. סריוז'ה נותנת כסף לפטיה.
2. ואסיה נותן את דירתו לסריוז'ה.
3. פטיה נותן את דירתו לווסיה.
4. או מגלור או מדרוס מוסרים את דירתם בוואלינור לפטיה ומקבלים את הכסף של סריוז'ה.
5. מלקור ומאדרוס הולכים למורדור לשרת את מלקור.

זה יהיה אידיאלי להעביר את התסריט הבא ל-Rosreestr לביצוע:

התחל בעסקה
תן את הדירה של ואסיה לסריוז'ה.
תן את הדירה של פטיט לואסיה.
להתחיל
תן את הדירה של מלקור לפטיה
תן את הכסף של סריוז'ה למלקור
IF_ERROR:
תן את הדירה של מאדרוס לפטיה
תן את הכסף של סריוז'ה למיידרוס
סוף
- עסקה

מדובר בתסריט עסקה מפושט עם חלופה, בהנחה שלכל הדירות יש בעלים אחד מבוגר (וכשיר), שהמחירים שלהן שווים, ושהמתווכים (אם יש) מקבלים תשלום ללא קשר לשלבי העסקה.

עם זאת, Rosreestr אינו תומך בעסקאות. כל הפעולות יבוצעו ברצף ובאופן עצמאי, בזו אחר זו, מבלי לבטל את העסקה כולה אם אחת מהן לא הושלמה. המקסימום שניתן להשיג - בהתחשב בכך שרוזריסטר וה-MFC לא עובדים עם העברת מזומנים - הוא להכניס כסף לתא בנק, עם תנאי הגישה אליהם על ידי Vasya, Petya, Serezha (אם לא נרשמה עסקה בכלל), ושחקנים נוספים, בהצגת הסכמים שנרשמו על ידי Rosreestr. (ואגב, הבנקים אינם מוודאים באופן עצמאי את האותנטיות של חוזים, כלומר, הם סומכים על האותנטיות של הניירות של המשתתפים בעסקה).

בנוסף לסיכונים של אי השלמת העסקה במלואה, בעיה נוספת היא שאם משתתפים אחרים יוכלו להיכנס לדיור החדש שלהם מבלי להמתין לרישום מלא (שלום, שאלת תשלום חסר של חשבונות חשמל!), אז מגלוור ומעדרוס לא יעשו זאת. בקרוב לך לשרת את מלקור, ואולי מגלוור לא יוכל להחזיק את הסילמארילים בידיו, פשוט לא יהיה לו זמן. עסקאות מקרקעין מבוצעות ברצף, והעיבוד של כל עסקה ייקח לפחות 9 ימי עבודה.

בנוסף, Rosreestr לא תומך בשיעבוד של דיור בבנייה במסגרת DDU, אבל זה יכול, זו פעולה אלמנטרית ביחס לעתיד פשוט.

עכשיו בואו נעבור לחסרונות ולרצועה שלי לגבי ה-DBMS

1) הראשון הוא היעדר מערכת בקרת גרסאות. אם מהצד של דלפי אני מפתח בארגז החול שלי, והשינויים שעשיתי לא יופיעו למתכנתים אחרים עד שהם יתחייבו, אז זה לא כך ב-DBMS. וגם אם אמון על גישה מלאה (לפחות במסגרת המשימה שהוטלה עליי) למאגר הקרבות, וזה קורה, אני לא יכול להתפתח עליו. בזמן שאני מנקה באגים, הכל יתמוטט. מה זה תקופת האבן הזו? צור ארגז חול למפתחים.

2) השני הוא היעדר טבלאות סטנדרטיות מותקנות מראש המתארות את העולם האמיתי. לכל חברה שעבדתי בה יש פורמט טבלה משלה המתאר את השמות (ברוסית ו(לפחות) באנגלית, במקרים שונים של רוסית) של שנים עשר חודשים!

3) שלישית - וכאן אשתמש בטרמינולוגיה של Oracle - אין דרך לקרוא לסקריפט פשוט של Insert או Update שמשתמש ב-Returing, כמו שאנחנו קוראים ל-Select. אולי אלו לא בעיות של Oracle, אלא בעיות ממשק של Delphi + Oracle.

4) רביעית, הצורך להקצות סמכויות לפרוצדורות ולפונקציות שאני יוצר היכן שאני לא רוצה לעשות זאת. אני לא רוצה להגדיר, ולאחר מכן לשנות, את ההרשאות של המשתמש עבור נהלים ופונקציות. מדוע, אם לא כתבתי במפורש Grants, המערכת עצמה לא יכלה להסתכל על האובייקטים המעורבים, ובהתאם לזכויות לפעול איתם, לתת או לא למשתמשים מסוימים את הזכות להתקשר לפונקציה? אני מוכן לכתוב מילת מפתח אחת עבור זה בעת כתיבת פונקציות ונהלים. או, אפילו יותר טוב, תן למשתמש להתחיל בביצוע, ואם ענף האלגוריתם יוביל אותו לבקשה שאין למשתמש זכויות עליה, הוא יזרוק אותה עם שגיאה.

מקור: www.habr.com