J'ai eu la maladresse de croire que Le type ENUM de Mysql pouvait servir de garde fou.

En effet

[SQL]
create table `test_enum`( 
`id` int UNSIGNED NOT NULL AUTO_INCREMENT , 
`monEnum` enum('a','brol','7') , 
`monAutreEnum` enum('a','brol','7') NOT NULL , 
PRIMARY KEY (`id`)
)  ;

Je ne veux que 'a','brol' ou '7', éventuellement NULL dans monEnum

insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a','a');
# (1 row(s) affected)


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,NULL,'a');
# (1 row(s) affected)


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a',NULL);
# Error Code : 1048
# Column 'monAutreEnum' cannot be null


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,NULL,NULL);
# Error Code : 1048
# Column 'monAutreEnum' cannot be null

    id  monEnum  monAutreEnum
------  -------  ------------
     1  a        a           
     2  a        a           
     3  (NULL)   a

Là ca allait.

Mais maintenant

[SQL]
insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'','a');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a','');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'','');
# (1 row(s) affected, 2 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'Z','a');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a','Z');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'Z','Z');
# (1 row(s) affected, 2 warning(s))

On voit que les "vides" et les "Z" ne bloquent pas l'ajout de l'enregistrement. et sont remplacés par "vide" alors que ce n'est pas une valeur acceptée.

En effet le manuel dit ceci.

Si vous insérez une valeur illégale dans une énumération ENUM (c'est à dire, une chaîne qui n'est pas dans la liste de valeurs autorisées), la chaîne vide est insérée pour représenter une erreur. Cette chaîne peut être distinguée d'une chaîne vide 'normale' par le fait que cette chaîne à la valeur numérique 0. Nous reviendrons sur ce point plus tard.

Par exemple, une colonne créée comme ENUM("un", "deux", "trois") peut prendre n'importe quelle valeur ci-dessous. L'index de chaque valeur est aussi présenté :

 Valeur     Index
--------- --------
 NULL 	   NULL
 ""         0
 "un"       1
 "deux"     2
 "trois"    3

[Resultat]
    id  monEnum  monAutreEnum
------  -------  ------------
     1  a        a           
     2  a        a           
     3  (NULL)   a           
     4           a           
     5  a                    
     6                       
     7           a           
     8  a                    
     9                       

Notez que si j'ajoute une valeur par défaut, ca n'y change rien

[SQL]
alter table `test_enum` 
change `monEnum` `monEnum` enum('a','brol','7') character set latin1 collate latin1_swedish_ci default 'a' NULL , 
change `monAutreEnum` `monAutreEnum` enum('a','brol','7') character set latin1 collate latin1_swedish_ci default 'a' NOT NULL;


///[SQL]
insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'','a');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a','');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'','');
# (1 row(s) affected, 2 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'Z','a');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'a','Z');
# (1 row(s) affected, 1 warning(s))


insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'Z','Z');
# (1 row(s) affected, 2 warning(s))

    id  monEnum  monAutreEnum
------  -------  ------------
     1  a        a           
     2  a        a           
     3  (NULL)   a           
     4           a           
     5  a                    
     6                       
     7           a           
     8  a                    
     9                       
    10           a           
    11  a                    
    12                       
    13           a           
    14  a                    
    15                       

En fait tout dépends du mode sql en cours

[SQL]
select @@SQL_MODE;
SET SESSION sql_mode='STRICT_ALL_TABLES';
select @@SQL_MODE;
#@@SQL_MODE       
#-----------------
#STRICT_ALL_TABLES

insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'brol','z');
#Error Code : 1265
#Data truncated for column 'monAutreEnum' at row 1
insert into `test_enum`(`id`,`monEnum`,`monAutreEnum`) values ( NULL,'z','brol');
#Error Code : 1265
#Data truncated for column 'monEnum' at row 1

SET SESSION sql_mode='';
select @@SQL_MODE;

Là mes 2 inserts sont bloqués avec le message

