6 ms·

At this point, why are we still using JSON/XML when there is SQLite for new projects? Stop the non sense of JSON/XML. SQLite is like json, but very queryable.

At this point, why are we still using JSON/XML when there is SQLite for new projects? Stop the non sense of JSON/XML. SQLite is like json, but very queryable. Just send SQLite files around. MongoDB also saves document db type of store space just FYI.

constantly 3y ago
Any text editor in the world, even the ones that ship with the most barebones shells, can open json and xml and present their data to the user. SQLite files require opening in a DB terminal or using special software to even get to the point where one can see what’s there at all. Further the entire internet basically natively supports XML and JSON.
- vmfunction 3y ago
  That is a good argument, however many people like some big game development company start to ship with GB of json file, at that point just use SQLite. It will be faster to query load. Also if you look at how DB such as Mongo (Not promoting them in any way), but when Maildir is used aginst Mongo for file storage, Mongo saves a lot of disk space. Again, it is about how we want to store files? NixOS is a quite a way to think about having a file system or db/store.
- eviks 3y ago
  Outside of simple cases xml is too verbose and ugly (and in these cases usually zipped), so it's not suitable for a poor human with a plain text editor, so that doesn't give you much of a leg. (Json has a higher threshold of complexity before it succumbs)
deleted 3y ago
[deleted]
quickthrower2 3y ago
With JSON/XML the app owner decides the schema of the saved file, as they should. One day Sqlite will do some perfectly fine change that’ll break people who outsource their file format to it. Own your file format! That said there is some nuance and it depends what the user expects. Is you app more of an MSWord where people expect a format that is decades backward compatible and only changes on explicit save, or is it more like a live app with a db back end. If the latter there should be no save concept around the DB file but perhaps a backup and restore function that exports to a controlled format.
- eastern 3y ago
  In sqlite the on-disk file format does not matter. All that matters is that you should be able to issue sql to the sqlite embedded library and get back the results. Freeing you from the overhead of owning (thus inventing and then maintaining) your own file format is almost the entire point of using sqlite in this manner.
  - quickthrower2 3y ago
    It matters for 2 reasons. One, the expectation that the file changes only when you click Save is broken (as mentioned in another comment), and Two, unless you pin the version of sqlite forever then the file format may have braking changes or your need to deal with migrations.
    - eastern 3y ago
      > expectation that the file changes only when you click Save is broken This has nothing to do with sqlite. You can have (or not have) gradual saves in any file format. It's a choice that the developers of that app made. > file format may have braking changes The sqlite file format is unchanged for 19 years now. A world of features and capabilities have been added since. Don't hold your breath waiting for the sqlite format to change.
      - quickthrower2 3y ago
        This is not gradual saves. File changes when nothing has saved even, according to that comment. Fair enough about the history of it not changing and you can always embed a frozen copy if it does. But this is a pragmatic assumption not a guarantee.
- OliverJones 3y ago
  XML and JSON are for serialization. zip and sqlite, and file-system files, are for lossless persistence. They're separate issues. An app can go bananas with serialization and use, I dunno, binary JSON or Matroska / ebml or .mp4 containers or whatever, and still serialize any way it wants.

constantly 3y ago

Any text editor in the world, even the ones that ship with the most barebones shells, can open json and xml and present their data to the user. SQLite files require opening in a DB terminal or using special software to even get to the point where one can see what’s there at all. Further the entire internet basically natively supports XML and JSON.

vmfunction 3y ago
That is a good argument, however many people like some big game development company start to ship with GB of json file, at that point just use SQLite. It will be faster to query load. Also if you look at how DB such as Mongo (Not promoting them in any way), but when Maildir is used aginst Mongo for file storage, Mongo saves a lot of disk space. Again, it is about how we want to store files? NixOS is a quite a way to think about having a file system or db/store.
eviks 3y ago
Outside of simple cases xml is too verbose and ugly (and in these cases usually zipped), so it's not suitable for a poor human with a plain text editor, so that doesn't give you much of a leg. (Json has a higher threshold of complexity before it succumbs)

deleted 3y ago

[deleted]

quickthrower2 3y ago

With JSON/XML the app owner decides the schema of the saved file, as they should. One day Sqlite will do some perfectly fine change that’ll break people who outsource their file format to it. Own your file format! That said there is some nuance and it depends what the user expects. Is you app more of an MSWord where people expect a format that is decades backward compatible and only changes on explicit save, or is it more like a live app with a db back end. If the latter there should be no save concept around the DB file but perhaps a backup and restore function that exports to a controlled format.

eastern 3y ago
In sqlite the on-disk file format does not matter. All that matters is that you should be able to issue sql to the sqlite embedded library and get back the results. Freeing you from the overhead of owning (thus inventing and then maintaining) your own file format is almost the entire point of using sqlite in this manner.
- quickthrower2 3y ago
  It matters for 2 reasons. One, the expectation that the file changes only when you click Save is broken (as mentioned in another comment), and Two, unless you pin the version of sqlite forever then the file format may have braking changes or your need to deal with migrations.
  - eastern 3y ago
    > expectation that the file changes only when you click Save is broken This has nothing to do with sqlite. You can have (or not have) gradual saves in any file format. It's a choice that the developers of that app made. > file format may have braking changes The sqlite file format is unchanged for 19 years now. A world of features and capabilities have been added since. Don't hold your breath waiting for the sqlite format to change.
    - quickthrower2 3y ago
      This is not gradual saves. File changes when nothing has saved even, according to that comment. Fair enough about the history of it not changing and you can always embed a frozen copy if it does. But this is a pragmatic assumption not a guarantee.
OliverJones 3y ago
XML and JSON are for serialization. zip and sqlite, and file-system files, are for lossless persistence. They're separate issues. An app can go bananas with serialization and use, I dunno, binary JSON or Matroska / ebml or .mp4 containers or whatever, and still serialize any way it wants.