Antichesse (o ^ω^ o)
Quel article à charge ! Même UTF-8 en prend pour son grade !
Mais ça vaut le coup d'oeil et en dehors du ton vinaigré de son auteur, les arguments sont là.
La base H2DB intègre un moteur NoSQL au format clef-valeur.
Elle gère les accès concurrents en lecture/écriture et les connexions effectuées en parallèle par de multiples utilisateurs.
La documentation de la base indique que le mode concurrent est toujours qualifié de beta, mais il existe depuis la 1.3.x en expérimentale, et en "to qualify" depuis la 1.4.x.
C'est le cas depuis 2010 donc... Je pense qu'en 8 années et 196 patch (de la 1.4.0 à 1.4.196) on devrait être bons là nan ?
Bref, si H2 intègre un mode "dump before update" ou que je parvienne à en faire un, je switch et j'abandonne PostgreSQl et MySQL à son profit.
MySQL conseil d'utiliser le type DATETIME pour stocker des dates, mais côté JVM quel est le type de données à utiliser ? Je résume ici la réponse :
- java.sql.Date permet de stocker une date mais sans l'heure.
- java.sql.Time permet de stocker l'heure mais sans la date.
- java.sql.Timestamp permet de stocker les deux.
Donc le type qui se rapproche le plus de DATETIME c'est java.sql.Timestamp.
Edit : et côté MySQL, que se passe-t-il ?
MySQL dispose de quatre types pour stocker les données temporelles :
- DATE pour stocker une date mais sans l'heure.
- TIME pour stocker une heure mais sans la date.
- DATETIME pour stocker un timestamp allant de 1000-01-01 00:00:00.000000 à 9999-12-31 23:59:59.999999.
- TIMESTAMP pour stocker un timestamp au format UTC allant de 1970-01-01 00:00:01 UTC à 2038-01-19 03:14:07 UTC.
Donc côté base de données vous êtes dans deux cas de figure qui ont eux-mêmes des sous-cas :
- Soit votre SI est mono-timezone et dans ce cas là, DATETIME vous accorde une plage de données plus large.
- Soit votre SI est multi-timezone (comme chez mon client actuel) et dans ce cas là vous avez deux sous-cas :
- Soit vous gérez la timezone côté serveur (Kotlin / Rust par exemple) => DATETIME.
- Soit vous gérez la timezone côté base et vous lui passez uniquement des timestamp UTC => TIMEZONE.
Je suis sur le sujet et un article vient tout droit d'une de mes rivers.
Merci les amis :D
Un PDF à lire lorsque l'on configure une base MySQL derrière un driver Java et HikariCP en pool de connexions.
Je parlais justement de PostgreSQL avec Doudou hier en lui affirmant que je considérais ce SGBD comment bien meilleur que MySQL. Cela confirme encore mon point de vue.
Edit : mais l'écosystème MySQL est mieux (faut pas pousser hein).
-
L'indice des primary keys commence à 1 et non à 0 (donc faire bien attention avec des insert efrectués manuellement lorsque l'on veut s'assurer qu'un tuple dispose d'un ID en particulier).
-
Mieux vaut utiliser des ID en UNSIGNED, par exemle :
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
Ceux-ci permettent de n'avoir que des ID positifs et rangés pas ordre croissant, ce qui améliore la recherche. De plus votre limite passera de 2 millards d'entrées à 4 milliards d'entrées dans cette table.
- Préférez le type INT UNSIGNED à BIGINT (qui peut aussi être UNSIGNED). Vous ferai une économie mémoire d'environ 12% sur les recherches et économiserez 4 octets sur le disque par tuple ayant un id (et ceci pour chaque table).
Limitations :
- BIGINT UNSIGNED permet de gérer jusqu'à 2^64 - 1 entrées alors que INT UNSIGNED jusqu'à 2^32 - 1. On risque d'atteindre plus rapidement la limite non ?
==> Oui c'est vrai, mais admettons que :
- Notre système encaisse 100 000 insertions / jour.
- Cela fera 36 500 000 d'insertions / an.
- Soit 3 650 000 000 insertions pour 1 siècle.
Si votre application est toujours là dans 10 an ce sera déjà énorme alors 1 SIÈCLE !!!
Moralité, nous ne sommes pas Google.
In MySQL, never use “utf8”. Use “utf8mb4”. – Adam Hooper – Medium - kalvn's links - Liandri's Links.
Je résume ici :
- Dans MySQL, l'encodage appelé utf_ (ou utf8_general_ci) n'est pas de l'UTF-8.
- En réalité, il s'agit d'une implémentation partielle de l'UTF-8 limité à trois octets.
- Cela peut poser problème, voir corrompre vos données si vous faites de l'UTF-8 end-to-end.
- A la place de l'encodage 'utf8', choisissez 'utf8mb4' qui est une vraie implémentation du format.
Je précise aussi qu'il faut utiliser la collation utf8mb4_unicode_ci à la place de utf8mb4_general_ci car le tri alphabétique y respecte la langue de la région employant les caractères particuliers.
Comment définir la timezone de votre base MySQL
Modifier le fichier : /etc/mysql/mysql.conf.d/mysqld.cnf
default-time-zone='+00:00'La qualité de cette réponse !!! Date de 2012 quand même
Manipuler les bases MtSQL en ligne de commande avec auto-completion.
Via une river
Un récapitulatif des différents types de données disponibles sur MySQL et MariaDB. Toujours pratique à avoir sous la main.
Accéder à une base MySQL en Python via le driver MysqlDB. Très facile à faire et très sympa à utiliser (quand on vient du monde Java).
À noter que pour installer le driver MysqlDb il suffit de lancer : sudo aptitude install python-mysqldb
Coudifié (je suis lancée ce matin ^^)/
Très utile pour moi en ce moment. Mon serveur n'a pas assez de RAM et les 311 Mo consommés en permanence par MySQL l'oblige à swapper sans cesse.