Un petit gestionnaire de bases de données web en php supportant MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL, Oracle et autres.

Quelques faits amusants et particuliers à propos de SQLite.

Un chouette outils en ligne pour expliciter (y compris graphiquement) les EXPLAIN PLAN de Postgres, et de bien voir ce qui consomme le plus.

mySQL pourrit par le rachat par Oracle => mariaDB.
Et maintenant mariaDB est racheté par un fond d'investissement.
Il est temps de le fuire.

PS: Pour préciser, c'est la partie "Entreprise" qui se fait racheter, pas la fondation.

Sous le coude : une extension vectorielle à SQLite (très pratique pour faire des requêtes du genre : donne-moi les point à moins de telle distance de tel point. Ou bien: Donnes-moi tous les points situés dans ce rectangle.)

DuckDB peut être une alternative à SQLite, intéressante car elle utilise tous les coeurs du CPU. (https://duckdb.org/)

Sous le coude : Des tutoriels pour Postgres, avec un terminal sql directement dans le navigateur pour expérimenter.

Oh mais non, pas encore.
Ils se rappellent encore pourquoi ils ont forké MySql ? 🤦🏻‍♂️

Bon je retourne sur mes SQLite et Postgres.

Sous le coude : un long article sur le chiffrement des données en base de données.

Sous le coude: Choisir ses clés primaires sous Postgres.

Sous le coude: Un livre pour développeur avec quelques astuces SQL.
PS: Il faut s'inscrire à la mailing-list pour recevoir le livre.  Si cela vous embête, voici le livre : https://sebsauvage.net/nc/s/GdSGGJEnMGPDM2D

Utiliser SQLite pour stocker des données sensibles, ce n'est pas con : SQLite étant immensément plus simple que des bases comme Postgres ou Oracle, la surface d'attaque est largement inférieure.
(Et c'est sans compter que SQLite est très fortement testé et résiste très bien aux crashs. Le "redémarrage" du serveur est également nettement moins problématique.)

Quand un ancien de l'équipe MySQL/MariaDB décide de quitter Oracle en disant que - franchement - vous ne devriez pas utiliser MySQL/MariaDB et que vous devriez vraiment regarder du côté Postgres, on peut se dire que oui, il y a des problèmes.
(Et cela rejoint les constatations que j'ai pu faire dans mes boulots précédents: MySQL pose beaucoup de problèmes. Postgres est plus intéressant et possède désormais des fonctionnalités plus avancées et il est plus performant.)

PS: Oui je sais que MariaDB est forké de MySQL et n'a plus à voir avec Oracle.

Sous le coude.
SQLite est une formidable base de données, mais très simple. Elle n'a pas certaines fonctions avancées de Postgres ou Oracle. Mais SQLite est facilement extensible, et beaucoup de monde a développé des extensions. En voici quelques unes (fonctions de hashage, recherche flou et phonétique, fonctions json, expressions régulières, UUID...)

Sous le coude: Des supports de formation pour la base de données Postgres.

Sous le coude parce que ça pourra me servir: Insérer 1 milliard de lignes dans une base SQLite en moins d'une minute.

Si on résume (extrait de l'article):

PRAGMA journal_mode = OFF;
PRAGMA synchronous = 0;
PRAGMA cache_size = 1000000;
PRAGMA locking_mode = EXCLUSIVE;
PRAGMA temp_store = MEMORY;

What do these do?
- Turning off journal_mode will result in no rollback journal, thus we cannot go back if any of the transactions fail. This disables the atomic commit and rollback capabilities of SQLite. Do not use this in production.
- By turning off synchronous, SQLite does not care about writing to disk reliably and hands off that responsibility to the OS. A write to SQLite, may not mean it is flushed to the disk. Do not use this in production.
- The cache_size specifies how many memory pages SQLite is allowed to hold in the memory. Do not set this to a high value in production.
- In EXCLUSIVE locking mode, the lock held by the SQLite connection is never released.
- Setting temp_store to MEMORY will make it behave like an in-memory database.

De bonnes raisons d'utiliser SQLite (autre que celles que j'énonce d'habitude)

Pour Postgres. Sous le coude on ne sait jamais.

Woo alors attendez: SQLite peut:
- supporter l'insertion directe de json
- avoir des colonnes virtuelles basées sur le json
- et donc permet du requêtage sur ces colonnes virtuelles.
On peut donc utiliser SQLite pour stocker du json et requêter dedans en profitant des indexes et du tri !
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?chmZMQ)

Sous le coude: Un client SQL multibases qui permet d'afficher directement des graphes à partir des requêtes SQL.
Ça peut être sympa pour avoir rapidement des vues sur les données sans pour autant se monter un BO.

Sous le coude: Les choses à ne pas faire dans Postgres.

Sous le coude: Quelques recommandations de configuration pour Postgres.

La faille de SQLite a été montée en épingle.
En réalité, vous n'êtes vulnérable que si :
1) vous avez activé le module recherche full text (FTS3) (qui ne fait pas partie du coeur de SQLite)
et
2) Vous exécutez du code SQL arbitraire.
Si vous êtes dans le cas 2), vous être déjà dans une énorme merde question sécurité, avec SQLite ou n'importe quelle autre base, en fait.

Pour mon boulot, après avoir pratiqué de l'Oracle et du SQL Server pendant des années, j'aborde Postgres (j'ai un gros script à adapter pour Postgres).

Je veux importer des CSV, et je découvre la commande COPY qui permet de coller directement son CSV dans le script  \o/
C'est dix fois plus pratique que les outils Oracle.

J'importe des données, erreur sur un format de date: Postgres me suggère la bonne option à utiliser \o/

Je sens que je vais aimer ce dbms  :-)