ADD	ALL	ALTER
ANALYZE	AND	AS
ASC	ASENSITIVE	BEFORE
BETWEEN	BIGINT	BINARY
BLOB	BOTH	BY
CALL	CASCADE	CASE
CHANGE	CHAR	CHARACTER
CHECK	COLLATE	COLUMN
CONDITION	CONNECTION	CONSTRAINT
CONTINUE	CONVERT	CREATE
CROSS	CURRENT_DATE	CURRENT_TIME
CURRENT_TIMESTAMP	CURRENT_USER	CURSOR
DATABASE	DATABASES	DAY_HOUR
DAY_MICROSECOND	DAY_MINUTE	DAY_SECOND
DEC	DECIMAL	DECLARE
DEFAULT	DELAYED	DELETE
DESC	DESCRIBE	DETERMINISTIC
DISTINCT	DISTINCTROW	DIV
DOUBLE	DROP	DUAL
EACH	ELSE	ELSEIF
ENCLOSED	ESCAPED	EXISTS
EXIT	EXPLAIN	FALSE
FETCH	FLOAT	FLOAT4
FLOAT8	FOR	FORCE
FOREIGN	FROM	FULLTEXT
GOTO	GRANT	GROUP
HAVING	HIGH_PRIORITY	HOUR_MICROSECOND
HOUR_MINUTE	HOUR_SECOND	IF
IGNORE	IN	INDEX
INFILE	INNER	INOUT
INSENSITIVE	INSERT	INT
INT1	INT2	INT3
INT4	INT8	INTEGER
INTERVAL	INTO	IS
ITERATE	JOIN	KEY
KEYS	KILL	LABEL
LEADING	LEAVE	LEFT
LIKE	LIMIT	LINES
LOAD	LOCALTIME	LOCALTIMESTAMP
LOCK	LONG	LONGBLOB
LONGTEXT	LOOP	LOW_PRIORITY
MATCH	MEDIUMBLOB	MEDIUMINT
MEDIUMTEXT	MIDDLEINT	MINUTE_MICROSECOND
MINUTE_SECOND	MOD	MODIFIES
NATURAL	NOT	NO_WRITE_TO_BINLOG
NULL	NUMERIC	ON
OPTIMIZE	OPTION	OPTIONALLY
OR	ORDER	OUT
OUTER	OUTFILE	PRECISION
PRIMARY	PROCEDURE	PURGE
RAID0	READ	READS
REAL	REFERENCES	REGEXP
RELEASE	RENAME	REPEAT
REPLACE	REQUIRE	RESTRICT
RETURN	REVOKE	RIGHT
RLIKE	SCHEMA	SCHEMAS
SECOND_MICROSECOND	SELECT	SENSITIVE
SEPARATOR	SET	SHOW
SMALLINT	SONAME	SPATIAL
SPECIFIC	SQL	SQLEXCEPTION
SQLSTATE	SQLWARNING	SQL_BIG_RESULT
SQL_CALC_FOUND_ROWS	SQL_SMALL_RESULT	SSL
STARTING	STRAIGHT_JOIN	TABLE
TERMINATED	THEN	TINYBLOB
TINYINT	TINYTEXT	TO
TRAILING	TRIGGER	TRUE
UNDO	UNION	UNIQUE
UNLOCK	UNSIGNED	UPDATE
UPGRADE	USAGE	USE
USING	UTC_DATE	UTC_TIME
UTC_TIMESTAMP	VALUES	VARBINARY
VARCHAR	VARCHARACTER	VARYING
WHEN	WHERE	WHILE
WITH	WRITE	X509
XOR	YEAR_MONTH	ZEROFILL

Je l'avais déjà posté mais j'en ai eu besoin aujourd'hui. Donc comme c'est toujours utile, je le rappelle.

Une explication pour démarrer à partir de zéro un cluster MySQL 7.0.7 (ou supérieur) avec 2 noeuds de gestion. C'est dans l'article How to start MySQL Cluster 7.0 with 2 magement nodes? de notre compatriote Geert.

Comme expliqué ici.

si vous passez à 5.1.12

Incompatible change: For utf8 columns, the full-text parser incorrectly considered several nonword 
punctuation and whitespace characters as word characters, causing some searches to return 
incorrect results. The fix involves a change to the full-text parser in MySQL 5.1.12, 
so as of 5.1.12, any tables that have FULLTEXT indexes on utf8 columns must be repaired with REPAIR TABLE:

REPAIR TABLE tbl_name QUICK;

Si vous passez à 5.1.16

Il sera nécéssaire de réindexer les fulltext

Incompatible change: The structure of FULLTEXT indexes 
has been changed in MySQL 5.1.6. After upgrading to 
MySQL 5.1.6 or greater, any tables that have FULLTEXT 
indexes must be repaired with REPAIR TABLE:

REPAIR TABLE tbl_name QUICK;

Comment trouver facilement ces tables ?

 SELECT `TABLE_NAME` FROM `STATISTICS` WHERE `INDEX_TYPE`= 'FULLTEXT' ;

Pour faire le point sur Timestamp : un bel article sur le sujet.

timestamp, ou Unix Timestamp, correspond au nombre de secondes écoulées depuis le 1er Janvier 1970.

A lire aussi : La page dans le manuel

Petite expérience sur mysql 5.1

4 tables de même structure mais 4 stockages différents : MyISAM et archive, avec et sans partition. un peu plus de 500 enregistrements ....

sans partition

MyISAM 52Ko ->Archive : 20 Ko

avec partition

Myisam 63 Ko -> Archive 12.1Ko

Là je suis étonné, l'archive avec partition est 40% plus petite.

J'ai ajouté 31000 enregistrements

sans partition

• MyISAM : 52Ko -> 1.59Mo
• Archive : 20 Ko -> 90Ko !!!!

avec partition

• MyISAM : 63 Ko -> 1.6Mo
• Archive : 12.1Ko -> 82Ko

2 grande conclusions

• L'archive ça vaut vraiment le coup quand on peut supporter ses limites
• Le partitionnement ne change rien (il y a des différences négligeables)

Je reste quand même étonné que le partitionnement d'une table archive réduit le stockage.

Voir la suite pour plus de détails

Lire la suite...

Ce post est à moitié une manière de faire , et une autre une façon de mieux le faire?

Donc, vous voulez construire un système qui effectue des tâches. Vous voulez que le travail puisse être organisé en parallèle pour la vitesse, mais aussi pour la redondance. Ce système doit être coordonnée de façon, par exemple, les mêmes tâches ne sont pas faites deux fois, le statut de chaque tâche est facile à voir, et de multiples serveurs peuvent effectuer les tâches simplement en interrogeant la source centrale.

Voici la traduction de Creating a Job queue in Innodb Comment peut-on construire cela avec innodb pour avoir MySQL comme système central de notre système?

[MYSQL]
CREATE TABLE IF NOT EXISTS job_queue(
   id int(10) not null auto_increment,

   updated timestamp not null,
   started timestamp not null,

   state ENUM('NEW', 'WORKING', 'DONE', 'ERROR' ) default 'NEW',

   PRIMARY KEY ( id ),
   KEY( STATE )
) ENGINE=Innodb;

Dans ce schéma, notre table de tâches a un identifiant unique, une heure de démarrage et de mise à jour et un statut.

Dans un système réel, il y aura sans doute un peu plus de méta-données ici sur la nature des tâches.

Lorsque de nouvelles tâches doivent être programmées, les lignes sont insérées dans la table (avec started à NOW (), et updated est mis à jour automatiquement)

[MYSQL]
insert into job_queue set started=NOW();

Maintenant, en perl, nous écrivons un contrôleur de tâches. Ce programme peut être exécuté sur chaque serveur qui pourrait accomplir les tâches.

[perl]
#!/usr/bin/perl

# Don't leave zombies around, shamelessly stolen from 'man perlipc'
use POSIX ":sys_wait_h";
sub REAPER {
    my $child;
    while (($child = waitpid(-1,WNOHANG)) > 0) {
        $Kid_Status{$child} = $?;
    }
    $SIG{CHLD} = \&REAPER;
}
$SIG{CHLD} = \&REAPER;

use DBD::mysql;

my $dbh = DBI->connect(
'DBI:mysql:database=test;host=127.0.0.1;port=3306',
'test', 'test',
{ RaiseError => 1, AutoCommit => 0 }
);


