I have a C # application that uses a MySQL database with Entity Framework. However, the size of the database is ridiculously small, so I do not think it's worth having a MySQL database server just to run this application.
What approach would the database be built into the application, so that it could be run without being connected to any server?
And how would I transport the data from the database to this new solution?
What approach would the database be built into the application, so that it could be run without being connected to any server?
A good approach is SQL Server LocalDb . It is identical to SQL Server Express and uses the identical Entity Framework settings in the same way.
ASP.NET MVC5 projects are typically created with LocalDb being used by default.
And how would I transport the data from the database to this new solution?
Using SQL Server Management Studio .
Use the migration wizard .
The solution is usually to use SQLite. It is a built-in database and usually meets most applications needs, especially if there is no direct access coming from different machines. Note that indirect access works fine without problems, which is normal for web applications or that have an application server (middleware) or something like that.)
It handles large volumes of data and accesses very well. It would only be a problem if you have a very large number of long, effectively simultaneous writings.
There is an official driver for Entity Framework available.
See when using SQLite .
Obviously there are other possible solutions if you do not want an embedded database, as shown in other answers. There will be a connection to a server, even if it is not remote.
The transport of data takes place in a traditional way. Either use a client software, possibly a GUI, just like any other database, and have a lot of choice, or do it programmatically, in this case of course it would have to make a connection with the unincorporated database to read the data that will be written in the SQLite, or would have to connect to a service of yours that provides the data (connecting on the server).
There are MySQL installation options directly on Android, making it a Server. One good option would be to migrate your database to MariaDB (OpenSource version of MySQL) and use the: link
The fact is whether you really need to persist / save this data. If so, it will have to be somewhere. That part is taken yesterday to decide on persistence.
Often, using a simple database like MySQL is more advantageous - like simple and quick implementation - than trying a more "creative" solution.
So the question is: do you need to persist data?
If so, what advantage do you see in not having a database? What problem will you solve by not having a persistence service like a MySQL?
If not, you can go to an In Memory solution, such as instantiating a System.Data.DataSet , in it to create all the tables and relationships your application needs. Then make a first seed of data for your application to start working. This is an option where, if your application is recycled, all data will be cleaned and will start from scratch.
Important also to consider that your application already exists and is already working with a database. Is it worth removing it? Is ROI - return on investment - interesting? Because removing a database, already implemented with EF, will cost a few hours of the developer to adapt.
