Чи можуть доменні моделі в базі даних бути стійким рішенням?

Я щойно розпочав нову роботу як розробник баз даних для компанії середнього та невеликого розміру, заснованої на технології Microsoft. Я рано помітив, наскільки практика відхиляється від того, що мене навчали в школі щодо найкращих практик, моделей дизайну, тестування та управління проектами.

Що мене найбільше клопоче - це те, як наш головний розробник баз даних (відтепер називається "Джон") зберігає модельну схему в базі даних! Ми робимо це, маючи 3 «чарівні» таблиці; одна для баз даних-схем, одна для таблиць і одна для стовпців.

Вставлення запису в таблицю " Таблиці " генерує (через тригер бази даних) фактичну відповідну таблицю. Вставлення рядка в таблицю " Рядки " оновлює таблицю з посиланням на цей рядок. Вони, у свою чергу, читаються його саморобною програмою C # для створення моделей C #, які використовуються розробниками інтерфейсів для контролерів і зовні.

Крім цього, більшість розробок проводиться згідно з рамками ASP.NET MVC .

Я бачу кілька недоліків у такому підході:

• Нам він потрібен для підтримки ОРМ, і він рідко встигає зробити це (безпека роботи хороша!)
• Тригери для таблиці "Таблиці" та "Рядки" є помилковими. Вони не підтримують оновлення таблиць, а також перевірки обмежень або більше "розширених" функцій. Хоча ми, безумовно, могли їх покращити, я ще не впевнений, чи це шлях.
• Утримання програмної логіки в базі даних відчуває себе дивно та обмежувально (хоча можливо розширити його моделі через C #).
• Його C # Модель-генератор повинен запускати вручну один з 3-х людей (серед яких я - один), і він ще недостатньо зрілий, щоб бути включеним в автоматизований процес збирання.

Кілька людей запропонували поетапно реалізувати справжній і перевірений продукт, такий як Entity Framework , але він відхиляє його, заявивши, що збереження ділової логіки в кодовому рівні підходить лише для невеликих програм та завантажувальних проектів для стартапів.

Ця публікація веде до чогось, що могло б виглядати як впевнене обговорення, але це не мій намір. Я просто хочу роз’яснення стосовно нашого архітектурного підходу.

Чи може зберігання доменних моделей у базі даних бути стійким рішенням для компанії, що росте?

Ви описуєте внутрішню платформу.

Проблема внутрішніх платформ полягає в тому, що ви винаходите всі механізми платформи чи технології (в даному випадку реляційну базу даних), які були відточені та вдосконалені протягом десятиліть еволюції та зусиль, але відновлювали їх погано. Ви обминаєте всі оптимізації, доступні для тих, хто обирає більш звичайний дизайн, і торгуєте початковою простотою та вишуканістю для майбутньої складності та труднощів.

Однак, якщо кінцевим продуктом цього процесу є реальні таблиці та реальні класи, що моделюють реальні об'єкти бізнес-домену, я не бачу великої шкоди в цьому підході, крім незрілості інструментів. Stack Exchange фактично використовує свій власний, доморощений ORM, і це, здається, спрацювало для них. Тож я знаю, що такі види "котеджних" підходів можуть працювати.

Зауважте, що більшість ОРМ, які використовують підхід «на першому столі», просто дивляться на структуру таблиці в базі даних для створення класів. Таблиці "таблиця" та "рядок", створені вашим другом, - це лише метадані, які вже існують у системних таблицях більшості сучасних систем реляційних баз даних.

Подальше читання
проекту "Бачення", застережливої ​​розповіді про ефект внутрішньої платформи
_{(Ви можете пропустити преамбулу і почати читати в підзаголовку "Представлення бачення")}