13

I just started at a new job as a database developer for a medium-small sized, company based on Microsoft-technology. I noticed early on how much practices deviate from what I've been taught at school regarding best practices, design patterns, testing and project management.

What is bugging me the most is how our main database developer (henceforth called "John") keeps the model schema in the database! We do this by having 3 "magic" tables; one for database-schemas, one for tables and one for columns.

Inserting a record into the "Tables"-table generates (through a database trigger), the actual, corresponding table. Inserting a row into the "Rows"-table updates the referenced table with that row. These are in turn read by his homemade C#-program to generate C# models, which are used by the frontend-developers for controllers and outwards.

Apart from this, most of the development is done according to the ASP.NET MVC framework.

I see a couple of flaws with this approach:

  • We need him to maintain the ORM, and he rarely has the time to do so (job security is good!)
  • The The triggers for the "Tables" and "Rows" table are flawed. They don't support table updates, nor Check-constraints or more "advanced" features. While we could surely improve them, I am not yet sure if this is the way to go.
  • Keeping the programmatic logic in the database feels weird and restrictive (although it is possible to extend his models through C#).
  • His C# Model-generator has to be run manually by one of 3 people (among which I am one), and is not yet mature enough to be included into an automated build process.

Several people have suggested phasing in a true and tested product like Entity Framework, but he dismisses it, claming that keeping the business logic in the code-layer is only suitable for small-scale applications and bootstrap projects for startups.

This post is leading towards something that could look like a opinionated discussion, but that is not my intention. I just want some clarification regarding our architectural approach.

Can keeping the domain models in the database be a sustainable solution for a company in growth?

  • Domain models are very closely tied to domain driven design. The whole point of domain driven design is to be free from the data driven design, where data (ie. the database) is the core of the application. Said approach and domain models do not really go together. When developing following the domain driven design practices, you don't care where the data comes from, you just use it and perform logic on it in your business layer. – Andy Nov 13 '15 at 17:44
  • I'm a little unclear on what you mean by "keeping the programmatic logic in the database." Can you clarify that? – Robert Harvey Nov 13 '15 at 17:48
  • The business logic in code is exactly the right way. The db should be a dumb datastore, nothing else. – Andy Nov 13 '15 at 23:38
  • @Andy I guess this depends. May be their DBA is the center of the team and he keeps all bussiness logic in database, which is then queried by dumb stored procs calls, extracts data into POCO's etc. This is a questionable approach but I know teams, keeping most of business logic if not all of it in DB. – Vladislav Rastrusny Nov 16 '15 at 14:31
  • @VladislavRastrusny Whatever the reason, keeping business logic in the db is an extremely poor design. – Andy Nov 16 '15 at 23:58
16

You're describing an Inner Platform.

The problem with inner platforms is that you reinvent all of the mechanisms of a platform or technology (in this case, a relational database) that have been honed and perfected over decades of evolution and effort, but re-inventing it poorly. You're bypassing all of the optimizations that are available to those who choose a more conventional design, and trading initial simplicity and elegance for future complexity and hardship.

That said, if the end product of this process is real tables and real classes modelling real business domain objects, I don't see much harm in this approach, apart from the immaturity of the tools. Stack Exchange actually uses their own, homegrown ORM, and that seems to have worked out for them. So I know that these kinds of "cottage" approaches can work.

Note that most ORM's that take the "table-first" approach simply look at the table structure in the database to create the classes. The "table" and "row" tables that your friend has created is merely metadata that already exists in the system tables of most modern relational database systems.

Further Reading
The "Vision" project, a cautionary tale about inner platform effect
(You can skip the preamble and start reading at the subheading "Introducing Vision")

  • 2
    Interesting read, I could definitely draw anologies. I'm still new and will remain a spectator for now, but I will definitely keep it under the lens. Thanks for a good response! – krystah Nov 19 '15 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.