Antichesse (o ^ω^ o)
Je cite :
Les bases de données relationnelles sont plus adaptées à des requêtes de type "trouver toutes les entités de type X" grâce aux structures internes des tables. Cela est d'autant plus vrai lorsqu'il s'agit de réaliser des opérations d’agrégation sur toutes les lignes d'une table.
L'exemple que donne la Wikipédia est très bien puisqu'il part d'un modèle relationnel maîtrisé pour représenter la même chose sous la forme d'un graphe.
Je viens de tomber sur ce site. La partie NoSQL est tellement vraie !
Certains le savent, j'ai beaucoup de mal avec les bases relationnelles ; encore plus lorsque je code un service REST. Mais les bases dénormalisées ne constituent pas non plus une solution à mes yeux dans le sens où elles augmentent l'espace occupé et rendent difficile les opérations d'update (les données y étant redondantes).
Je pense que GraphQL est un bon compromis entre le monde relationnel et dénormalisé.
@Chlouchloutte @Lenny et @Doudou qu'en pensez-vous ?
Dessiner le schéma de sa base de données et générer le SQL qui va bien à partir de ce schéma.
Voici la liste des outils que j'ai trouvé et qui soient "gratuits" (le premier est sympa) :
N.B : je n'ai pas lu les conditions d'utilisation !
Un bon article expliquant ce qu'est le big data et les différents types de base de données à utiliser en fonction des problématiques.
Une autre documentation sur les bonnes pratiques de versioning de base de données.
Une liste de bonnes pratiques sur le versioning de base de données.
Un résumé expliquant comment utiliser facilement H2BD (création d'une connexion, ajout de la base en dépendance Maven, création d'un pool de connexion, connectivité avec Hibernate & JPA, URL à utiliser, etc.
Voici quelques exemples :
Cas pour rendre les données persistantes sur le disque :
# Pour stocker les données de la base dans le répertoire TEST de votre home
jdbc:h2:~/TEST
# Pour stocker les données de la base dans le répertoire /data/TEST
jdbc:h2:/data/TEST
URL pour l'écriture en mémoire (données non persistantes) :
# Permet d'avoir plusieurs connexion pour une même instance (processus) :
jdbc:h2:mem:test
# Permet de n'avoir qu'une seule connexion (schéma anonyme et privé) :
jdbc:h2:mem:Changer le dialect SQL de H2DB pour employer celui d'une autre base :
La liste des modes de compatibilité est disponible ici
# Pour Apache Derby
jdbc:h2:mem:MON_SCHEMA;MODE=Derby
# Pour DB2
jdbc:h2:mem:MON_SCHEMA;MODE=DB2
# Pour MySQL
jdbc:h2:mem:MON_SCHEMA;MODE=MySQL;IGNORECASE=TRUE
# Pour Oracle
jdbc:h2:mem:MON_SCHEMA;MODE=Oracle
# Pour PostgreSQL
jdbc:h2:mem:MON_SCHEMA;MODE=PostgreSQLExécution de scripts SQL au démarrage de la base :
# Pour exécuter un script SQL au démarrage de l'instance de la base :
jdbc:h2:mem:test;INIT=create schema if not exists test\;runscript from '~/sql/init.sql'