Storage

As someone that spends a little time on each level of the stack, I find that the database portion is fun and challenging. It find it to be the easiest to write, but the hardest to do. One mistake and I find myself in a world of hurt.

SQL

I've had more experience in the SQL realm than the NoSQL realm of development. Most of the applications I've built in SQL have been using MSSQL accompanied with SSMS or Azure Data Studio. I've found Microsoft's docs to be extremely helpful in this regard, and has made learning and reviewing different commands a breeze.

I've spent most of my time using Entity Framework. I started using the DB-First approach then spent more time with the Code-First approach. As someone who spends most of their time outside of the realm of databases, I've found the Code-First approach to be more natural, but I can see why the DB-First approach would be preferable from a DBA's perspective. I've found that the overhead of learning LINQ has paid dividends in helping me work through features without having to leave the application project. Even though I prefer using EF for doing all the CRUD to the DB, I've found updating the database schema to be easier using sql migrations. Writing Sql also seems to have advantages in certain areas where I want more control over what is run on the db, or on occasions where the rest of the team doesn't want to jump over the hurdle to use EF.

NoSQL

When I'm outside of the .Net realm I often find it simple to use Express with a NoSql database such as Mongo. I've looked into using other databases, but I haven't moved very far outside of the Document-oriented databases. I've been tempted to play around with Neo4j, since I've enjoyed working with GraphQL and like the idea of using Edges to show relationships between documents.