Practical approach to integration testing of the .NET + NoSQL bundle. Key features, examples and comparisons of RavenDB with other NoSQL engines.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Multi-tenancy is never simple and can be addressed at different levels. Arguably, the most interesting solution would be where the app and the database both support multiple tenants. Here I bring this solution to the YABT project.

Designing 'one-to-many' and 'many-to-many' relationships to reduce read operations on querying the data.
Let's take Users, Backlog Items and Comments entities from the YABT and consider their relationships from various angles, taking into account performance, operational costs, time/costs of development and maintenance.

Marrying the flexibility of NoSQL entities for storing various sets of fields with strongly-typed .NET languages and powerful RavenDB indexing tools. Store custom fields, manage their C# structures and filter/search on them in the queries.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Strategies for document identifiers in RavenDB (and NoSQL in general). Pros and cons of GUIDs, auto-incremented numbers, use of prefixes, ID masking and more.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Practical modelling of a NoSQL database using the DDD (Domain Driven Design) practices to define the problem area (Bounded context) of the project, its domain entities and aggregates. Comparison to designing a relational model for a traditional SQL.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

NoSQL is not hard, it’s different. And to show that, RavenDB and I kick off a new series of articles dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

When it comes to choosing a platform for a new application there is a lot to consider at different levels. For the CTO or Architect the focus is on providing the required scale, resiliency, maintainability, elasticity. And all of it within a certain price range. For the developers, the preference goes to elegant solutions, well integrated with the preferred technology stack and with smooth (pain-free) development experience.

Following up on my "7 reasons not to NoSQL", here are my two reasons to go with NoSQL in enterprise projects - Cheaper to scale and Convenience of development.

Have you seen people affiliated with NoSQL databases aggressively advertising them as a solution for everything? And early adopters swearing allegiance to the NoSQL and claiming to pass the point of no return to SQL? Unsurprisingly, one may think of NoSQL as the silver bullet which solves all the problems. Should we always use NoSQL?

Having actively used RavenDB for a couple of years, I constantly get asked by other devs about feedback on the database. They usually expect to hear something simple and straightforward, like "love it" or maybe even "hate it", but my experience doesn't fall into any of these extremes. After 2 years I'm torn apart by polarised feelings about the database, and my expected-to-be-simple response turns into a long story about all the pros and cons, love and hatred. So here is my story.