Mong muốn của tôi cho DBMS của tương lai, cũng như cho Rosreestr về mặt giao dịch

Mong muốn của tôi cho DBMS của tương lai, cũng như cho Rosreestr về mặt giao dịch
Client tương tác với cơ sở dữ liệu.
Từ trang web http://corchaosis.ru, của Jonathan Tiong.

Bên cạnh việc tôi là một lập trình viên (chủ yếu là Delphi + đủ loại DBMS khác nhau, gần đây là ORACLE, + một chút PHP), tôi còn có một sở thích - mua bán căn hộ. Tôi mua một căn hộ đang trong giai đoạn xây dựng từ một nhà phát triển ít nhiều đáng tin cậy với giá hấp dẫn (ví dụ: Samolet hiện là một nhà phát triển như vậy, các căn hộ gần ga tàu điện ngầm Nekrasovka đang được rao bán), tôi chờ bàn giao nhà (thường hai năm sau, điều này xảy ra với những lời đề nghị rẻ tiền), tôi sửa chữa nó và sau đó bán nó với giá 95-100% so với giá thị trường.

Vì vậy, tôi (giống như những người khác) gặp phải vấn đề về việc thiếu khả năng giao dịch của RosReestr.

Vấn đề thiếu bản chất giao dịch của các giao dịch của Rosreestr

Trong lập trình "Giao dịch" và trong bất động sản, đó là "Thỏa thuận với giải pháp thay thế" (và cũng là một phần của nó, "Thỏa thuận hộp ký gửi") và ở đó mọi thứ phức tạp hơn một chút. Tôi đang nói.

Vasya đến xem căn hộ mà Petya đang bán. Và Vasya rất thích mọi thứ, kể cả giá cả, nhưng Vasya không có tiền. Đây là cách câu chuyện của chúng tôi bắt đầu.

Vasya có tài sản riêng, có một số giá trị không đặc biệt cần thiết đối với anh ta - Lomonosov sống ở một ngôi nhà bên cạnh, trần nhà cao bảy mét rưỡi, có một cơ sở bán trái cây và chợ Sadovod gần đó , có thể đi bộ ra Aeroexpress, có tầng hầm dưới chung cư 1m, phía trên chung cư có gác xép thuận tiện cho việc quan sát thiên văn. Vasya hiểu rằng những tính năng này làm tăng giá căn hộ của anh ấy, nhưng không phải cho chính anh ấy. Và anh ta quyết định mua căn hộ của Petya và bán căn hộ của mình. Nhưng bán nó để mua căn hộ của Petya, và không chỉ. Trong ngôn ngữ của những người môi giới, điều này được gọi là - "Phương án thay thế được chọn."

Bây giờ hãy xem xét tình huống này từ phía Petya. Sự thật là Petya cũng không thích ngồi trên đồng tiền mất giá, anh ấy đang bán một căn hộ để mua một căn hộ ở thành phố yêu tinh Valinor, nhưng anh ấy vẫn chưa xem qua căn nào. Trong ngôn ngữ của những người môi giới, điều này được gọi là - "Thỏa thuận với một giải pháp thay thế."

Hai yêu tinh của Trung Địa, Maglor và Maedhros, có bất động sản phù hợp (tiêu chí của Petit) ở thành phố Valinor, cần bán gấp để phục vụ Melkor. Trong ngôn ngữ của những người môi giới, điều này được gọi là - "Bán miễn phí".

Vì vậy, Vasya tìm thấy một khách hàng là Serezha. Giờ đây, Petya tìm thấy hai lựa chọn phù hợp cho mình ở thành phố Valinor. Chúng ta sẽ thực hiện một thỏa thuận. Giả sử đơn giản rằng không ai trong số những người tham gia giao dịch sử dụng thế chấp và không có cổ đông nhỏ. Do đó, các hành động sau đây sẽ diễn ra:
1. Seryozha đưa tiền cho Petya.
2. Vasya nhường căn hộ của mình cho Seryozha.
3. Petya nhường căn hộ của mình cho Vasya.
4. Maglor hoặc Maedhros giao căn hộ của họ ở Valinor cho Petya và nhận tiền của Seryozha.
5. Malkor và Maedhros đến Mordor để phục vụ Melkor.

Sẽ là lý tưởng nếu chuyển tập lệnh sau sang Rosreestr để thực thi:

BẮT ĐẦU GIAO DỊCH
Đưa căn hộ của Vasya cho Seryozha.
Đưa căn hộ của Petit cho Vasya.
bắt đầu
Tặng căn hộ của Malkor cho Petya
Đưa tiền của Seryozha cho Malkor
IF_ERROR:
Đưa căn hộ của Maedhros cho Petya
Đưa tiền của Seryozha cho Maedhros
cuối
CAM KẾT GIAO DỊCH

