3 ms·
> First of all, you still haven't answered the question: What is it that an RDBMS has that SQLite doesn't have? And RDBMS is a well defined thing and is litera
by bane 7y ago
> First of all, you still haven't answered the question: What is it that an RDBMS has that SQLite doesn't have?
And RDBMS is a well defined thing and is literally what the acronym expands to mean. This is very old technology with an interesting history and I really implore you and anybody reading this to go read up on it. It's not just whatever we assume it to be or some kind of data bucket with SQL.
> Microsoft Word is not a word processor -- it's a file format.
No, don't be obtuse. I'm saying that .docx is a file format.
Word is both an application for editing documents and contains a reference implementation for reading/writing .docx formatted files. There are many libraries that can read .docx files and some of them are also part of document editing software.
> Right, but you don't have to write the logic if you're using SQLite. That's the point. SQLite is a library, which provides a way to do SQL operations on data. Like Word, SQLite has a file format, but it is far more.
I just don't get where you're coming from. Do you not know that the SQLite libray can actually do complex SQL queries on data? Or do you think that people shouldn't do that for some reason? Or do you just value SQL queries so little that you don't see any difference between being able to do complex queries and doing `file.Write(json.Marshal(data))`? What is it you're trying to accomplish with this line of argument?
Precision of thought. People don't go around calling fish oceans, or forks restaurants. The SQLite library does what you've described to SQLite files. But you don't need the SQLite library to work on SQLite files. You don't need even need SQL. e.g. https://sqljet.com/ https://sqljet.com/
Just because a library offers SQL as a convenient tool to read/write data into its file format everybody loses their minds and starts to think the library is some kind feature reduced Oracle cluster. Go back to my first post. People are approach what SQLite is from the wrong direction (RDBMS) and its confusing the fuck out of everybody who gets near it.
This is important. IT departments and governments make very large, very expensive decisions based on if people know that SQLite is closer to CSV files than to Oracle databases.
I literally sat in a meeting last week where a senior decision-maker at a client wouldn't accept delivery of some software because it used SQLite and didn't want to add maintenance of yet another database to their overworked DBA staff and didn't want to hire a dedicated person to manage it. So now, instead of just taking delivery of the software, some of it has to be rewritten to use the client's RDBMS system, which in turn actually will add workload to the overworked DBA staff and will also perform worse.
SQLite IS A FILE FORMAT with a really nice library for reading/writing to that format.
- goto11 7y ago> SQLite IS A FILE FORMAT with a really nice library for reading/writing to that format. You keep repeating that, but it is just not the case. SqlLite is the name of the library, not the file format. Just see the definition on Wikipedia: > SQLite is a relational database management system (RDBMS) contained in a C library. In contrast to many other database management systems, SQLite is not a client–server database engine. Rather, it is embedded into the end program. It is really that simple.
- gwd 7y ago> > Microsoft Word is not a word processor -- it's a file format. > No, don't be obtuse. I'm saying that .docx is a file format. I'm afraid I'm not the one being obtuse. That statement is a mirror; please have a look. > Precision of thought. Which is why "SQLite is only a file format" is a false statement, and you shouldn't be making it. > But you don't need the SQLite library to work on SQLite files. You don't need even need SQL. That's like saying btrfs isn't a filesystem, because grub knows how to read it. The core functionality of SQLite is the query system. The fact that it's got a well-defined file specification which other projects can read is one of its features, not the sum of everything that SQLite is. > I literally sat in a meeting last week where a senior decision-maker at a client wouldn't accept delivery of some software because it used SQLite and didn't want to add maintenance of yet another database to their overworked DBA staff and didn't want to hire a dedicated person to manage it. So now, instead of just taking delivery of the software, some of it has to be rewritten to use the client's RDBMS system, which in turn actually will add workload to the overworked DBA staff and will also perform worse. Finally, something remotely concrete, rather than a repetition of the same false statement. So the problem you're trying to solve is that people see "SQL" and think "Oracle": A massive installation which requires separate resources, both in terms of servers and manpower to maintain it. I can see why you want to try to correct that false belief. But your solution seems to be to introduce another false belief. Imagine you're successful in getting people to accept that "SQLite is just a file format". Five years from now, someone else will be posting this to HN: "I literally sat it a meeting last week where a senior decision-maker at a client wouldn't accept delivery of some software because it used SQLite, and he said SQLite is just a file format like JSON; and they need advanced SQL querying, safe transactions, and safe access by multiple accounts. So now, instead of taking the delivery of the software, some of it has to be rewritten to use the client's RDBMS system." You're not going to fix one misconception by introducing another. One better thing to say would be the truth: "SQLite allows us to embeds database functionality into your application, so there's no need for a separate stand-alone database." Or, in fact, to do what this article does, and try to hijack current hype around "serverless": "SQLite is a serverless database -- you don't need to install and maintain a new RDBMS; it's embedded inside the application itself. No additional maintenance necessary."