Saying that a program that opens and reads/writes a file through a file format API is a light RDBMS turns almost every program in history into an RDBMS.
If SQLite didn't force you to use SQL as the read/write logic, absolutely nobody would confuse it for an RDBMS. That's because it's a file format.
I think your comment would be more comprehensible if you gave some examples of the kind of functionality you think is missing.
I don't know what you mean by "RDBMS", but JSON and XML don't do joins, don't do views, don't do efficient query plans, and so on. It's either ignorance or obstinacy to say SQLite is just a file format.
Sure they do. If you write the logic to do so, and put it behind a nice API, you can make all of this come true. In fact, millions of people every day do joins with JSON and XML in their code every day. You can probably just use Apache Drill as the "library" in this sense to facilitate joins and whatnot. The creators of the SQLite library simply build that stuff into their library for you.
SQLite is a file format. It has a nice library full of wonderful utility functions for reading/writing that file format and a simple to use API that is operated by sending SQL to it.
It is exactly the same as reading and writing any other file format with any other API and library. The more you understand SQLite as a file format with a nice reference API implementation, the more it makes sense.
It is not the same as using an RDBMS and offers almost none of the things and RDBMS might offer. The more you try to figure out how it's not like PostgreSQL or Oracle or MongoDB, the more confused you'll make yourself.
It's no more an RDBMS than a .docx file is.
> It's no more an RDBMS than a .docx file is.
Thanks for the idea. Your argument is like saying this:
Microsoft Word is not a word processor -- it's a file format.
I mean, yes, Word has a file format; but it's far more than just a format specification.
> Sure they do. If you write the logic to do so,
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?
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/
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.
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.
> 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."
According to their home page the SQLite database file format is a file format, and SQLite is a library.
You could write your own code tomorrow that reads/writes SQLite files but does not produce, read, or write WAL or Journal files. So long as the resultant SQLite file follows the specification, it can be read by any other piece of software that implements the specification, such as the SQLite library or SQLJet (https://sqljet.com/).