Đây là một kịch bản giao dịch đơn giản hóa với một giải pháp thay thế, giả định rằng tất cả các căn hộ đều có một chủ sở hữu là người lớn (và có khả năng), giá của chúng bằng nhau và người môi giới (nếu có) được thanh toán bất kể các giai đoạn của giao dịch.

Tuy nhiên, Rosreestr không hỗ trợ giao dịch. Tất cả các hành động sẽ được thực hiện tuần tự và độc lập, lần lượt, mà không hoàn thành toàn bộ giao dịch nếu một trong số chúng chưa được hoàn thành. Mức tối đa có thể đạt được - do Rosreestr và MFC không hoạt động với việc chuyển tiền mặt - là gửi tiền vào ô ngân hàng, với các điều kiện để Vasya, Petya, Serezha tiếp cận chúng (nếu không có giao dịch nào được đăng ký ở tất cả), và các bên tham gia khác, sau khi trình bày các thỏa thuận đã được đăng ký bởi Rosreestr. (Và nhân tiện, các ngân hàng không xác minh độc lập tính xác thực của hợp đồng, nghĩa là họ tin tưởng vào tính xác thực của giấy tờ của những người tham gia giao dịch).

Ngoài những rủi ro khi không hoàn thành giao dịch đầy đủ, một vấn đề khác là nếu những người tham gia khác có thể chuyển đến nơi ở mới của họ mà không cần đợi đăng ký đầy đủ (xin chào, câu hỏi về việc thanh toán thiếu hóa đơn tiện ích!), thì Maglor và Maedhros sẽ không sẽ sớm phục vụ Melkor, và có lẽ Maglor sẽ không thể cầm Silmarils trong tay, đơn giản là anh ta sẽ không có thời gian. Các giao dịch bất động sản được thực hiện tuần tự và việc xử lý từng giao dịch sẽ mất ít nhất 9 ngày làm việc.

Ngoài ra, Rosreestr không hỗ trợ việc đóng gói nhà ở đang được xây dựng theo DDU, nhưng nó có thể, đây là một hành động cơ bản liên quan đến một hợp đồng tương lai đơn giản.

Bây giờ hãy chuyển sang những thiếu sót và Danh sách mong muốn của tôi về DBMS

1) Đầu tiên là thiếu hệ thống kiểm soát phiên bản. Nếu từ phía Delphi, tôi đang phát triển trong hộp cát của mình và những thay đổi tôi đã thực hiện sẽ không xuất hiện với các lập trình viên khác cho đến khi họ được cam kết, thì điều đó không xảy ra với DBMS. Và ngay cả khi tôi được tin tưởng với quyền truy cập đầy đủ (ít nhất là trong khuôn khổ nhiệm vụ được giao) vào cơ sở dữ liệu chiến đấu, và điều này xảy ra, tôi không thể phát triển trên đó. Trong khi tôi đang gỡ lỗi, mọi thứ sẽ sụp đổ. Thời kỳ đồ đá này là gì? Tạo hộp cát cho nhà phát triển.

2) Thứ hai là thiếu các bảng tiêu chuẩn hóa được cài đặt sẵn mô tả thế giới thực. Mỗi công ty tôi từng làm việc đều có định dạng bảng riêng mô tả tên (bằng tiếng Nga và (ít nhất) tiếng Anh, trong các trường hợp khác là tiếng Nga) của mười hai tháng!

3) Thứ ba - và ở đây tôi sẽ sử dụng thuật ngữ Oracle - không có cách nào để gọi một tập lệnh Chèn hoặc Cập nhật đơn giản mà sử dụng Trả lại, cách chúng ta gọi là Chọn. Có lẽ đây không phải là vấn đề của Oracle, mà là vấn đề về giao diện Delphi + Oracle.

4) Thứ tư, nhu cầu gán quyền hạn cho các thủ tục và chức năng tôi tạo ra nơi tôi không muốn làm điều này. Tôi không muốn đặt và sau đó thay đổi quyền của người dùng đối với các thủ tục và chức năng. Tại sao, nếu tôi không viết Grants một cách rõ ràng, liệu hệ thống có thể tự xem xét các đối tượng liên quan và, theo quyền hành động với chúng, cấp hoặc không cho một số người dùng nhất định quyền gọi chức năng? Tôi sẵn sàng viết một từ khóa cho điều này khi viết các hàm và thủ tục. Hoặc, tốt hơn nữa, hãy để người dùng bắt đầu thực thi và nếu nhánh thuật toán dẫn anh ta đến một yêu cầu mà người dùng không có quyền, anh ta sẽ loại bỏ nó với một lỗi.

Nguồn: www.habr.com

Thêm một lời nhận xét