They released a UI to manipulate the data too

Can one have a project with a relational database that is deployed early and often, and not have thousands of SQL migration scripts? Seems like it’s difficult to have both. Maybe there’s some way to “roll up” old migration scripts into one nice SQL schema. I guess running them all on a new database and exporting the schema will do that. 🤔

Prisma provides a "baseline" to reset merge all migration scripts. There are always many migrations though.

Jon Gjengset make great tools. The idea of Noria is to compute reads in advance when update occurs. It leads to faster reads.

At a high level, Noria takes a set of parameterized SQL queries (think prepared statements), and produces a data-flow program that maintains materialized views for the output of those queries.

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.