SQLite is probably the best database to use if your site does not get more than 100000 hits per day, or your database size doesn't exceed about 25 GBytes.
MySQL is better when your site is getting hammered with lots of concurrent requests, and you need the extra threading and queueing to serve all of the requests properly. It simply parses the requests, figures out what to do (query plan), and calls an fopen() on the SQLite database file and executes the query. SQLite doesn't waste processing and bandwidth packing up requests between the application server process and the database server process. MySQL, is a database server that runs in its own process. SQLite is an embedded database engine, but it runs in the same process as your application. If you want to scale your web application, you'll probably have to use a server-based database such as MySQL. In SQLite, you're stuck on storing your database on a local disc (or of course, network disc, if one is available). SQLite is quite popular as an embedded database - Firefox 3 has one inside it. In short, you can't really compare them like-for-like.
Potentially rather fast for easy queries because there is less IPC, system calls and data copying to do.Very low query overhead because of this.Runs in-process with the client application.SQLite and MySQL are both fine products in the right context. Try to get your development system as close to production as you possibly can (hint: run it in a VM) Different database engines behave differently and will cause unexpected bugs to appear. If you are using a different DB in development and production, DON'T.
I'm hoping that from your question, you aren't talking about using a different database system in development and production.
0 kommentar(er)
