Différences

Ci-dessous, les différences entre deux révisions de la page.

--- basededonnees:mysql [22/03/2017 17:12]
julp [Comment supprimer une option au sql_mode ?]
+++ basededonnees:mysql [22/03/2017 17:19] (Version actuelle)
julp
@@ Ligne 1: / Ligne 1: @@
+====== Convertir une colonne timestamp Unix en DATETIME ======
+<code sql>ALTER TABLE sujet ADD tmpswap DATETIME;
+UPDATE sujet SET tmpswap = FROM_UNIXTIME(ancien);
+ALTER TABLE sujet DROP ancien;
+ALTER TABLE sujet CHANGE tmpswap ancien DATETIME;</code>
+(sujet : nom de la table ; ancien : nom de la colonne initialement en (big)int)
+====== Convertir une colonne VARCHAR pour dates au format fr (d/m/Y) en DATE ======
+<code sql>ALTER TABLE sujet ADD tmpswap DATE;
+UPDATE sujet SET tmpswap = STR_TO_DATE(ancien, '%d/%m/%Y');
+ALTER TABLE sujet DROP ancien;
+ALTER TABLE sujet CHANGE tmpswap ancien DATE;</code>
+(sujet : nom de la table ; ancien : nom de la colonne initialement en varchar)
+Pourquoi utiliser le type DATE ?
+  * pour simplifier toute manipulation sur les dates : vous pouvez ainsi nativement utiliser toutes les fonctions date du SGBD sans avoir à d'abord reconvertir [le format de] la date
+  * le format interne (us) prévu permet nativement un tri (lexicographique) correct
+  * le formatage au format fr (ou autres) ne justifie pas une colonne en VARCHAR : tous les langages ou même les SGBD (DATE_FORMAT pour MySQL) permettent facilement la conversion. Et quid du jour où votre site devra être internationalisé ?
+  * le SGBD s'assure que la date est un minimum correct, toute erreur à l'insertion/modification est minimisée. Au contraire, avec un varchar, si le format est incorrect, ça peut être catastrophique suivant l'importance des données. MySQL avec un sql_mode comprenant les valeurs NO_ZERO_IN_DATE (interdit des composantes de date à 0) et NO_ZERO_DATE (interdit les dates "zéro" 0000-00-00 obtenues par défaut dans des cas +/- foireux) et sans ALLOW_INVALID_DATES assurera une cohérence des plus strictes.
+====== Mapper des valeurs en d'autres lors d'une requête ======
+On peut aisément remplacer un CASE comme celui-ci :
+<code sql>SELECT CASE <in>
+    WHEN 'FT' THEN 'Fiche Technique'
+    WHEN 'PV' THEN 'Procès Verbal'
+    WHEN 'NF' THEN 'Norme'
+    ELSE 'Valeur par défaut'
+END;</code>
+Par :
+<code sql>COALESCE(
+    ELT(
+        FIELD(<in>, 'FT', 'PV', 'NF'),
+        'Fiche Technique', 'Procès Verbal', 'Norme'
+    ),
+    'valeur par défaut'
+)</code>
+C'est l'"équivalent" PHP de :
+<code php>$out = str_replace(array('FT', 'PV', 'NF'), array('Fiche Technique', 'Procès Verbal', 'Norme'), $in);
+# ou, mieux :
+$out = ['FT' => 'Fiche Technique', 'Procès Verbal', 'NF' => 'Norme'][$in];</code>
+Par contre : ça revient éventuellement à "réinventer" le type ENUM
+====== Désactiver (temporairement) les clés étrangères ======
+<code sql>SET FOREIGN_KEY_CHECKS=0;
+-- les différentes opérations sql à exécuter en ignorant les clés étrangères
+SET FOREIGN_KEY_CHECKS=1;</code>
+====== Les timezones et comment régler l'heure ======
+Déplacé sur [[http://www.julp.fr/blog/posts/5-les-timezones-et-comment-regler-l-heure]]
+====== Optimisation : éviter des SELECT inutiles ======
+Déplacé sur [[http://www.julp.fr/blog/posts/6-optimisation-eviter-des-select-inutiles]]

julp

Outils pour utilisateurs

Outils du site

Différences

Outils de la page