* Hendursaga <hendurs...@aol.com> [2022-10-08 03:46]: > Jean Louis <bugs@gnu.support> writes: > > > Of course it is so much better option than keeping stuff in text. All > > properties shall be in the database. SQLite is not a network database, thus > > it disables collaboration. It is better developing with PostgresSQL or > > MariaDB, or other network databases. > > Vanilla SQLite, that is. There are multiple[1] SQLite[2] addons[3] around[4] > that add some sort of distributed layer to it, most being zero-cost (or at > least low-cost) abstractions. Pretty cool, I'd say! > > ~ Hendursaga > > [1] https://dqlite.io/ > [2] https://litestream.io/ > [3] https://github.com/losfair/mvsqlite > [4] https://github.com/rqlite/rqlite
Thanks, insightful, I have reviewed links. But none tells me that it is truly network based database. Of course one may replicate files through network and send data, that is not what is meant with network database. One can make layers on top of it, but that does not make it multi user or suitable for collaboration. From: https://www.sqlite.org/whentouse.html ,---- | Many concurrent writers? → choose client/server | | If many threads and/or processes need to write the database at the | same instant (and they cannot queue up and take turns) then it is best | to select a database engine that supports that capability, which | always means a client/server database engine. | | SQLite only supports one writer at a time per database file. But in | most cases, a write transaction only takes milliseconds and so | multiple writers can simply take turns. SQLite will handle more write | concurrency than many people suspect. Nevertheless, client/server | database systems, because they have a long-running server process at | hand to coordinate access, can usually handle far more write | concurrency than SQLite ever will. `---- -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
