What are the differences between embedded and built-in databases?

Question

I have studied embedded and built-in databases, but I don't understand the difference between the two.

Which of these databases does Mysql belongs to?

Answer 1

It's not really clear what you're looking for, so context would be helpful. Because I'm not sure what you're really looking for, I'll try to explain through applications.

Sqlite is an example of a common and popular embedded database. It exists in a single file, it is lightweight, and thus it plays nice in applications that need a persistent datastore without a lot of overhead. Sqlite doesn't require a server or a background process to run. So, you can think of an embedded database as a database that exists within an application's file structure. In iOS, Core Data serves the same function. For the sake of simplicity, the database exists within the app, there's no real "client-server relationship."

MySQL is a full-fledged database solution, and it runs independently of your program. When your program needs to access the database, it connects to the external process (the server, which can be the local machine), makes its requests, and processes the responses. With MySQL, it's helpful to think of the client-server model, with your program being the client, and the database engine being the server (even if they're running on the same system).

If you're making a web app, you'll probably need a database, and MySQL is a sensible choice. You install MySQL on the server, and your web app routes data requests to the server, which then provides the requested data.

If you're making a mobile app, and it needs a persistent datastore, then an embedded database might well make sense. Core Data in iOS is a decent candidate.

If you're making a desktop application, and you want a database to back it, then Sqlite is a pretty decent option. You add the database during your application's install routine, and then access it on-demand. If you need something more robust, then you might use MySQL locally instead. Or you might use a central database server, and have your app use a web service to get the data.