181–190 of 274 posts
Earlier quoted context omitted.
> So, we would have databases like Users.db, UserSessions.db, Settings.db, etc. How do you do joins?
Not the OP, but you can attach and join tables from multiple sqlite databases in the same process.
Earlier quoted context omitted.
If a customer has 1000 employees all using your app, it is.
If the app is designed correctly, then the thousand employees would write to their own temporary databases, and a background job would pull their changes into the main database sequentially. If the app is not specifically designed to do this, then SQLite would not be an option.
Earlier quoted context omitted.
> I believe you mean that you can't easily do a "psql ..." or connect using DataGrid and similars, right? Yeah. > Does this mean that devs need to copy the production database file locally to then inspect it? Or are there tools to connect/bridge to a remote sqlite file? We use "kubectl copy" currently when we want to inspect it, and we haven't actually had to write back to a production file yet. We've explored the "r…
Ah I see! Yeah, I expected your team would have to copy it locally. I wonder tho, in times of data leaks and whatnot, couldn’t it be dangerous to have lots of PII (personal identifiable information) copied around many dev laptops? I mean, devs can do the same with Postgres, but it is more for backups instead of purely querying.
Earlier quoted context omitted.
Not the OP, but you can attach and join tables from multiple sqlite databases in the same process.
Really??? How? Because I use sqlite, and the query functions that I know take a single DB as an argument.
Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to e…
SQLite hides a ton of complexity that lives in the filesystem. It’s incredibly hard to do robust IO correctly with the APIs we have. I almost always choose SQLite for persisting to disk over JSON files. It essentially removes a large class of bugs and is robust enough that I’m not worried about introducing new problems.
Earlier quoted context omitted.
SQLite hides a ton of complexity that lives in the filesystem. It’s incredibly hard to do robust IO correctly with the APIs we have. I almost always choose SQLite for persisting to disk over JSON files. It essentially removes a large class of bugs and is robust enough that I’m not worried about introducing new problems.
In addition to hiding a ton of complexity, SQLite is actually faster than the filesystem in a surprising range of cases.
Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to e…
Your solution works to a point, but it will not be as robust as SQLite. Its ACID powers are incredibly valuable in the real world where things fail or are unreliable. Also the ability to do complicated queries comes in handy sooner than you would think. Of course you have to then mess around with SQL but you only have to write it once and encapsulate it somewhere and you're done.
I believe SQLite is about to explode in usage into areas it’s not been used before. SQL.js[0] and the incredible “Absurd SQL”[1] are making it possible to build PWAs and hybrid mobile apps with a local SQL db. Absurd SQL uses IndexedDB as a block store fs for SQLite so you don’t have to load the whole db into memory and get atomic writes. Also I recently discovered the Session Extension[2] which would potentially ena…
You can run it on AWS Lambda and store the SQLite file(s) on EBS [1]. [1] https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aw...
Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to e…
If you care about data normalization and data integrity then SQLite is going to be a much better choice.