81–90 of 127 posts
> It's used in systems as important as the Airbus A350 so it comes as no surprise the tests for SQLite 3 are aviation-grade I stumbled upon SQLite around 2001 and have been using and admiring this gem of a software since that time, but hearing that it is aviation-grade is definitely a surprise to me...
Very nice! I'm in the middle of writing a book based on SQLite (the overall topic is data analysis with SQL, but SQLite is the medium) while I'm teaching it to students. I used to teach MySQL but it was just so goddamned hard to get it configured correctly on people's computers (I always hated when work had to be done on pre-configured computers lab rather than my own laptop), nevermind the server/client/daemon aspec…
Have you tried sqlitebrowser? It's fantastic, I use it a lot. http://sqlitebrowser.org
The DB Browser (they changed it from sqlitebrowser at the request of sqlite IIRC) also has in my experience, a very helpful and responsive dev team: https://github.com/sqlitebrowser/sqlitebrowser/issues
Earlier quoted context omitted.
Sqlite is great but it is a poor substitute for a "real" database where you need any serious constraint enforcement at the database level. Yes, you can enable RI, but it's off by default. There is no field length constraint on text values, no native datetime, boolean, or guid types. You can't structurally alter tables without building a new one and copying the old. If you actually need any of these things you can enf…
> Sqlite is great but it is a poor substitute for a "real" database This is true, and explicitly acknowledged by the author: > SQLite does not compete with client/server databases. SQLite competes with fopen(). https://sqlite.org/whentouse.html If you're deciding between Postgres and SQLite, in most cases you're doing it wrong (there are a few exceptions, such as serving a low-traffic almost-entirely-read dynamic web…
Think about requirements first, then tech/implementation approach.
But yeah, like everyone else, I often just start with SQLite anyway!
I love SQLite (and use it in a large number of places in our application stack!), but I feel that it suffers from a case of bad defaults. To name a few: - Foreign key checking (and cascading deletion for that matter) are turned off by default. You need to enable them using `PRAGMA foreign_keys = ON;`. - There are practically no downsides (and a number of upsides) to using the WAL journalling mode (at least for "use a…
Very nice! I'm in the middle of writing a book based on SQLite (the overall topic is data analysis with SQL, but SQLite is the medium) while I'm teaching it to students. I used to teach MySQL but it was just so goddamned hard to get it configured correctly on people's computers (I always hated when work had to be done on pre-configured computers lab rather than my own laptop), nevermind the server/client/daemon aspec…
I'm of course not suggesting you switch back to MySQL, but distributing preconfigured MySQL docker images perhaps might've helped with your configuration troubles.
So you are advocating people who have issues with simple apt-get or yum install mysql or to instead install docker and deal with the complexity of docker, before they can use the app?
Earlier quoted context omitted.
> I mean Postgres is a fine piece of software but if your website gets 500 visits a day, you don't need Postgres; just use SQLite. On the flip side, setting up a PostgreSQL instance is so easy now with docker that you could go ahead and use it with a fraction of the admin overhead that it used to require: https://hub.docker.com/_/postgres/
Docker is its own nightmare :/ I just find it weird and confusing. Also, how do you setup a database in docker? Docker does not support persisting data as far as I know. So if you need to restart the thing, all the data will be wiped. At least that's how it seems to be.
Earlier quoted context omitted.
> I mean Postgres is a fine piece of software but if your website gets 500 visits a day, you don't need Postgres; just use SQLite. On the flip side, setting up a PostgreSQL instance is so easy now with docker that you could go ahead and use it with a fraction of the admin overhead that it used to require: https://hub.docker.com/_/postgres/
The running docker image will still need many more resources than opening up a SQLite dB and running a few queries.
Earlier quoted context omitted.
Sure you can do that, but if your app needs to use other services (Redis, for example) you can easily throw that in the compose file as well, and then it's easy to maintain versions and have every developer be on the same page. This is especially helpful if some developers use OS X or Windows. I don't understand the "all of that" phrasing, as if what I just described was a large amount of work.
How many people run webwpps with changing version requirements for their _database_? Docker is useful for running components of your own code or for isolation, not for managing versions of core applications like a database or a mail server for most people deploying ready-made apps.
I've tried several different dev environment setups and this approach yields the fewest frustrations and inconsistencies.
Production is a different story but that's not what I'm discussing here.
Sqlite is great as data store for storing JSON. We receive realtime data from different sources in JSON format. I dump the raw data into MongoDB, but it's still not very easy to query. This is where Sqlite comes in handy. I import the data straight into Sqlite from MongoDB which then enables me to run SQL queries using the JSON1 extension. Currently I'm using it to store data that drive feed simulators. We can extrac…