Các mô hình miền trong cơ sở dữ liệu có thể là một giải pháp bền vững?

Tôi mới bắt đầu ở một công việc mới là nhà phát triển cơ sở dữ liệu cho một công ty có quy mô vừa, nhỏ dựa trên công nghệ của Microsoft. Tôi đã sớm nhận thấy có bao nhiêu thực hành đi chệch khỏi những gì tôi đã được dạy ở trường về các thực tiễn tốt nhất, các mẫu thiết kế, thử nghiệm và quản lý dự án.

Điều khiến tôi bận tâm nhất là cách nhà phát triển cơ sở dữ liệu chính của chúng tôi (từ đó gọi là "John") giữ lược đồ mô hình trong cơ sở dữ liệu! Chúng tôi làm điều này bằng cách có 3 bảng "ma thuật"; một cho các lược đồ cơ sở dữ liệu, một cho các bảng và một cho các cột.

Chèn một bản ghi vào " Bảng " có thể tạo ra (thông qua trình kích hoạt cơ sở dữ liệu), bảng thực tế, tương ứng. Chèn một hàng vào " Hàng " có thể cập nhật bảng được tham chiếu với hàng đó. Chúng lần lượt được đọc bởi chương trình C # tự chế của anh ấy để tạo các mô hình C #, được các nhà phát triển frontend sử dụng cho các bộ điều khiển và hướng ra ngoài.

Ngoài ra, hầu hết sự phát triển được thực hiện theo khung ASP.NET MVC .

Tôi thấy một vài sai sót với cách tiếp cận này:

• Chúng tôi cần anh ấy để duy trì ORM, và anh ấy hiếm khi có thời gian để làm điều đó (bảo mật công việc là tốt!)
• Các kích hoạt cho bảng "Bảng" và "Hàng" là thiếu sót. Họ không hỗ trợ cập nhật bảng, cũng như các ràng buộc Kiểm tra hoặc các tính năng "nâng cao" hơn. Trong khi chúng tôi chắc chắn có thể cải thiện chúng, tôi không chắc liệu đây có phải là hướng đi hay không.
• Giữ logic lập trình trong cơ sở dữ liệu cảm thấy kỳ lạ và hạn chế (mặc dù có thể mở rộng các mô hình của mình thông qua C #).
• Trình tạo mô hình C # của anh ta phải được điều hành thủ công bởi một trong 3 người (trong đó tôi là một) và chưa đủ chín chắn để được đưa vào quy trình xây dựng tự động.

Một số người đã đề xuất phân kỳ trong một sản phẩm thực sự và đã được thử nghiệm như Entity Framework , nhưng ông bác bỏ nó, cho rằng việc giữ logic kinh doanh trong lớp mã chỉ phù hợp cho các ứng dụng quy mô nhỏ và các dự án bootstrap cho khởi nghiệp.

Bài đăng này đang hướng tới một cái gì đó có thể trông giống như một cuộc thảo luận, nhưng đó không phải là ý định của tôi. Tôi chỉ muốn một số làm rõ về phương pháp kiến ​​trúc của chúng tôi.

Có thể giữ các mô hình miền trong cơ sở dữ liệu là một giải pháp bền vững cho một công ty tăng trưởng?

Bạn đang mô tả một Nền tảng bên trong.

Vấn đề với các nền tảng bên trong là bạn phát minh lại tất cả các cơ chế của nền tảng hoặc công nghệ (trong trường hợp này là cơ sở dữ liệu quan hệ) đã được mài giũa và hoàn thiện qua nhiều thập kỷ tiến hóa và nỗ lực, nhưng phát minh lại nó kém. Bạn đang bỏ qua tất cả các tối ưu hóa có sẵn cho những người chọn một thiết kế thông thường hơn, và giao dịch đơn giản và thanh lịch ban đầu cho sự phức tạp và khó khăn trong tương lai.

Điều đó nói rằng, nếu sản phẩm cuối cùng của quy trình này là các bảng thực và các lớp thực mô hình hóa các đối tượng miền kinh doanh thực , thì tôi không thấy nhiều tác hại trong cách tiếp cận này, ngoài sự non nớt của các công cụ. Stack Exchange thực sự sử dụng ORM của chính họ, cây nhà lá vườn của họ, và điều đó dường như đã giải quyết được cho họ. Vì vậy, tôi biết rằng những cách tiếp cận "tiểu" này có thể làm việc.

Lưu ý rằng hầu hết các ORM sử dụng phương pháp "đầu tiên bảng" chỉ cần nhìn vào cấu trúc bảng trong cơ sở dữ liệu để tạo các lớp. Các bảng "bảng" và "hàng" mà bạn của bạn đã tạo chỉ là siêu dữ liệu đã tồn tại trong các bảng hệ thống của hầu hết các hệ thống cơ sở dữ liệu quan hệ hiện đại.

Đọc thêm
Dự án "Tầm nhìn", một câu chuyện cảnh báo về hiệu ứng nền tảng bên trong
_{(Bạn có thể bỏ qua phần mở đầu và bắt đầu đọc ở phân nhóm "Giới thiệu Tầm nhìn")}