while( 1 ) {
 my $row;
 eval {
     my $sth = $dbh->prepare( "select id from job_queue where state='NEW' li
mit 1 for update" );
     $sth->execute();
     $row = $sth->fetchrow_hashref();
     $sth->finish();
 };

 if( $@ or !$row ) {
     # Couldn't lock or lock wait timeout
     $dbh->commit();
     sleep 10;
     next;
 }

 # Got one, change state, commit, and fork a worker

 $dbh->do( "update job_queue set state='WORKING' where id=" . $row->{id} );
 $dbh->commit();

 # Fork a worker
 if( fork )  {
     # Parent, let the child have the old connection and reconnect to
     # the db.
     $dbh->{InactiveDestroy} = 1;
     $dbh = DBI->connect(
        'DBI:mysql:database=test;host=127.0.0.1;port=3306',
        'test', 'test',
        { RaiseError => 1, AutoCommit => 0 }
     );
 } else{
     # fils
     print "Création du verrou\n";
     $dbh->do( "select * from job_queue where id=" . $row->{id}
         . " for update " );

     print "Travail en cours\n";
     #On simule un traitement
     srand( time );
     sleep rand 30;

     $dbh->do( "update job_queue set STATE='DONE' where
         id=" . $row->{id} );
     print "On Commit\n";
     $dbh->commit();

     $dbh->disconnect();

     exit;
 }
 sleep 1;
}

Maintenant, ce n'est pas mauvais. Mais il a au moins une chose que je n'aime pas. Si une des tâches n'aboutit pas, il n'existe aucun moyen pour réaffecter la tâche.

Ideally each worker would have a lock on his job row inside of a transaction, which it is doing now, but, instead of the job being in the 'WORKING' state first, I'd rather it was 'NEW' before the transaction started. If that were the case, if a worker died, it's unfinished transaction would be rolled back, and the job would be unlocked and NEW again.

Idéalement, chaque travailleur aurait un verrou sur son travail dans une transaction, ce qui est fait maintenant, mais, au lieu du travail en cours dans le «travail» d'abord, je préfère c'est "NOUVEAU" avant l'opération a commencé . Si tel était le cas, si un travailleur est mort, il est inachevé transaction serait annulée, et la tâche serait déverrouillé et NEW nouveau.

However, because of the way SELECT ... FOR UPDATE works, Innodb will deadlock waiting for 'NEW' jobs to unlock from the workers (or wait until they are done). This is sub-optimal, since my parent process could be forking new jobs in the meantime. What would fix this is a SELECT ... FOR UPDATE that skipped locked rows without blocking. Toutefois, en raison de la façon SELECT ... MISE À JOUR DE œuvres, InnoDB va impasse d'attente pour les «nouveaux» pour déverrouiller l'emploi des travailleurs (ou d'attendre jusqu'à ce qu'ils soient fait). Cela est sous-optimale, car mon père pourrait être forking de nouveaux emplois dans l'intervalle. Qu'est-ce que ce correctif est un SELECT ... MISE À JOUR DE verrouillé ignoré que des lignes sans blocage.

If anyone knows a good way to achieve this, please let me know!

However, assuming we have no better alternatives, we can create a reaper process like this:

[perl]
#!/usr/bin/perl

use DBD::mysql;

my $dbh = DBI->connect(
   'DBI:mysql:database=test;host=127.0.0.1;port=3306',
   'test', 'test',
   { RaiseError => 1, AutoCommit => 0 }
);


while( 1 ) {
    my $row;
    eval {
        my $sth = $dbh->prepare( "select id from job_queue where state='WORKING' limit 1 for update" );
        $sth->execute();
        $row = $sth->fetchrow_hashref();
        $sth->finish();
    };

    if( $@ or !$row ) {
        # Couldn't lock or lock wait timeout
        $dbh->commit();
        sleep 10;
        next;
    }

    # Got one, change state, commit, and fork a worker

    $dbh->do( "update job_queue set state='NEW' where id=" . $row->{id} );    $dbh->commit();

    sleep 1;
}

This will find the first WORKING row and try to lock it. Since normal jobs will be moved to DONE before they are committed, this should only ever find jobs that are in WORKING and unlocked, which means the worker died.

However this isn't perfect. Because SELECT ... FOR UPDATE will try to lock a row already locked, we have to wait until all jobs before our stalled job are complete, getting deadlocks along the way (be sure to set your innodb_lock_wait_timeout fairly low!. Even further, I've seen dead worker processes leave behind idle mysql connections that hold onto their row locks.

Is there any smoother way to do this? I'd love to hear other people's advice.

La room mySql rencontre un très beau succès. Entré a l'heure juste du début de la conférence de Kris, j'ai eu une des dernières places confortables.

La présentation concernait les solutions de monitoring. Je ne vais pas m'étendre sur le contenu. Il est plus simple d'aller voir ça sur le site.

Si j'écris c'est pour dire aussi combien il est plaisant de voir la qualité de ces présentations. Mais qu'en plus les liens entre elles sont établis. Les différents orateurs connaissent les présentations des autres.

• Vladimir Kolesnikov: Practicing DBA's Guide to the PBXT Storage Engine
• Kris Buytaert: Monitoring MySQL
• Geert Vanderkelen: MySQL Cluster
• Roland Bouman: MySQL 5.1 Plugins
• Kaj Arnö: MySQL, powering and using Social Networks
• Ewen Fortune: Percona MySQL patches and the XtraDB storage engine
• Giuseppe Maxia: Boost performance with MySQL 5.1 partitions
• Jurriaan Persyn: Database Sharding

Le programme détaillé est ici.

Ca se passe donc dans la Room AW1.126!

Moi je vais tenter d'aller voir Kris et Geert du Belgian Mysql User Group. Ainsi que Kaj Arnö et Giuseppe Maxia.

Le 18 mars prochain, au Cafe Sport à Leuven se tiendra le prochain meeting du MySQL Belgian User Group Geert envisage d'aborder les points suivants

• revue rapide de ce qui s'est passé dernièrement avec MySQL
• Avenir de certaines activités en Belgique
• Bonnes pratiques, en ce qui concerne l'installation, l'assistance, et quelques points sur les performances.

c'est là que ca se passe.

Version originale

par peter

Comme vous le savez peut-être, même si vous êtes seulement des tables Innodb votre réplication n'est pas complètement sécurisée en cas de crash. Si le slave MySQL se plante ou est éteint, il est probable que les logs de relais en court de synchronisation (ils ne sont pas synchronisés sur le disque), deviennent obsolète et la synchronisation est perdue

Pour les séries MySQL 4.0 et 4.1 série il y avait un gros hack si vous utilisez uniquement des tables Innodb.

La suite

SELECT WEEK('2008-01-01'); // 0;
SELECT WEEK('2008-01-07'); // 1;
SELECT WEEK('2008-02-03'); // 4;
SELECT WEEK('2008-12-31'); // 52;

WEEK ne compte que les semaines complètes.

Certains vont dire, mais non la première semaine c'est la 0.

Non, non, en voici la preuve

SELECT DAYOFWEEK('2008-01-01'), # 3
       DAYOFWEEK('2007-01-01'), # 2
       DAYOFWEEK('2006-01-01'), # 1 <- ICI l'année commence le premier jour de la semaine
       DAYOFWEEK('2005-01-01'), # 7
       DAYOFWEEK('2004-01-01'), # 6
       DAYOFWEEK('2003-01-01'), # 5
       DAYOFWEEK('2002-01-01'); # 4 

Du coup

SELECT WEEK('2008-01-01'), # 0
       WEEK('2007-01-01'), # 0
       WEEK('2006-01-01'), # 1 <-on est bien la première semaine complète de l'année
       WEEK('2005-01-01'), # 0
       WEEK('2004-01-01'), # 0
       WEEK('2003-01-01'); # 0 

et du coup

SELECT WEEK('2008-12-31'), # 52
       WEEK('2007-12-31'), # 52
       WEEK('2006-12-31'), # 53
       WEEK('2005-12-31'), # 52
       WEEK('2004-12-31'), # 52
       WEEK('2003-12-31'); # 52 

En fait maintenant il y a une deuxième paramètre.

WEEK(date ,mode)

Voici ce que dit le manuel.

Avec deux arguments, la fonction WEEK() vous permet de spécifier si les semaines commencent le Dimanche ou le Lundi et la valeur retournée sera dans l'intervalle 0-53 ou bien 1-52. Lorsque l'argument mode est omis, la valeur de la variable default_week_format (ou 0 en MySQL 4.0 ou plus ancien) est utilisée.

Voici un tableau explicatif sur le fonctionnement du second argument : Valeur Signification

• 0 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année
• 1 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
• 2 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année
• 3 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
• 4 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
• 5 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année
• 6 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
• 7 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année

Le mode 3 est disponible depuis MySQL 4.0.5. Le mode 4 est disponible depuis MySQL 4.0.17.

# Je crée une table
DROP TABLE IF EXISTS `testReplace`;
CREATE TABLE `testReplace` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `a` INT(11) DEFAULT '1',
  `b` INT(11) DEFAULT '2',
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
#J'y ajoute 2 records /lignes/tuples
INSERT INTO `testReplace` 
	(`a`, `b`)
	VALUES
	(1, 1),(2,2);
SELECT * FROM  `testReplace`;

 id | a | b
============
  1 | 1 | 1
  2 | 2 | 2

#Je remplace la première valeur de la première ligne 
REPLACE INTO `testReplace` 
	SET `id`=1, a=3;
# que vaut b ? 

  SELECT * FROM  `testReplace`;

 id | a | b
============
  1 | 3 | 2
  2 | 2 | 2

B a repris sa valeur par défaut

En pratique cela veut dire que si on fait un replace et qu'on ne précise pas toutes les colonnes les colonnes non-spécifiées prennent la valeur par défaut alors qu'on peut s'attendre à un "non" changement.

Il est donc faux de croire que REPLACE c'est un exist(id) ? UPDATE : INSERT

C'est plutôt

• exist(id) ? DELETE
• suivi d'un INSERT

Il faut donc utiliser une autre méthode.

INSERT INTO table (id,a) VALUES (1,3)
  ON DUPLICATE KEY UPDATE a=3;

mercredi, 12 septembre 2007

Présentation en ligne

Le Web 2.0 représente la seconde génération de services disponibles sur le web permettant aux utilisateurs de collaborer et de partager des informations en ligne. Une des caractéristiques du Web 2.0 est que ce sont les données qui conduisent son évolution. Durant ce séminaire web nous explorerons comment les sociétés déploient des architectures et applications Web 2.0 pilotées par MySQL et MySQL Cluster.

Lire la suite...

• Découvrir comment tirer au mieux parti de MySQL
• Bénéficier de conseils d'experts sur l'optimisation des performances
• Assimiler les meilleures pratiques MySQL
• Découvrir les nouvelles fonctionnalités et services pour mieux planifier vos déploiements de MySQL
• Mieux comprendre comment sélectionner la solution de haute disponibilité pour MySQL la mieux adaptée à vos besoins
• Poser toutes vos questions aux experts MySQL, et avoir l'opportunité de faire part de votre feedback et de vos commentaires
• Nouer des relations avec l'équipe de MySQL AB
• Découvrir comment vous pouvez bénéficier des solutions de nos partenaires

Agenda :

1. Introduction : Bertrand Matthelié, Directeur Marketing EMEA
2. La roadmap MySQL, nouveautés & fonctionnalités à venir : Robin Schumacher, Directeur Product Management
3. Optimisation des performances: Session 1, meilleures pratiques : Stéphane Varoqui, Consultant
4. MySQL pour les applications en ligne : Serge Frezefond Ingénieur Avant-Vente
5. Optimisation des performances: Session 2, études de cas Stéphane Varoqui
6. MySQL pour Datawarehouse & BI : Serge Frezefond
7. Présentation Client: Skyblog et Crédit Mutuel
8. Stratégies de Haute Disponibilité avec MySQL : Max Mether, Formateur
9. Rendre la gestion de données d'abonnés flexible grâce à MySQL Cluster Carrier Grade : Christophe Thivend, Alcatel-Lucent
10. Définition d'une stratégie de moteurs de stockage : Kaj Arnö, VP Community; Stéphane Varoqui, Serge Frezefond
11. Conclusion et Questions/Réponses

MySQL AB :: Conférences Européennes MySQL 2007

Prix 199€, (159€ avant le 31 Août 2007)