Thread 107161667

Let me guess, you need more?

We don't, but I'd probably be fired for suggesting it.

>>107161667 (OP)
Nope, sometimes I even need less.

>>107161832
True. XML, flat files, serializing classes, csv, etc. the possibilities are there. Relational databases are great for enterprise applications because you need to track large amounts of data (appointments, tools, whatever) and link these to various users, but here a remote database tends to be better. For something like a file editor, a video game, or even an encyclopedia where the relations are borderline irrelevant SQLite is the wrong tool for the job.

There are certainly use cases for sqlite though. I think it is a great way to teach newbies about relational databases, or for test data. Or if you have a large complex filing system you could use the sqlite to store references and make navigating this way easier.

>>107161667 (OP)
Great read times. Only problem is read and write concurrency since it can't multi write. From an application perspective if you had high write load and are using SQLite your best choice is to create a writer routine where everything that needs to be written is put into a queue and then written all at once. But if your read write demand is this high in the first place you're better off with a different database engine.

It has it's use cases and is pretty nifty.

>>107161667 (OP)
why is it that the only people who use sqlite are python people? I don't remember seeing web devs (js/ts) using it but postgresql

>>107161667 (OP)
it has many good use cases, but does not solve every problem (like it says in its fucking documentation) and it's not meant to

also, it's portable - and every good software is portable

personally, I love it and am using it in my projects instead of hundreds of yaml/json/xml files

>>107161667 (OP)
Great functionality, just needs some official(ish) python wrapper to dumb it down for people (like me) who hate dicking around with sql and "pickling".

>>107162303
>Great read times. Only problem is read and write concurrency since it can't multi write.
Can I ask why this is the case? I've heard that before, but I don't get it. Is it trying to write back to the file every time time? I think most web apps are tracking every fucking user detail and every click, but if you were doing something like a multi tenant app where every user had their own sqlite file wouldn't that be fine?

>>107162406
>why is it that the only people who use sqlite are python people? I don't remember seeing web devs (js/ts) using it but postgresql
I think thats a factor of infastructure actually. Everyone now days keeps their web server seperate from their database server. That and cloud services like RDS are simpler to spin up. You just change your db connection string to some random amazon or google cloud thing and you're good to go. I think a lot of people could just do 1 big server with everything and be fine desu. I think if you're a python dev with a giant sqlite database you're probably doing some data analyst or science or math thing with a small team, not some giant 1984 tracking web app. But who knows!

>>107161667 (OP)
Let me guess, you're unemployed and don't understand the use cases for SQLite and think it's the bomb because it works well for your toddler project local to your machine

>>107163116
concurrent write (on the same machine) is no longer an issue since it's now buffered in a write-ahead log

>>107163177
not him but I am currently undecided what to use for my little hobby project, am building an application tracker, not many people will use, from what I have read sqlite is nice for small projects but I am just a beginner and not that deep into databases. and I have read if more people use it it would be easy to transfer to postgresql later

>>107163224
it will be very easy to migrate to postgresql or mysql, go for it. just remember to read https://www.sqlite.org/quirks.html
also it's much easier to start with because you don't need to handle a server (even if it would be just a docker container)

>>107163208
>concurrent write (on the same machine) is no longer an issue since it's now buffered in a write-ahead log
Wow interesting thanks. Okay ya I agree with OP 90% of sites could probably do a single server with sqlite. Most of the tracking junk is third party anyway.

echo key=value >> database
simple as

>>107163256
that's great, I think it will stay on sqlite for a long time since the only people who are going to use it will be friends from uni, but you never know. thanks

>>107163292
geg

>>107163292
haha 25GB file go brrr
sqlite3 database.db < co_block_OUT.sql

>>107165135
i was surprised when i found out that there is no way to do something like prepared statements from command line, something like echo -e lorem\x00ipsum|sqlite3 file.db 'insert into table (a,b) values (?,?)'

>>107161667 (OP)
most use cases are solved by sqlite. The only time I wouldn't use it are if I am expecting insanely fast scaling (never I am a bum) or the problem I am working on is already very high traffic. Then I probably would use postgres + redis. I don't there are many cases which wouldnt be covered by either one of those.