IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Conception et performances de lourdes tables


Sujet :

MySQL

  1. #1
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut Conception et performances de lourdes tables
    Bonjour,

    Je suis en train de mettre en place des statistiques de visites sur différentes applications, appelons-les "zone membre" et "zone visiteur" pour simplifier.

    Comme le plupart des champs sont identiques, mis à part deux ou trois spécifiques, tous les enregistrements se feront dans une table unique, appelons-la "visites", dont un champ sera nécessaire pour différencier la zone de visite.

    Exemple de structure :
    Code x : Sélectionner tout - Visualiser dans une fenêtre à part
    id, champ1, champ2, champ3, ..., champ10
    où champ1 et champ2 sont spécifiques à la zone membre et champ3 est spécifique à la zone visiteur.

    Cette table "visites" risque de se remplir assez rapidement, disons quelques centaines de milliers d'enregistrements par semaine.

    Quelle serait la meilleure méthode à adopter pour garder une certaine fluidité dans l'exécution des requêtes sur cette table ?

    J'ai déjà pensé à créer des vues, l'une pour la zone membre excluant donc le champ3 et l'autre pour la zone visiteur excluant les champ1 et champ2.
    On peut aussi scinder la table "visites" en tables hebdomadaires dont une table merge serait l'union de toutes ces tables.
    Peut-être un mixe entre les deux ? Peut-être une autre technique à laquelle je ne pense pas ou que je ne connais pas ?
    J'utilise MySQL 5.0.24 donc je ne peux pas utiliser le partitionnage.

    Je suis preneur de tous les conseils que vous pourrez m'apporter.

    Merci !

  2. #2
    Expert confirmé

    Homme Profil pro
    SDE
    Inscrit en
    Août 2007
    Messages
    2 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : SDE

    Informations forums :
    Inscription : Août 2007
    Messages : 2 013
    Points : 4 321
    Points
    4 321
    Par défaut
    Bonjour,

    en terme de conception je pense que l'héritage pourrait être une bonne chose.

    par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    VISITE(id_visite, champ_commun1, champ_commun2, ...)
    VISITE_MEMBRE(#id_visite, champ_membre1, champ_membre2, ...)
    VISITE_VISITEUR(#id_visite, champ_visiteur1, champ_visiteur2, ...)
    Il suffit alors d'utiliser une vue utlisant une double jointure externe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE VIEW V_VISITE
    AS
    SELECT VISITE
    FROM VISITE_MEMBRE
    LEFT JOIN VISITE_MEMBRE ON VISITE.id_visite = VISITE_MEMBRE.id_visite
    LEFT JOIN VISITE_VISITEUR ON VISITE.id_visite = VISITE_VISITEUR.id_visite;
    Cette conception me semble plus élégante, l'utilisation des vues permet de ne pas alourdir l'utilisation de la base.

    Bien évidement la table VISITE ne se remplira pas moins vite, mais quand on souhaite stocker beaucoup de données il faut bien les mettre quelque part
    http://alaindefrance.wordpress.com
    Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
    SDE at BitTitan

  3. #3
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    Ca me parait plutôt bien oui, comme conception, mais compliquons un peu la chose. Au lieu de deux applications, mettons en quatre avec un champ commun dans trois des applis. Ca me fait créer un champ identique dans chacune des tables VISITE_%application% ou il faut rajouter une nouvelle couche d'héritage ?
    Sachant aussi que chaque fois qu'une application est rajoutée, il faut que ce soit le moyen contraignant possible (exemple d'un champ de la nouvelle application qui se retrouve commun avec un champ spécifique d'une application existante) ...

  4. #4
    Expert confirmé

    Homme Profil pro
    SDE
    Inscrit en
    Août 2007
    Messages
    2 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : SDE

    Informations forums :
    Inscription : Août 2007
    Messages : 2 013
    Points : 4 321
    Points
    4 321
    Par défaut
    Oui dans ce cas les choses se compliquent de manière sérieuse.

    En effet une nouvelle couche d'héritage est un moyen de résoudre le problème mais comme tu dois le sentir, il deviendra de plus en plus lourd de gérer ces données.
    http://alaindefrance.wordpress.com
    Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
    SDE at BitTitan

  5. #5
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    Cette nouvelle couche d'héritage nous donnera en plus du fil à retordre dans le cas d'ajout d'applications, puisqu'il faudra créer un table héritée pour chacune des possibilités de champ commun avec les autres tables. Leur nombre augmentera alors de manière exponentielle ainsi que les jointures qui devront être faites.

    Que penses-tu de ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    VISITE(id_visite, champ_commun1, champ_commun2, champ_specifique_a1, champ_specifique_a2, ..., application)
    Où VISITE est une table merge sur :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    VISITE%année%%num_semaine%( [même champs] )
    Exemple :
    VISITE200801
    [...]
    VISITE200852
    Avec une vue pour chaque application sur la merge, par exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    CREATE VIEW V_VISITE_MEMBRE
    AS
    SELECT champ_commun1, ..., champ_spécifique_membre1, ...
    FROM VISITE
    WHERE application = 'membre';
    Et où les tables VISITE%année%%num_semaine% seraient créées à l'aide d'un trigger avant l'INSERT sur la merge vérifiant la semaine selon la date d'insertion, du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    CREATE TRIGGER t_create_table_visite BEFORE INSERT ON visite
       FOR EACH ROW
       BEGIN
          DECLARE @annee AS INT
          DECLARE @num_semaine AS INT
          DECLARE @new_table AS STRING
     
          @annee = DATE_FORMAT(...., NEW.date_visite)
          @num_semaine = DATE_FORMAT(...., NEW.date_visite)
          @new_table = CONCAT("VISITE", @annee, @num_semaine)
     
          CREATE TABLE IF NOT EXISTS @new_table
          [...]
       END//
    Après on peut imaginer des vues en plus pour chaque application sur la merge mais pour des années ou des mois choisis (voire même des champs spécifiques) pour ne pas alourdir les traitements.

    Et dans le cas d'ajout d'une application, on a juste à rajouter une valeur dans le champ application de type ENUM par exemple, et de créer la vue associée selon le modèle des autres vues.



    ?

    Merci en tout cas pour tes réponses !

  6. #6
    Expert confirmé

    Homme Profil pro
    SDE
    Inscrit en
    Août 2007
    Messages
    2 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : SDE

    Informations forums :
    Inscription : Août 2007
    Messages : 2 013
    Points : 4 321
    Points
    4 321
    Par défaut
    Oui ça me semble bien. J'avoue ne pas avoir pensé au tables merge

    Mis à part le fait qu'il ne faudra pas oublier de faire attention de mettre à jour la définition de la table mergé, et vérifier sur combien de table une table merge peut porter au maximum (puisque dans ton cas, il y en aura 52 par ans).
    Si la limitation est trop forte, il faudra envisager d'avoir une table mergé par ans, et d'avoir une vue qui fera des unions.
    http://alaindefrance.wordpress.com
    Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
    SDE at BitTitan

  7. #7
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    J'avais en effet oublié qu'il fallait mettre à jour l'union de la merge après la création de la table ..
    Pour info, une merge peut supporter jusqu'à 475 tables, donc ça laisse le temps de voir venir.

    Seul hic dans tout ça, c'est que je ne peux pas faire de CREATE TABLE dans un TRIGGER apparemment ...

  8. #8
    Expert confirmé

    Homme Profil pro
    SDE
    Inscrit en
    Août 2007
    Messages
    2 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : SDE

    Informations forums :
    Inscription : Août 2007
    Messages : 2 013
    Points : 4 321
    Points
    4 321
    Par défaut
    En effet ton système est capable de tenir de cette façon 9 ans.
    A savoir si il est nécessaire de prévoir aussi loin ou pas...
    Si le système est fait pour tenir aussi longtemps autant adopter une structure qui tiendra.

    Pour les create table a partir d'un trigger, j'avoue n'avoir jamais essayer, mais ça ne me surprendrais pas ...
    http://alaindefrance.wordpress.com
    Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
    SDE at BitTitan

  9. #9
    Rédacteur/Modérateur

    Avatar de Antoun
    Homme Profil pro
    Architecte décisionnel
    Inscrit en
    Octobre 2006
    Messages
    6 277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 6 277
    Points : 11 733
    Points
    11 733
    Par défaut
    Je confirme que les triggers refusent le DDL. Je crois également qu'ils refusent tout ordre qui entraîne un COMMIT implicite, mais je ne suis plus très sûr.

    Par contre, il doit être possible dans ton trigger de faire appel à une proc stock qui fait le CREATE TABLE.

    Enfin, pour mettre des variables du genre @new_table dans une requête SQL, le seul moyen est d'utiliser les prepared statements (cf doc sur PREPARE et EXECUTE).

    (toute cette cuisine est évidemment 100% spécifique MySQL)
    Antoun
    Expert Essbase, BO, SQL

    La bible d'Essbase, 2ème édition

  10. #10
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    @kazou : Ce système n'est peut-être pas censé tenir 9 ans (d'ici là j'ose imaginer que les langages auront évolué et que de meilleures techniques seront sorties), mais bien quelques années.
    A voir à l'usage s'il garde ses performances ou non.

    @Antoun : Malheureusement, selon la doc :

    Le déclencheur ne peut pas exécuter de procédures avec la commande CALL. Cela signifie que vous ne pouvez pas contourner le problèmes des noms de tables en appelant une procédure stockée qui utilise les noms de tables.
    Donc je suis condamné à faire cette vérification en PHP juste avant l'INSERT, chose ennuyeuse puisque source d'erreur ..

  11. #11
    Rédacteur/Modérateur

    Avatar de Antoun
    Homme Profil pro
    Architecte décisionnel
    Inscrit en
    Octobre 2006
    Messages
    6 277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 6 277
    Points : 11 733
    Points
    11 733
    Par défaut
    Citation Envoyé par Bisûnûrs Voir le message
    @Antoun : Malheureusement, selon la doc :
    Ach ! faudrait que je me remette sérieusement à MySQL, moi !

    Citation Envoyé par Bisûnûrs Voir le message
    Donc je suis condamné à faire cette vérification en PHP juste avant l'INSERT, chose ennuyeuse puisque source d'erreur ..
    Alternative : tu fais une proc stock qui gère le tout, et ton PHP fait le CALL à la place de l'INSERT.
    Antoun
    Expert Essbase, BO, SQL

    La bible d'Essbase, 2ème édition

  12. #12
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    Je viens d'essayer, mais un autre problème se pose à moi : Impossible d'utiliser le '?' pour un nom de table dans une commande préparée.

    Exemple qui fonctionne :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    PREPARE stmt1 FROM 'SELECT * FROM matable WHERE id = ?';
    Exemple qui ne fonctionne pas :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    PREPARE stmt2 FROM 'SELECT * FROM ? WHERE id = 1';
    Or dans mon cas, ça serait :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    PREPARE s_create_table FROM 'CREATE TABLE IF NOT EXISTS ? LIKE modele';
    et cette syntaxe génère une erreur.

  13. #13
    Rédacteur/Modérateur

    Avatar de Antoun
    Homme Profil pro
    Architecte décisionnel
    Inscrit en
    Octobre 2006
    Messages
    6 277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 6 277
    Points : 11 733
    Points
    11 733
    Par défaut
    oui, tu es obligé de passer par les variables de session, genre @matable.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SET @matable = 'trucmuche42' ;
    SET @SQL = CONCAT('CREATE TABLE IF NOT EXISTS ', @matable, 'LIKE modele' ;
    PREPARE s_create_table FROM  @SQL ;
    Antoun
    Expert Essbase, BO, SQL

    La bible d'Essbase, 2ème édition

  14. #14
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    Ca avance tout doucement, mais je suis confronté à pas mal de problèmes de procédure stockée, c'est limite vexant.

    Par exemple, j'ai ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    CREATE PROCEDURE p_insert_visites (bdd VARCHAR(25), date_visite DATETIME, cles TEXT, valeurs TEXT)
    BEGIN
     
      DECLARE annee       INT;
      DECLARE num_semaine INT;
      DECLARE new_table   VARCHAR(12);
     
      SET annee       = DATE_FORMAT( date_visite, '%Y' );
      SET num_semaine = DATE_FORMAT( date_visite, '%v' );
      SET new_table   = CONCAT( 'visite', annee, num_semaine );
     
      SET @sql_create = CONCAT( 'CREATE TABLE IF NOT EXISTS ', bdd, '.', new_table, ' LIKE modele' ) ;
     
      PREPARE s_create_table FROM @sql_create;
      EXECUTE s_create_table;
      DEALLOCATE PREPARE s_create_table;
     
    END//
    Lancé en ligne de commande, aucun problème, mais de part la présence du EXECUTE, si je fais un mysql_query() pour appeler la procédure stockée, j'ai le fameux "can't return a result set in the given context".

    Faisant fi de ce problème pour le moment, je continue à développer ma procédure et juste à ce moment-là je veux faire un SELECT sur cette table fraichement créée pour vérifier qu'elle vient de se créer ou non et donc avoir le résultat dans une variable. Ce qui me donne :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    CREATE PROCEDURE p_insert_visites (bdd VARCHAR(25), date_visite DATETIME, cles TEXT, valeurs TEXT, OUT x INT)
    BEGIN
     
      [...]
      DEALLOCATE PREPARE s_create_table;
     
      SET @sql_select = CONCAT( 'SELECT COUNT(*) INTO x FROM ', bdd, '.', new_table );
     
      PREPARE stmt_test FROM @sql_select;
      EXECUTE stmt_test;
     
    END//
    Ce qui ne fonctionne pas, MySQL retournant l'erreur "Undeclared variable: x". J'essaie alors comme ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SET @sql_select = CONCAT( 'SELECT COUNT(*) INTO ', x, ' FROM ', bdd, '.', new_table );
    Mais lors de l'appel j'ai une erreur de syntaxe NULL à la ligne 1.

    Je ne sais pas comment m'en sortir ..

  15. #15
    Rédacteur/Modérateur

    Avatar de Antoun
    Homme Profil pro
    Architecte décisionnel
    Inscrit en
    Octobre 2006
    Messages
    6 277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 6 277
    Points : 11 733
    Points
    11 733
    Par défaut
    y aurait des solutions crado avec FOUND_ROWS, mais comme tu veux de la performance, je pense que la meilleure solution est une table temporaire :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    SET @sql_select = CONCAT( 'CREATE TEMPORARY TABLE resu
      SELECT COUNT(*) AS nb FROM ', bdd, '.', new_table ) ;
     
    PREPARE stmt_test FROM @sql_select;
    EXECUTE stmt_test;
     
    SELECT nb INTO x FROM resu ;
    Antoun
    Expert Essbase, BO, SQL

    La bible d'Essbase, 2ème édition

  16. #16
    Modérateur
    Avatar de Bisûnûrs
    Profil pro
    Développeur Web
    Inscrit en
    Janvier 2004
    Messages
    9 868
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2004
    Messages : 9 868
    Points : 16 258
    Points
    16 258
    Par défaut
    Ta solution d'utiliser une variable de session(?) était apparemment bonne et fonctionnait.

    En tout cas grâce à vous deux j'ai pu finir ma procédure qui fonctionne impeccablement (même si je ne garantis pas une optimisation parfaite).
    Je la mets ici, peut-être que ça pourra en inspirer certains :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    DROP PROCEDURE IF EXISTS p_insert_visites//
    CREATE PROCEDURE p_insert_visites( bdd VARCHAR(25), date_visite DATETIME, clefs TEXT, valeurs TEXT )
    BEGIN
     
      DECLARE annee       INT;
      DECLARE num_semaine INT;
      DECLARE new_table   VARCHAR(13);
      DECLARE champ1      VARCHAR(13);
      DECLARE done        INT DEFAULT 0;
      DECLARE cur_tables  CURSOR FOR SHOW TABLES LIKE "visites%";
      DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
     
      SET annee       = DATE_FORMAT( date_visite, '%Y' );
      SET num_semaine = DATE_FORMAT( date_visite, '%v' );
      SET new_table   = CONCAT( 'visites', annee, num_semaine );
     
      SET @sql_create = CONCAT( 'CREATE TABLE IF NOT EXISTS ', bdd, '.', new_table, ' LIKE modele' );
     
      PREPARE s_create_table FROM @sql_create;
      EXECUTE s_create_table;
      DEALLOCATE PREPARE s_create_table;
     
      SET @sql_select = CONCAT( 'SELECT COUNT(*) INTO @nb_enreg FROM ', bdd, '.', new_table );
     
      PREPARE s_select FROM @sql_select;
      EXECUTE s_select;
      DEALLOCATE PREPARE s_select;
     
      IF @nb_enreg = 0 THEN
        BEGIN
     
          OPEN cur_tables;
     
          SET @sep          = '';
          SET @liste_tables = '';
     
          REPEAT
            FETCH cur_tables INTO champ1;
     
            IF NOT done THEN
              SET @chp1         = champ1;
              SET @liste_tables = CONCAT( @liste_tables, @sep, @chp1 );
            END IF;
     
            SET @sep = ',';
          UNTIL done END REPEAT;
     
          CLOSE cur_tables;
     
          SET @sql_alter = CONCAT( 'ALTER TABLE `m_visites` UNION(', @liste_tables ,') INSERT_METHOD=LAST' );
          PREPARE s_alter FROM @sql_alter;
          EXECUTE s_alter;
          DEALLOCATE PREPARE s_alter;
     
        END;
      END IF;
     
      SET @sql_insert = CONCAT( 'INSERT INTO ', bdd, '.', new_table, '(', clefs, ')', ' VALUES(', valeurs, ')' );
     
      PREPARE s_insert FROM @sql_insert;
      EXECUTE s_insert;
      DEALLOCATE PREPARE s_insert;
     
    END//
    Et pour l'appel en PHP, mysqli est obligatoire :

    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    mysqli_query( $link, 'CALL p_insert_visites( "test", "2008-07-28 10:12:00", "champ1, champ2, champcommun", "\'Bla\', \'Bli\', \'Blu\'" )' );

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 11/08/2008, 16h33
  2. [Access][Conception] Nb champs dans une table
    Par arno2000 dans le forum Access
    Réponses: 6
    Dernier message: 01/08/2006, 18h30
  3. conception et utilisation d'une table
    Par lkryss dans le forum Décisions SGBD
    Réponses: 4
    Dernier message: 29/06/2006, 12h14
  4. Réponses: 3
    Dernier message: 21/10/2005, 15h56
  5. [conception] champs vides ou plusieurs tables ?
    Par in dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 17/02/2004, 09h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo