I have to agree with Brian. SQLite is not intended to replace a database, it's intended to replace a flat file. Even the documentation for SQLite emphasizes that it replaces 'fopen()', not MySQL. If you would be happy (from an admin perspective) keeping the entire data set in a single text file, then SQLite is probably a good choice (with better semantics!). If you expect to *ever* need a "real" relational database backend, then start with MySQL (alt. MariaDB) or PostgreSQL (depending on use case and preferences) and evaluate from there.
On 05/27/2015 12:05 PM, Brian Cluff wrote: > If your database is going to be fairly small it might be OK, but in my > experience sqlite ground my website to a halt once the database had a few > megs of data in it. It really didn't take much data at all to become > ridiculously slow. > > Brian Cluff > > On 05/27/2015 11:31 AM, Mark Phillips wrote: >> I am working on a small project using the django framework. I have a >> choice of backends - mysql, postgress, sqlite. The web site will have >> low traffic, and 90% of the assets are scanned images (pdf, tiff, jpeg), >> so they will be stored in a file system and not in the database. The >> framework/database are for tags and search terms (ocr from pdfs) and >> user login credentials. >> >> I am inclined to use the sqlite backend so the site uses fewer resources >> and to make backups easier. However, I have never used sqlite in a >> production environment. According to the sqlite website, it is >> production ready. >> >> Would you recommend sqlite for a production website? >> >> Thanks, >> >> Mark >> >>
signature.asc
Description: OpenPGP digital signature
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss
