Czy modele domen w bazie danych mogą być trwałym rozwiązaniem?

Właśnie zacząłem od nowej pracy jako programista baz danych dla średniej wielkości firmy opartej na technologii Microsoft. Zauważyłem wcześnie, jak wiele praktyk różni się od tego, czego nauczono mnie w szkole w zakresie najlepszych praktyk, wzorców projektowych, testów i zarządzania projektami.

Najbardziej denerwuje mnie to, w jaki sposób nasz główny programista baz danych (odtąd zwany „John”) utrzymuje schemat modelu w bazie danych! Robimy to, mając 3 „magiczne” stoły; jeden dla schematów baz danych, jeden dla tabel i jeden dla kolumn.

Wstawienie rekordu do tabeli „ Tabele ” generuje (poprzez wyzwalacz bazy danych) rzeczywistą, odpowiednią tabelę. Wstawienie wiersza do tabeli „ Wiersze ” aktualizuje tabelę, do której istnieje odniesienie, z tym wierszem. Są one z kolei odczytywane przez jego domowy program w języku C # w celu wygenerowania modeli C #, które są używane przez programistów frontendów dla kontrolerów i na zewnątrz.

Poza tym większość prac rozwojowych odbywa się zgodnie ze środowiskiem ASP.NET MVC .

Widzę kilka wad tego podejścia:

• Potrzebujemy go do utrzymania ORM, a on rzadko ma na to czas (bezpieczeństwo pracy jest dobre!)
• Wyzwalacze dla tabeli „Tabele” i „Rzędy” są wadliwe. Nie obsługują aktualizacji tabel, ograniczeń Check ani bardziej „zaawansowanych” funkcji. Chociaż z pewnością moglibyśmy je ulepszyć, nie jestem jeszcze pewien, czy to jest właściwa droga.
• Utrzymywanie logiki programowej w bazie danych jest dziwne i restrykcyjne (chociaż możliwe jest rozszerzenie jego modeli przez C #).
• Jego generator modeli w języku C # musi być uruchamiany ręcznie przez jedną z 3 osób (wśród których jestem jedną z nich) i nie jest jeszcze wystarczająco dojrzały, aby włączyć się w proces automatycznej kompilacji.

Kilka osób zaproponowało wprowadzenie prawdziwego i przetestowanego produktu, takiego jak Entity Framework , ale odrzuca go, twierdząc, że utrzymanie logiki biznesowej w warstwie kodu jest odpowiednie tylko dla małych aplikacji i projektów bootstrapowych dla startupów.

Ten post prowadzi do czegoś, co mogłoby wyglądać na uprzejmą dyskusję, ale nie o to mi chodzi. Chcę tylko wyjaśnienia na temat naszego podejścia architektonicznego.

Czy utrzymywanie modeli domen w bazie danych może być trwałym rozwiązaniem dla rozwijającej się firmy?

Opisujesz wewnętrzną platformę.

Problem z wewnętrznymi platformami polega na tym, że na nowo wymyślasz wszystkie mechanizmy platformy lub technologii (w tym przypadku relacyjnej bazy danych), które zostały dopracowane i udoskonalone w ciągu dziesięcioleci ewolucji i wysiłku, ale źle je wynaleziono. Pomijasz wszystkie optymalizacje, które są dostępne dla tych, którzy wybierają bardziej konwencjonalny projekt, i handlujesz pierwotną prostotą i elegancją dla przyszłej złożoności i trudności.

To powiedziawszy, jeśli produktem końcowym tego procesu są prawdziwe tabele i prawdziwe klasy modelujące prawdziwe obiekty w domenie biznesowej, nie widzę większych szkód w tym podejściu, poza niedojrzałością narzędzi. Stack Exchange faktycznie używa własnej, własnej produkcji ORM, i wydaje się, że to zadziałało. Wiem więc, że tego rodzaju podejścia „wiejskie” mogą działać.

Zauważ, że większość ORM, które stosują podejście „najpierw do tabeli”, po prostu patrzy na strukturę tabeli w bazie danych, aby utworzyć klasy. Tabele „tabel” i „wierszy”, które utworzył twój przyjaciel, to jedynie metadane, które już istnieją w tabelach systemowych większości nowoczesnych systemów relacyjnych baz danych.

Dalsza lektura
Projekt „Wizja”, przestroga dotycząca efektu platformy wewnętrznej
_{(możesz pominąć preambułę i zacząć czytać w podtytule „Przedstawiamy wizję”)}