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

MS SQL Server Discussion :

[2019] Avis sur une méthode de calcul de Hash unique


Sujet :

MS SQL Server

  1. #1
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut [2019] Avis sur une méthode de calcul de Hash unique
    Bonjour,

    Alors voilà j'ai besoin de calculé un Hash SHA1 pour chaque record de chaque table qui va servir d'identifiant.
    Ce hash est calculé sur certaines colonnes des tables pas toujours les mêmes d'une table à l'autre.

    En revanche la chaine hashée doit avoir un format très précis pour évité les duplicats.

    Du coup il est important que son calcul ne soit qu'a un seul endroit pour être certain qu'il est le même d'un dev à l'autre, régénérable, maintenable, etc...

    Bref, quels seraient vos idées / propositions pour ce problème ?

    A suivre quelques précisions
    - Oui je sais que les hash ont un risque de créer des doublons. Mais tellement infime que ce risque est ignoré.
    - J'utilise un Hash plutôt qu'un GUID pour qu'il puisse être connu a l'avance et régénérable.
    - J'ai essayer d'utiliser les fonction de Hash de sql serveur, mais comme les paramètres doivent être fixe, c'est compliqué.

    Enfin la solution actuellement implémentée qui ne satisfait pas complétement
    Nous avons créé une CLR qui prendre un nombre variable de SQLVariant en paramètres.
    La CLR fait parfaitement le travail mais pose les problèmes suivants :
    - Les [n]Varchar(MAX) ne fonctionnent pas car ne peuvent pas être converti en SQL variant.
    - Les CLR ont un nombre de paramètres défini, j'ai du donc créé une SP pour chaque nombre de paramètres.
    - Dans les requêtes simples ça va très vite mais dés que c'est un peu compliqué l'Optimiseur pète un câble et une requête de 20 secondes passe à 1h. Un work around à ce dernier point est de stocker les hashs calculés dans une table temporaire puis d'utiliser cette dernière dans la requête complexe.

  2. #2
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 753
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 753
    Points : 10 687
    Points
    10 687
    Billets dans le blog
    21
    Par défaut
    Mes idées en vrac :
    - générer un identifiant unique sous forme de chaine de caractère par concaténation des colonnes qui vont bien, par table (par ex : NOM + DATECREATION + COL18) avec un séparateur entre chaque champ
    - utiliser une colonne calculée pour déterminer cet identifiant
    - calculer le hash à partir de la colonne calculer (là, se sera très simple)
    - utiliser une colonne calculée pour stocker le hash
    - persister les colonnes calculées
    - ajouter un INDEX UNIQUE sur l'identifiant et/ou hash pour s'assurer de l'unicité (ou sur les colonnes de base servant au calcul de l'identifiant)
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 686
    Points : 52 290
    Points
    52 290
    Billets dans le blog
    4
    Par défaut
    Je ne voit vraiment pas l'intérêt de cette usine à gaz... Que va t'il se passer lors d'un UPDATE ?

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Il n'y a pas d'update dans cette DB.
    C'est du pur insert.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 686
    Points : 52 290
    Points
    52 290
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Bonjour,

    Alors voilà j'ai besoin de calculé un Hash SHA1 pour chaque record de chaque table qui va servir d'identifiant.
    Ce hash est calculé sur certaines colonnes des tables pas toujours les mêmes d'une table à l'autre.

    En revanche la chaine hashée doit avoir un format très précis pour évité les duplicats.

    Du coup il est important que son calcul ne soit qu'a un seul endroit pour être certain qu'il est le même d'un dev à l'autre, régénérable, maintenable, etc...
    Donc vous aller créer un hotspot qui induira des problèmes de performance...

    Bref, quels seraient vos idées / propositions pour ce problème ?

    A suivre quelques précisions
    - Oui je sais que les hash ont un risque de créer des doublons. Mais tellement infime que ce risque est ignoré.
    - J'utilise un Hash plutôt qu'un GUID pour qu'il puisse être connu a l'avance et régénérable.
    Un GUID peut lui aussi être généré à l'avance. Dans tous les langage de programmation vous avez une fonction de génération des GUID. Exemple en C# NewGuid(). Vous pouvez aussi appeler la fonction NEWID() de SQL Server dans une requête préalable. Exemple ;
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT NEWID() AS GUID;
    - J'ai essayer d'utiliser les fonction de Hash de sql serveur, mais comme les paramètres doivent être fixe, c'est compliqué.

    Enfin la solution actuellement implémentée qui ne satisfait pas complétement
    Nous avons créé une CLR qui prendre un nombre variable de SQLVariant en paramètres.
    La CLR fait parfaitement le travail mais pose les problèmes suivants :
    - Les [n]Varchar(MAX) ne fonctionnent pas car ne peuvent pas être converti en SQL variant.
    C'est totalement faux, il suffit d'utiliser la fonction CAST... qui est faite pour cela !
    Mais stocker une valeur binaire dans du texte est une idiotie. Utilisez du binaire. Par exemple BINARY(20)...
    - Les CLR ont un nombre de paramètres défini, j'ai du donc créé une SP pour chaque nombre de paramètres.
    ça n'a aucun sens de créer une procédure pour cela. Un simple fonction suffit !
    - Dans les requêtes simples ça va très vite mais dés que c'est un peu compliqué l'Optimiseur pète un câble et une requête de 20 secondes passe à 1h. Un work around à ce dernier point est de stocker les hashs calculés dans une table temporaire puis d'utiliser cette dernière dans la requête complexe.
    Dans tous les cas vous aurez des problèmes de performance. En effet une clé pour être efficace doit être la plus petite possible. Un GUID c'est 16 octets ce qui impose une double lecture dans le processeur 64 bits (=8 octets) donc coute deux fois plus cher qu'un BIGINT... comme clé. De plus, comme les valeurs sont aléatoires, il y aura fragmentation des index. Tout ceci pèsera fortement sur les performances...
    Quand au hash c'est pire encore... 20 octets pour le SHA1 ! Donc 3 passe dans le processeur, 6 pour faire une jointure.... Et fragmentation.

    Sans parler de la lourdeur de la clé dont le nombre d'octets pèsera sur les sauvegardes, la maintenance...
    C'est donc une très mauvaise idée, que l'on rencontre fréquemment chez les développeurs qui ne maîtrisent pas le fonctionnement des SGBDR !

    Pourquoi ne pas utiliser un autoincrément à partir d'une séquence ? Il suffit de demander la nouvelle valeur avec :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT NEXT VALUE FOR MaSequence AS NOUVEL_ID;
    Puis de l'utiliser dans la requête...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 022
    Points : 38 164
    Points
    38 164
    Billets dans le blog
    8
    Par défaut
    Le seul cas où un hash est intéressant, c'est justement si l'on veut disperser les valeurs pour qu'elles ne soient pas contigües.
    L'intérêt est de limiter les problèmes de blocages liés aux accès concurrents (les valeurs contigües étant le plus souvent rangées dans la même page en tout cas quand les espaces sont bien organisés, donc un verrou page prend toutes les valeurs contigües).
    Dans les autres cas, je rejoins SQLPro : une colonne de type IDENTITY est préférable

  7. #7
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Vous êtes les deux hors sujet.

    Vous vous douter bien que si je pars sur des HASH c'est par ce que je n'ai pas le choix.
    Maintenant la question et de le faire au mieux en limitant les dégâts.

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 686
    Points : 52 290
    Points
    52 290
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Le seul cas où un hash est intéressant, c'est justement si l'on veut disperser les valeurs pour qu'elles ne soient pas contigües.
    Je suis d'accord sur cette première phrase, mais pas sur la suivante !
    L'intérêt est de limiter les problèmes de blocages liés aux accès concurrents (les valeurs contigües étant le plus souvent rangées dans la même page en tout cas quand les espaces sont bien organisés, donc un verrou page prend toutes les valeurs contigües).
    Parce que un HASH ne se fait pas en cache car il a besoin des données pour être calculé alors que les méthodes d'auto incrément font du cache... Donc d'un point de vue concurrentiel, c'est incommensurablement plus performant
    Dans les autres cas, je rejoins SQLPro : une colonne de type IDENTITY est préférable
    Enfin pour ta première phrase sur la non contiguïté du hash la seule fois ou j'y ais trouvé un intérêt c'était il y a plus de 20 ans pour mettre en parallèle plusieurs machines SQL Server coopératives dans le cadre du site web FNAC.com afin de faire du scale out

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 686
    Points : 52 290
    Points
    52 290
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Vous êtes les deux hors sujet.

    Vous vous douter bien que si je pars sur des HASH c'est par ce que je n'ai pas le choix.
    Maintenant la question et de le faire au mieux en limitant les dégâts.
    Donc ça ne devrait pas être votre clé primaire !!!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 449
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 449
    Points : 17 795
    Points
    17 795
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Bref, quels seraient vos idées / propositions pour ce problème ?
    Vous nous avez décrit ce que vous voulez faire, comment vous essayez de le faire mais pas pourquoi vous voulez le faire.

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 022
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 022
    Points : 38 164
    Points
    38 164
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Je suis d'accord sur cette première phrase, mais pas sur la suivante !Parce que un HASH ne se fait pas en cache car il a besoin des données pour être calculé alors que les méthodes d'auto incrément font du cache... Donc d'un point de vue concurrentiel, c'est incommensurablement plus performant
    Certes, mais nous ne parlons pas de la même chose, je parle du blocage des pages de données lié aux valeurs contiguës d'identifiants, quand l'identifiant est défini comme critère de clusterisation. Ici on peut arriver à une situation de blocage (time out).

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 686
    Points : 52 290
    Points
    52 290
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Certes, mais nous ne parlons pas de la même chose, je parle du blocage des pages de données lié aux valeurs contiguës d'identifiants, quand l'identifiant est défini comme critère de clusterisation. Ici on peut arriver à une situation de blocage (time out).
    Jamais constaté sur du SQL Server depuis plus de 20 ans !

    ça a existé... Mais c'était il y a très très longtemps.... Du temps de la RAM à tambour probablement !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #13
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2008
    Messages
    698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Octobre 2008
    Messages : 698
    Points : 586
    Points
    586
    Par défaut
    Citation Envoyé par Waldar Voir le message
    Vous nous avez décrit ce que vous voulez faire, comment vous essayez de le faire mais pas pourquoi vous voulez le faire.
    C'est toujours compliqué d'expliquer le pourquoi dans sur un forum. Habituellement les gens lisent une phase sur deux voir aucune quand le post est un peu long.
    Et passent leur temps a essayer de trouver un moyen de pas faire ce qui est demandé ou a critiquer l'approche.


    En gros j'ai un datawarehouse avec des relations entre les tables qui doit rester "potentiellement" cohérent. ( c'est le potentiellement qui est important )
    Un bon 80% des données se trouvent dans la db SQL Server.
    Le 20% qui reste peut être un peu n'importe ou.
    Fichier Excel, autre base de données en tout genre etc...
    Dans ces conditions la PK ou la clé de substitution comme vous voulez l'appeler doit être prédictible sans accéder au datawareHouse d'où le choix des hash qui ont une taille définie.
    De plus l'utilisation de pk prédictible me permet de paralléliser là totalité des chargements ce qui me fait gagner un temps considérable lors chargement.

    Pour plus de détail cherchez DataVault 2.0 sur internet.

    Cordialement

  14. #14
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juillet 2016
    Messages
    2 753
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2 753
    Points : 10 687
    Points
    10 687
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par Donpi Voir le message
    C'est toujours compliqué d'expliquer le pourquoi dans sur un forum. Habituellement les gens lisent une phase sur deux voir aucune quand le post est un peu long.
    Et passent leur temps a essayer de trouver un moyen de pas faire ce qui est demandé ou a critiquer l'approche.
    Ce n'est pas à prendre personnellement. 80% des questions posées ici sur DVP (stat au doigt mouillé par moi) relève d'une mauvaise approche / méconnaissance / autre. Avant d'aborder un sujet complexe, il est donc souvent utile de demander pourquoi avant de dire comment, surtout quand la solution qui en découle est "complexe".

    Le "pourquoi" permet de comprendre la situation, et dans bien des cas, simplifier la solution.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  15. #15
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 449
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 449
    Points : 17 795
    Points
    17 795
    Par défaut
    Citation Envoyé par Donpi Voir le message
    Pour plus de détail cherchez DataVault 2.0 sur internet.
    Ok, je connais un peu DV - j'ai fait du DV 1.0 il y a une dizaine d'année, je sais qu'une des nouveautés de la 2.0 est justement le remplacement des clefs subrogées par des clefs hash.
    DV 2.0 a été pensé dans le cadre d'Hadoop plus que de nos bonnes vielles bases de données SQL.

    Je rajouterai enfin un bémol sur votre architecture DV 2.0 + SQL-Server, qui est vraiment pensé pour une modélisation d'entrepôt de données d'entreprise (Enterprise DWH en anglais dans le texte), et c'est quand même un domaine où SQL-Server ne brille pas du tout.

    J'ai un petit doute sur la compatibilité de ces deux propos :
    - j'ai besoin de calculer un Hash SHA1 pour chaque record de chaque table qui va servir d'identifiant.
    - En revanche la chaine hashée doit avoir un format très précis pour évité les duplicats.
    Si c'est demandé par DV 2.0 pas de soucis bien entendu.

    Si vous restez purement sur SQL-Server, je n'ai pas de meilleures idées par rapport à celles que vous avez déjà évoquées.

Discussions similaires

  1. Avis sur une méthode de rappel ?
    Par Shypster dans le forum C#
    Réponses: 18
    Dernier message: 25/03/2010, 16h38
  2. Avis sur une méthode
    Par sliderman dans le forum Langage
    Réponses: 1
    Dernier message: 19/08/2008, 23h05
  3. Besoin d'avis sur une méthode
    Par g_barthe dans le forum PyQt
    Réponses: 1
    Dernier message: 12/10/2007, 18h54
  4. Avis sur une méthode de gestion d'erreur
    Par mikedavem dans le forum ASP.NET
    Réponses: 4
    Dernier message: 01/08/2007, 20h26
  5. [Conception] Votre avis sur une méthode
    Par AIexis dans le forum PHP & Base de données
    Réponses: 7
    Dernier message: 17/04/2007, 19h08

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