+ Répondre à la discussion Actualité déjà publiée
  1. #121
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    _skip m'ôte les mots de la bouche.

    Citation Envoyé par loicmidy Voir le message
    autre question : le refactoring de code java sous éclipse avec les outils d'aide au refactoring je connais. Comment est ce que je fais la même chose en PL SQL?
    Si tu as un IDE qui le permet, donne-moi vite le nom, 'fin vite... pas trop non plus : le besoin de refactoring du code PL/SQL est bien moins important qu'en Java, par exemple.

  2. #122
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut

    Citation Envoyé par _skip Voir le message
    Pourtant sa réponse est juste...

    Le test unitaire finalement c'est quoi? Exécuter une opération et vérifier qu'elle produit les résultats attentdus dans diverses circonstances.
    Il est clair que ce n'est pas junit qui les a inventé pour ne citer que lui, ça se faisait bien avant.

    Tu peux tester unitairement une procédure stockée au moyen d'une autre procédure stockée de test, la deuxième déclenchant la première et testant sa valeur de retour avec un RAISE ERROR.
    Tu te fais un gros script de test ainsi, c'est largement faisable...

    Donc c'est entièrement possible à faire, et je suppose que ça s'est toujours fait peu importe le langage.

    Dans les IDE modernes, tu as la prise en charge avec les lumières vertes comme disait dingoth et le support out-of-the-box d'un framework (nUnit, Junit, phpUnit) qui te simplifie la vie. Mais ce n'est que de l'intégration, même si c'est vrai que c'est très confortable et facilement utilisable.
    d'accord, moi je connais bien JAVA et très peu le PL SQL.

    cependant, ta réponse reste partielle. Le problème est plus compliqué que celà :
    1 : souvent on utilise Junit avec une librairie de mock pour créer des bouchons de données : on fait comment en PL SQL? faire les mocks à la main : celà doit être possible , n'est ne pas pénible?
    2: tu dis Tu te fais un gros script de test ainsi, c'est largement faisable... et celà me met la puce à l'oreille : et la maintenabilité? et la factorisation du code?
    3 : lorsqu'on fait des tests unitaires en JAVA il est recommandé de faire peu de tests tapant sur la BDD (c'est pourquoi on fait des mocks) ce qui permet de faire tourner très rapidement tous les tests unitaires. A quelle vitesse tourneront ils en PL SQL?

    J'ai une autre question : les développeurs JAVA essayent de faire l'effort de faire des tests unitaires propres et maintenables : on trouve de nombreux livres et retours d'expérience sur ce sujet.
    est ce que les développeurs PL SQL font le même effort? Y a t il des livres sur ce sujet?

    Est ce que vous avez des retours d'expériences sur le codage de tests type unitaires en PL SQL?

    Pour vraiment aller au fond du sujet il faudrait coder une petite application des 2 façons (JAVA versus PL SQL) et leurs tests unitaires associés puis comparer.


    en ce qui concerne le refactoring en JAVA : il y a de nombreuses options de refactoring dans eclipse. c'est expliqué par exemple dans le livre Refactoring des applications Java/J2EE de Jean-Philippe Retaillé (dans la biblio sur ce site).

  3. #123
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Oui, on fait des tests de type unitaire. En gros, comme _skip l'a dit, on crée un gros script de test, et on implémente ensuite. Cependant, implémenter la méthodologie XP en PL/SQL est plutôt difficile, car il n'existe pas d'outils comme xUnit ou Mock (d'ailleurs, le mocking n'est pas tout à fait nécessaire dans le contexte PL/SQL, si tu y réfléchis davantage).


    Pourquoi voudrais-tu comparer les deux technologies ? La première chose qu'il faut savoir, c'est que leur but est différent. L'un est la création d'applications utilisables par le client, l'autre est la gestion des données utilisées par l'application. Cela revient à comparer des pommes et des poires. Les langages SQL (pas que PL/SQL) n'ont pas la prétention de vouloir prendre le rôle de Java, et inversément (quoique certains développeurs d'API pensent que ce ne seraient pas une mauvaise idée dans le sens "tout java, pas de SGBD").

    En ce qui concerne le tests du côté SGBDR, pas de souci de perfs, puisqu'on reste dans la base de données. Cela me semblait... évident.


    Quant à la refactorisation, tu verras que la plupart du temps, les gars qui développent pour une BDD, s'ils ont bien appris leur métier, passent parfois des jours à créer les interfaces (et uniquement les interfaces) d'accès aux données. Donc, le besoin en refactorisation est bien moins nécessaire.


    Enfin, je suis content de voir combien tu sembles enthousiastes à vouloir créer un SQLUnit

  4. #124
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut

    [QUOTE=dingoth;4871427]
    Pourquoi voudrais-tu comparer les deux technologies ? La première chose qu'il faut savoir, c'est que leur but est différent. L'un est la création d'applications utilisables par le client, l'autre est la gestion des données utilisées par l'application. Cela revient à comparer des pommes et des poires. Les langages SQL (pas que PL/SQL) n'ont pas la prétention de vouloir prendre le rôle de Java, et inversément QUOTE]

    les 2 technos sont parfois en concurrence. J'ai le cas au travail (je fais de l'informatique à l'INSEE). Nous développons notamment de nombreux batchs réalisant des traitements statistiques complexes et parfois sur de gros volumes de données (i.e : 30/40 millions de lignes). Pour ces batchs j'ai 2 technos en concurrence :
    PL SQL versus JAVA avec Hibernate.
    Nous avons développé avec succès dans les 2 technos. Cependant pour le moment pour les batchs travaillant sur les plus gros volumes de données on est resté au PL SQL : on ne sait pas trop si avec JAVA/hibernate on aurait eu des performances acceptables (on a souvent des deadlines serrées et on n'a pas le temps de développer de 2 façons différentes puis de comparer).

    Mon point de vue temporaire (je peux changer d'avis) est le suivant :
    je prone la solution JAVA avec Hibernate et je cherche donc à éradiquer le PL SQL sauf si c'est justifié pour des raisons de performances.

  5. #125
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Attention, il faut différentier les traitements "non batch" (transactionnel) et les traitements "batch". Un modèle "pur objet" qui va bien fonctionner pour du mode transactionnel peut s'avérer totalement inopérant dans le contexte d'un traitement batch. La raison est que dans le transactionnel, on fait essentiellement des accès à un objet (on va dire une ligne dans une table) et de la navigation entre objets (requêtes "simples" avec jointure). Dans le cas du batch on est souvent amené à faire des requêtes "ensemblistes" qui sont donc "transverses" aux objets. Dans ce contexte, on a bien souvent des requêtes complexes qui tapent sur plusieurs tables avec en plus la problématique de la volumétrie.
    Donc dans le cas du batch, le mapping objet/table de la partie transactionnelle de l'application n'est pas forcément adapté. Il faut donc parfois passer par un autre mapping voir faire des requêtes SQL "à la main" ou pire () faire du PL/SQL. C'est pourquoi, il y a des gens qui cherchent à faire "monter le SQL" dans la couche objet pour pouvoir faire des requêtes ensemblistes sur des objets en mémoire. On attend toujours les perfs, à ma connaissance, sur ce type de problématique.

  6. #126
    Membre expérimenté Avatar de chaplin
    Profil pro
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 605
    Points
    1 605

    Par défaut

    +1
    Tout est dit.

  7. #127
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut informatique opérationnelle versus décisionnelle

    Citation Envoyé par ego Voir le message
    Attention, il faut différentier les traitements "non batch" (transactionnel) et les traitements "batch". On attend toujours les perfs, à ma connaissance, sur ce type de problématique.
    j'ai continué à réfléchir au sujet.
    En fait je pense qu'il faut plutôt différentier :
    d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
    d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

    cordialement
    loïc midy

  8. #128
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par loicmidy Voir le message
    j'ai continué à réfléchir au sujet.
    En fait je pense qu'il faut plutôt différentier :
    d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
    d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

    cordialement
    loïc midy
    Peu importe les termes mais tu as raison. Il faut adapter la solution en fonction des besoins et il est clair que pour le moment quand on a des traitements ensemblistes et que l'on peut résoudre ça en faisant des requêtes complexes en SQL, pas de soucis, c'est ça la solution. Il y a aussi la possibilité de ne pas utiliser le même schéma pour les 2 mondes et donc faire des transformations de l'un vers l'autre = dénormaliser, regrouper, trier,...
    Il y avait sur jakarta un framework "SQL like" pour Java mais je ne me souviens plus du nom et je ne sais pas ce que cela vaut et si c'est aussi puissant que le SQL et certaines fonctions SQL spécifiques des SGBDR.

    Ah, j'ai trouvé, c'est JXPath (donc XPath et non SQL !!) mais je ne l'ai jamais essayé

  9. #129
    Membre actif
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    206
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2010
    Messages : 206
    Points : 269
    Points
    269

    Par défaut

    Citation Envoyé par loicmidy Voir le message
    j'ai continué à réfléchir au sujet.
    En fait je pense qu'il faut plutôt différentier :
    d'une part l'informatique opérationnelle (ou de gestion : il semble y avoir plusieurs terminologies). Chez nous c'est souvent une application web J2EE et les utilisateurs font de nombreuses mises à jour dans la base de données. Dans ce cas je pense qu'il vaut mieux mettre le métier dans la couche JAVA puis utiliser un framework ORM. La BDD ne sert alors que de réceptable pour faire persister les données.
    d'autre part l'informatique décisionnelle. Chez nous, nous avons notamment de gros traitement batchs de calculs statistiques sur des millions de lignes avec par exemple souvent des opérations d'agrégation. Dans ce cas faire du SQL avec un lanceur de code en JAVA ou faire du PL SQL est plus rapide et plus efficace que de coder le tout en JAVA et utiliser un framework ORM. Par exemple, nous développons actuellement un batch utilisant par ex la fonction group by rollup et la BDD a une modélisation en étoile. Du coup, pas de framework ORM pour ce batch.

    cordialement
    loïc midy
    Le monde décisionnel ou datawarehouse est effectivement très à part (pour avoir eu l'occasion d'y toucher au travers de BO ou SAPBW). Compte tenu des énormes volumes de données, il est clair qu'on ne fait plus dans le purisme du relationnel, qu'il y a de multiples redondances, bref ça ressemblerait presque à de gigantesques feuilles de tableur

    A fortiori utiliser de l'ORM sur du décisionnel serait du suicide.

  10. #130
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Sans vouloir mettre de l'huile sur le feu, les univers bo sont aussi dangereux voir plus qu'un. Il n'y a pas fondamentalement de diff a opérer : il faut choisir la bonne techno et en avoir les bons usages.
    L'échec de la bi est d'ailleurs le même souvent que celui de l'orm : une vision technocratique mono disciplinaire.

  11. #131
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 611
    Points : 38 491
    Points
    38 491

    Par défaut

    Citation Envoyé par loicmidy
    Citation:
    Envoyé par Voir le message
    il n'y a pas eu de réponse à ce post avec lequel je suis en accord.
    je relance : comment on fait un test unitaire si on gère le métier dans la base de données avec par ex du PL SQL?
    Citation Envoyé par ego Voir le message
    ah oui, bonne question ..........on fait comment les experts en base de données et en conception ?
    Je sens que ça va se corser
    C'est d'un simplicité enfantine.
    Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
    Il est alors d'une simplicité biblique de les tester unitairement...

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  12. #132
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    C'est d'un simplicité enfantine.
    Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
    Il est alors d'une simplicité biblique de les tester unitairement...

    A +
    Enfantins si on a besoin que de crud...et ce sont des tests inutiles.
    L'onjet apporte au moins le mocking, car la difficulté des tests ce n'est pas le langage mais le contexte et les données.
    Mettre les tests dans la base c'est une erreur grossiére de conception, puisque dans le cas d'une application, beaucoup de données spécifiques sont dans la base. Le but du jeu d'un test, c'est bien justement d'éprouver la qualité des algorithmes métiers indépendamment de la spécialisation des données.

  13. #133
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 282
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 282
    Points : 2 558
    Points
    2 558

    Par défaut

    Citation Envoyé par B.AF Voir le message
    ... L'onjet apporte au moins le mocking ...
    Et en français ça veut dire quoi ?

  14. #134
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Citation Envoyé par B.AF Voir le message
    L'objet apporte au moins le mocking, car la difficulté des tests ce n'est pas le langage maisle contexte et les données.

    Mettons qu'avec Java, tu aies les instructions A, B et C. Ton contexte est l'ensemble A, B et C dans cet ordre. Ton test unitaire ne voudrait rien dire si tu testais C tout seul, mais tu le fais quand même.

    En base de données, c'est pareil, on peut également écrire A, B et C sans souci et créer des tests pour chacun d'eux, et ensuite créer un test pour A, B et C ensemble. Le mocking sera moins évident pour tester B individuellement, mais avec le contexte A et C autour, tout cela deviendra cohérent. Aussi.

  15. #135
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Et en français ça veut dire quoi ?
    Que j'ai un handicap à la main droite qui fait que je peux faire des fautes de frappe. Heureux ceux qui possédent les deux.

  16. #136
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Mettons qu'avec Java, tu aies les instructions A, B et C. Ton contexte est l'ensemble A, B et C dans cet ordre. Ton test unitaire ne voudrait rien dire si tu testais C tout seul, mais tu le fais quand même.

    En base de données, c'est pareil, on peut également écrire A, B et C sans souci et créer des tests pour chacun d'eux, et ensuite créer un test pour A, B et C ensemble. Le mocking sera moins évident pour tester B individuellement, mais avec le contexte A et C autour, tout cela deviendra cohérent. Aussi.
    Ok, ça je comprends. Dans la partie conception, si tu découpes avec une bonne granularité tes données, tu pourras obtenir le bon résultat. Mais c'est difficile d'abstraire les données. Notamment dans le cas où l'algorithme est basé sur des critères particuliers ou des règles paramétrables.

    Injecter des données de test dans des procédures SQL est difficile et ça coute très cher en tests. En rapport à l'objet où le mocking est plus simple et la dépendance de données moins problèmatique-->que l'objet soit hydraté d'une base ou pas n'influe pas sur le comportement d'une méthode.

  17. #137
    Membre chevronné
    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    D'ailleurs je voulais juste parler de Fluent Nhibernate, qui est un framework permettant de gérer les mappings au travers d'une interface fluide.

    Pas qu'il soit révolutionnaire dans ce qu'il apporte, mais il met en exergue quelque chose d'intéressant de de méconnu et sous utilisé dans les ORM :
    - Le contrôle de cohérence du mapping
    ici
    - La définition de conventions
    ici

    C'est à dire que si nous considérons un pattern de type unit of work avec un data access layer, le dba et le développeur peuvent se mettre d'accord de telle façon que la traduction relationnellle du modèle objet soit conforme aux exigences du dba. Cela permet donc de réunir les deux compêtences simplement.

  18. #138
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    C'est d'un simplicité enfantine.
    Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
    Il est alors d'une simplicité biblique de les tester unitairement...

    A +

    Est-ce que ce que tu veux dire c'est que finalement, les drivers ODBC ou JDBC (en ne prenant que cela) ne servent finalement à rien. Les éditeurs ne devraient offrir que l'exécution de procédures stockées et pas d'ordres SQL ?
    L'ensemble de l'industrie se serait donc trompé sur les outils mis à disposition des développeurs ?

    J'ai bien compris ta position ?

  19. #139
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    Non : tu extrapoles à partir de peu.

  20. #140
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Mais SQLPro il dit quoi lui ?

Discussions similaires

  1. Les IDE sont-ils dangereux pour les développeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 85
    Dernier message: 13/05/2014, 12h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 20h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 09h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 09h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 24/11/2008, 00h13

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