(sous le coude)

Une recommandation d'utiliser des UUID à la place des auto-incréments en bases de données.
(J'avais aussi lu l'inverse... ^^)

OVH est l'un des plus importants hébergeurs mondiaux.
Ils sont donc confrontés à des problèmes peu communs, comme celui de sauvegarder un million (glups) de bases de données chaque jour.
C'est toujours intéressant de voir comment ils s'y prennent (et j'aime les entreprises qui partagent leur expérience).
(via http://links.kevinvuilleumier.net/?SwboWA)

J'aime SQLite.
Article similaire en français: http://www.developpez.com/actu/94614/Cinq-raisons-d-utiliser-SQLite-en-2016/
(via http://lehollandaisvolant.net/?id=20160109175118)

Hoper nous gratifie d'une études sur les méthodes d'injection SQL. Intéressant !

Visiblement il est possible de faire des attaques à travers mysql_real_escape_string().  Ce n'est donc pas la panacée pour vous protéger des attaques d'injection SQL.

sql.js est l'équivalent de SQLite, mais en Javascript.

Google migre ses bases mySQL vers MariaDB. Merci Oracle, tu as bien foutu le bordel.

Je note ça ici: un script pour convertir mySQL en SQLite

Tiens... un équivalent de SQLite, mais pour les bases clé-valeur.

Ma motivation ? Elle est très simple: Si tu expliques qu'il faut copier un fichier par FTP et ouvrir la page, beaucoup d'internautes vont y arriver (même si c'est déjà un peu compliqué). S'il faut en plus expliquer à Mr Michu comment trouver l'adresse de son serveur mySQL (différents selon les hébergeurs), login et mot de passe (pas toujours les mêmes), ça devient plus compliqué.

Ah et c'est également nettement plus facile le jour où il faut changer d'hébergeur (Transférer des fichiers par FTP = simple. ; Réaliser un dump SQL complet de la base et le ré-exécuter sur la destination = mission impossible pour beaucoup d'internautes.)
SQLite est plus simple que mySQL, et largement, LARGEMENT assez performant pour un site perso.
Réduire les obstacles à l'accès à l'auto-hébergement = Good.

C'est pas du snobisme, c'est de l'esprit pratique.

PS: J'ai aussi travaillé sur du mySQL, MS SQL Server et en ce moment c'est de l'Oracle. A chacun ses usages. La puissance et la complexité de mySQL ne se justifient pas quand on parle de donner l'accès au plus grand nombre à de petits outils pour un site perso.

EDIT: http://lehollandaisvolant.net/index.php?mode=links&id=20130320230917   :-)

Un client lourd pour les bases mySQL/MSSQL: http://www.heidisql.com/
(via http://bajazet.fr/shaarli)

:-)
Je compatis.

cf. http://sebsauvage.net/rhaa/index.php?2011/04/06/10/29/56-puree-de-bordel-d-access-a-la-con

oO  Reddit avait avant une base de données relationnelle, avec un beau schéma bien propre, bien maintenu... et avec leur monstrueuse augmentation de trafic, ils ont tout foutu à la poubelle et utilisent maintenant 2 tables: les "choses" et les "données". Plus de schéma à maintenir. Certes ils ne bénéficient plus de l'algèbre relationnelle, mais ils n'ont plus de soucis comme ajouter une colonne à une table de 10 millions de lignes.

Et pourquoi pas des fichiers ? (voir mon commentaire)

à garder sous le coude !

Un article pro-ORM (Object-Relational Mapping). Je ne suis pas fan des outils d'ORM (même j'utilise un de ces outils sur le projet sur lequel je bosse), mais je devrais sans doute revoir mon opinion. On m'a déjà montré diverses choses sympa, mais je continue à aimer le bon SQL des familles (même si ça veut dire faire son CRUD à la mimine, ce qui n'est pas si terrible que ça.)

☑ Se la péter en sortant plein de termes techniques - ça, c'est fait.

mySQL ne peut pas "scaler" comme Oracle, Microsoft SQL Server ou les bases clé-valeur ? Mon oeil. La preuve: Twitter utilise mySQL.

CryptDB : Après divers papiers scientifiques expliquant le concept (notamment chez IBM), CryptDB serait la première base de données à implémenter concrètement le principe: Une base de données chiffrée capable de travailler directement sur les données chiffrées. Cela pourrait avoir des impacts important sur le cloud computing, et résoudrait un bon nombre de problèmes de sécurité.

Pour ceux qui travaillent sur les bases de données avec la méthode MERISE, AnalyseSI est pratiquement le seul outil gratuit (et libre) en dehors des mastodontes comme PowerAMC. Certes il ne fait pas les MCT (par exemple), mais pour tout ce qui est MCD/MPD, ça marche.

Le mouvement NoSQL fait beaucoup de bruit, mais au final il n'est pas tant adopté que ça.

Tiens, les anciens collègues de Virgin Mobile passent à SkySQL ? Je croyais qu'ils étaient plus pour Hibernate.

Peut-être une solution à mon problème. EDIT: ouais bon, il faut que j'installe le JDK complet, et aussi Apache Ant, etc.  ça devient lourd.

Il a absolument, totalement raison. (Je parle en connaissance de cause pour avoir faire de l'intégration de bases de données.)

Après LibreOffice, c'est au tour de mySQL de forker avec SkySQL.