Why not just use SQLite for everything? It isn't like you need to handle a hundred writes a second in whatever software you're writing.
>>53393801
For a website requiring people to POST data, such as signing up, then there will likely be concurrent write requests, which is what sqlite isn't good at.
mongoDB is love, mongoDB is life
>>53393837
Signing up will very unlikely be a problem unless you have several such events per second
>>53393801
http://howfuckedismydatabase.com/
Referential integrity
>>53393927
This is incorrect
http://howfuckedismydatabase.com/sqlite/morethanone.php
More than a hundred, perhaps. Depends on how frequent writes are.
>>53393877
https://www.youtube.com/watch?v=b2F-DItXtZs
lolno
>>53393927
I broke it
>>53393940
A hundred is still a joke though. SQLite is not for massively concurrent applications. Also a statement of "good luck with that" is not that incorrect, once you go concurrent you will bump into scaling problems.
The point, don't use SQLite for *everything*! It's not for massively concurrent stuff!
>>53393801
True that.
I use json first. If that is not good enough I move to SQLite. If that ain't enough I reevaluate my life.
>>53393976
It's not for massively concurrent stuff, but it isn't bad just because you have more than one user.
>>53394091
If you have more than one user than you typically have unspecified/variable number of users. If you can safely constrain that below 100 then good for you, otherwise "good luck".
>>53393947
Jesus, these fucking videos are awful. If they at least pasted the transcript into the description as well as baby's first video generator, maybe I'd read the whole thing.
>>53394179
you are just offended, because you use MongoDB
>>53393801
ITT: inane suggestions.
>>53393801
there are limits to sqlite queries
>>53393927
what a fucking douchbag
saying shit just to shill affiliated amazon links
go fuck yourself
>>53393801
OP, if it was good for everything the authors would call it "SQLeverything"
It's designed for light usage, so either use it properly or don't come crying when your threads lock up.
t.fizzbuzz coder
>>53396868
https://www.sqlite.org/whentouse.html
>>53397317
well there you go, just like I said.
>>53397422
If "light use" means a website with 100K hits/day, then sure
>>53396868
http://charlesleifer.com/blog/sqlite-small-fast-reliable-choose-any-three-/
sqlite is good for small apps, but when I had many processes reading and writing from sqlite, it would constantly be locked.
elastic search, nosql or mariadb are infinitely better
We attempted to use sqlite for our small website and it just exploded after a couple million records.
>>53397747
>>53397747
>ledit
>>53393927
http://howfuckedismydistro.com/gentoo/
lol
>>53393801
>a hundred writes a second
Well at work I do, that's why I'm pushing a move to PostgreSQL (for DB) — we're currently suffering a poorly designed MySQL setup. But I agree SQLite is pretty based.
>>53403077
SQLite is based for embedding in single user apps.
For client/server PostgreSQL is the only way.
>>53403103
Yeah, I know. We run a heavy Drupal site pulling from dozens of MySQL databases as well as Mongo, so I've just learned to appreciate proper database software (aka foreign key support). SQLite's embeddable nature is pretty neat.
>>53393877
mongo is for anthropology majors that decide they're "engineers" after school b/c they learned some javascript and css.
>>53393898
Very unlikely isn't a good idea. That one time out of 100 will fuck you.
>>53393801
it can do hundreds of writes? it can talk to software? that's your grand argument?
>>53393801
i work in voip and handle cdrs being generated thousands per second
and we're not even big
get out of here lmao
>>53397470
>>53397470
>>>53397422
>If "light use" means a website with 100K hits/day, then sure
Almost all of which are reads. Sqlite is fine at that. As soon as you have a site where users can cause writes....
>>53393974
thats part of the page
