si vous souhaitez définir l'heure par défaut, vous devez passer à timestamp
dans votre type de données,
le datetime
va afficher l'entrée utilisateur du tableau...
http://dev.mysql.com/doc/refman/5.0/en/timestamp-initialization.html
http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
Comme le DEFAULT CURRENT_TIMESTAMP
la question a déjà une réponse, je ne répondrai qu'à l'incompatibilité de sensibilité à la casse dans les noms de table entre Windows et Linux.
Sous Windows, les systèmes de fichiers sont par défaut insensibles à la casse.
Mais sur Linux et d'autres systèmes d'exploitation *NIX comme, ils sont sensibles à la casse par défaut.
La raison pour laquelle vous obtenez une incompatibilité de comportement ici est le système de fichiers, car chaque table est créée en tant que fichier séparé et le système de fichiers gère la sensibilité à la casse pour vous.
MySQL a un paramètre pour remplacer ce comportement :
Par exemple, sous Unix, vous pouvez avoir deux tables différentes nommées
my_table
etMY_TABLE
, mais sous Windows ces deux noms sont considérés comme identiques.
Utilisez
lower_case_table_names=1
sur tous les systèmes. Le principal inconvénient est que lorsque vous utilisezSHOW TABLES
ouSHOW DATABASES
, vous ne voyez pas les noms dans leur casse d'origine.Utilisez
lower_case_table_names=0
sous Unix etlower_case_table_names=2
sur Windows. Cela préserve la casse des noms de base de données et de table. L'inconvénient est que vous devez vous assurer que vos instructions font toujours référence à vos noms de base de données et de table avec la casse correcte sous Windows. Si vous transférez vos instructions vers Unix, où la casse est importante, elles ne fonctionneront pas si la casse est incorrecte.
Exception : Si vous utilisez des tables InnoDB et que vous essayez d'éviter ces problèmes de transfert de données, vous devez définirlower_case_table_names=1
sur toutes les plateformes pour forcer la conversion des noms en minuscules.[...]
Pour éviter les problèmes causés par de telles différences,il est préférable d'adopter une convention cohérente, comme toujours créer et faire référence aux bases de données et aux tables en utilisant des noms en minuscules . Cette convention est recommandée pour une portabilité et une facilité d'utilisation maximales.
Ceci est un extrait du manuel MySQL sur la sensibilité à la casse des identifiants
Le DEFAULT CURRENT_TIMESTAMP
prise en charge d'un DATETIME
(type de données) a été ajouté dans MySQL 5.6.
Dans les versions 5.5 et antérieures, cela ne s'appliquait qu'à TIMESTAMP
(type de données) colonnes.
Il est possible d'utiliser un BEFORE INSERT
trigger en 5.5 pour attribuer une valeur par défaut à une colonne.
DELIMITER $$
CREATE TRIGGER ...
BEFORE INSERT ON mytable
FOR EACH ROW
BEGIN
IF NEW.mycol IS NULL THEN
SET NEW.mycol = NOW();
END IF;
END$$
La sensibilité à la casse (des requêtes sur des valeurs stockées dans des colonnes) est due au collation
utilisé pour la colonne. Classements se terminant par _ci
sont insensibles à la casse. Par exemple latin1_swedish_ci
est insensible à la casse, mais latin1_general_cs
est sensible à la casse.
La sortie de SHOW CREATE TABLE foo
affichera le jeu de caractères et le classement pour les colonnes de type de caractères. Ceci est spécifié au niveau de chaque colonne. La "valeur par défaut" spécifiée au niveau de la table s'applique aux nouvelles colonnes ajoutées à la table lorsque la nouvelle définition de colonne ne spécifie pas de jeu de caractères.
MISE À JOUR
Kaii a souligné que ma réponse concernant la "sensibilité à la casse" traite des valeurs stockées dans les colonnes et si les requêtes renverront une valeur à partir d'une colonne contenant une valeur de "New"
sera retourné avec un prédicat comme "t.col = 'new'"
.
Voir la réponse de Kaii concernant les identifiants (par exemple, les noms de table) étant gérés différemment (par défaut) sous Windows que sous Linux.