Discussion :

[Sethenssen]

Bonjour,

Mon besoin est très simple mais je coince.

J'ai une table d'achat (A) avec une colonne d'abonné que je récupère chaque jour.
Ici un abonné peut donc faire plusieurs achats.

Je souhaite créer une table (B) avec uniquement une colonne d'abonné en clé primaire, pour éviter les doublons.

Le but est donc de copier les abonnés (A) vers les abonnés (B)
Ce qui fonctionne avec:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

insert into table_b (select account_id from table_a where operator_id = 3 and billing_date >= current_date() - INTERVAL 1 DAY group by account_id);

Cependant si je ré-exécute cette requête la clé primaire de la table_b est violée et donc je ne peux y copier mes nouveaux abonnés.

J'ai lu qu'on pouvait peut-être y arriver avec ON DUPLICATE KEY UPDATE mais je n'arrive pas à avoir la bonne syntaxe.

Est-ce la bonne démarche?
Que me conseillez-vous?

Table_b:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
DROP TABLE IF EXISTS `table_b`;
CREATE TABLE `table_b` (
  `account_id` varchar(10) NOT NULL,
  #`operator_id` smallint(2) unsigned NOT NULL,
  PRIMARY KEY (`account_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='table_b';

[Fred_34]

Je souhaite créer une table (B) avec uniquement une colonne d'abonné en clé primaire, pour éviter les doublons.

C'est louche mais admettons... (En plus un Varchar en clé primaire c'est rarement recommandé)

Le ON DUPLICATE KEY UPDATE ne sert à rien vu qu'il sert principalement à mettre à jour les colonnes autre que la clé primaire.

Dans ton cas(une seule colonne), tu as juste à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT IGNORE INTO table_b ...

Les doublons seront ignorés et les nouvelles valeurs insérées.

Je pense que tu devrais être plus précis sur ton besoin, car ce que tu souhaites faire n'a aucun intérêt.

[Sethenssen]

Bonjour,

Merci ! Cela répond parfaitement à mon besoin.

C'est un varchar car l'identifiant peut contenir des lettres comme des chiffres.
Ma table_a contient des millions de lignes et aller taper l'information distinct abonné sur cette dernière me prend trop de ressource, je préfère donc passer par une table annexe qui n'aura que des dizaines de milliers de lignes.