and how to batch to optimize DELETEs

That's very interesting

A collection of resources such as guides, blog posts, advocacy, how to's

Inquiet de la perte de connaissance du métier de DBA. C'est une inquiétude qui me semble justifié.

I like the model: Subject - Predicate - Object

Such as: Xerxes - Parent - Brook.

It can be modeled as such:

parent(xerces, brooke).
parent(brooke, damocles).

Le NoSQL est également plus adaptée pour le développement agile car les données ne sont pas structurées pendant les itérations.

Le SQL a réussi à traverser les âges car: il est simple, il est rapide et il est stable.

Les avantages de SQLite:

• facilité d'administration: tout le contenu peut être visualisé par lecture d'un fichier.
• facilité de déploiement: il est possible de pousser les BDD en production et de les migrer
• simplicité: sqlite est intégré avec tous les langages de programmation
• capacité: une BDD peut contenir plus d'un million de TB

Ses désavantages:

• requêtes concurrentes:
• les types de données limitées: NULL, INTEGER, REA L, TEXT, BLOB. Il n'y a pas de BOOL ni de dates.
• les données sont faiblement validées: "abcd" dans INTEGER o 20 charactères dans VARCHAR(5) passent.
• la sauvegarde des données est à faire soit même
• l'hébergement n'est pas possible avec tous les hébergeurs

A great tool to generate an ERD. It can be generated from an SQL schema, a DB connection, JSON,

IndexedDB can be used to store a lot of data. It has some caveats though.

Storage:
About deletion, use soft delete to smoothen the synchronization if a user deletes a record and another one update it.

About record collection, use unique IDs (UUID v4) or property related ids with (UUID v5).

About ordering, it is easier to use fractional indices! Read more on https://www.figma.com/blog/realtime-editing-of-ordered-sequences/, or https://www.steveruiz.me/posts/reordering-fractional-indices, or use a dedicated library.

Sync is made with pull and push
Update:

• Send atomic changes from a client is the more convenient way. We can send only the model’s ID and its updated fields.
• send operations instead of changed data,

Conflict resolution:

• In some cases, last-write wins at the record field level will be enough
• in others, we strongly need a full-fledged CRDT.

Simple to use local JSON database. Use native JavaScript API to query. Written in TypeScript. owl

Good points! I have use cases where a frontend database approach will work perfectly!

SQLite that is not relational but using key/value pairs

• Key-value database: It is a non-relational database that stores data as a collection of key-value pairs, where the key is used as a unique identifier. KVDB has simple operations and robust scalability.
• Time Series Database: Time Series Database (TSDB) stores data in time sequence. TSDB data has a timestamp, large data storage, and high insertion and query performance.

Maybe useful someday

Much like QEMU, new trends in the industry are taking it into a completely new direction: the rise of use cases around Edge compute, due to its limited resources and limited environments means that SQLite fits the bill perfectly.

It lists some distributed data project based on SQLite. The most promising project seems to be LiteFS: https://github.com/superfly/litefs. However SQLite is not open to contribution...

That'S why the author starts a new project, open to contribution named LibSQL (https://libsql.org/). It can be merged with SQLite if they change their code of conduct. They want to add async interfaces for example, or WASM support.

About schema; tables; collections; keys and columns; unique, primary and foreign keys