Before we can start to make creation, update, or delete requests, we need a data backing store. This can be a database, or set of files, or something else. Whatever we decide on, we'll need it before we can create any of the operations which affect the actual data store.
This feature is set aside for looking into and learning more about different data storage technologies - with a preference for document-based databases or flat files.
The rationale for leaning towards Document-based databases is for ease of data input (most document DBs have a CLI which can be used to bulk insert data - which can be scripted), but also because it would be good to learn about non-traditional SQL databases.
One of the goals of this spike is to build up a list of data storage technologies and decide on one to leverage. There is no hard requirement on using a traditional SQL database, but it would be good to learn a little more about the other technologies available. If a traditional SQL based approach works better then let's use that, but let's also be pragmatic and think about which technology suits the problem domain "best" (for a given value of "best").
High-Level Proposed Solution
Investigate the following technologies and their suitability for the project:
MongoDb
Marten
RavenDB
The following SQL based technologies are also potentially applicable (if they fit the domain):
Sqlite
This requires no external applications to get running (i.e. SQL Server is not required)
However, certain migration actions are not supported via Entity Framework
SQL Server
There is a docker container for this, which isn't that non-trivial to set up
Places a hard requirement on docker being installed for local development
A real SQL Server instance (for deployment) could prove costly for an open-source application
Considerations
As this project is being developed on a Linux based distro, CosmosDb has been removed from consideration. This is because:
The official documentation (as of the time of creating this feature request) says that in order to use CosmosDb locally on a Linux machine (via the emulator), contributors would need to run a Windows VM
This would require little too much effort (and potential cost) in setting up the repo on a new machine
The easier we can make this for new developers, the better
It also ties this project to Windows (for local development)
Requirements
Take the above list of data storage technologies
Look at each investigating their strengths and weaknesses
Decide which one(s) is/are most applicable to the problem domain
If a SQL based technology is required, start drafting an entity-relationship diagram
If a SQL based technology is not required, start looking into how to implement them within a .NET application running ASP .NET Core
Description
Before we can start to make creation, update, or delete requests, we need a data backing store. This can be a database, or set of files, or something else. Whatever we decide on, we'll need it before we can create any of the operations which affect the actual data store.
This feature is set aside for looking into and learning more about different data storage technologies - with a preference for document-based databases or flat files.
The rationale for leaning towards Document-based databases is for ease of data input (most document DBs have a CLI which can be used to bulk insert data - which can be scripted), but also because it would be good to learn about non-traditional SQL databases.
One of the goals of this spike is to build up a list of data storage technologies and decide on one to leverage. There is no hard requirement on using a traditional SQL database, but it would be good to learn a little more about the other technologies available. If a traditional SQL based approach works better then let's use that, but let's also be pragmatic and think about which technology suits the problem domain "best" (for a given value of "best").
High-Level Proposed Solution
Considerations
As this project is being developed on a Linux based distro, CosmosDb has been removed from consideration. This is because:
Requirements