Database Model

[DotNetDublin]

I must admit as I tend to work in relative isolation when developing applications I have a habit of diving straight into SQL Server Management Studio and creating Tables and Fields off the top of my head and updating iteratively until I have a database schema that works for the needs of my application.

As this is an application that will be worked on by a team of developers I'm thinking it maybe appropriate to produce a database model.

Does anyone have recommendations on approaches/tools for documenting a database model?

[harperjohn]

I usually go "old school" and use the rules I learned form "database normalization"... I think 3rd normal form is a good target.

But that being said, most databases that I have personally designed have been relatively simple.

I feel that others in the group have lots of DB experience.

[adamfoneil]

I like dbdiagram.io. I think it could be a nifty collab tool for this problem, but I'm not sure how to integrate into our flow. I also wouldn't take it too literally or formally. I would suggest it as a place to think out loud about the db design -- letting us be specific enough to get some shared clarity on scope. My typical practice is to create C# model classes first, and use ModelSync to implement, but that really suits a solo dev better. I agree @harperjohn 3rd normal form is a good target. For some context, here is are the model classes in my Blazor "playground" project, and the diagram

[DotNetDublin]

I'm liking the look of dbdiagram.io so thanks for sharing that.

Yes, I would also tend to create my classes first however I'm wondering in this scenario whether it would make sense to -

1. Produce database diagram
2. Share for review
3. Repeat points 2 and 3 until database diagram is agreed
4. Create classes from database diagram

Depending on whether we decide on Entity Framework or Dapper in issue #5, the actual database tables maybe auto generated.

[jonhilt]

I like the idea of any tool/approach we adopt providing a means to "let us be specific enough to get some shared clarity on scope" as @adamfoneil mentioned.

One thing I find useful as a framing device for questions like this is to consider what approach will provide the shortest feedback loop.

To use an extreme example, a project which doesn't see any real use by a user for 12 months has a very slow feedback loop! (and lord knows I've encountered some of these in the past).

I'm always happy if I can get an entire vertical slice (a feature, or part of a feature) up and running fairly quickly, to test some assumptions and get real feedback, and conversely start to feel antsy if I'm spending too long 'building' without anything to show for it.

[AnkurSheel]

I think if we are saying we want to be agile, we should agree on a DB model (using peer reviews) that makes sense for the user story that we are working on.
Migrations albeit painful are unavoidable when working on long term projects so I don't think we should be scared of those.

I'm always happy if I can get an entire vertical slice (a feature, or part of a feature) up and running fairly quickly, to test some assumptions and get real feedback, and conversely start to feel antsy if I'm spending too long 'building' without anything to show for it.

I Agree. Its a tradeoff between adding tech debt and releasing but I would optimize for getting stuff in front of users while making sure we don't forget to address the tech debt