Discussion :

[ManyTwo]

La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".

Dire que mettre la logique métier dans la base est une règle fondamentalement meilleure est un non sens, tout comme dire l'inverse.
Il y a du pour est contre des deux cotés, suivant les projets on va privilégier différentes choses...

Déjà suivant le moteur de base de données, cela peut complètement changer la donne.

Dans mon entreprise actuelle (15aine d'employés), historiquement la logique métier est en BDD (interbase).
Le logiciel principal un ERP spécialisé, gérant des fonctionnements métiers complexes.

Et bien cela commence à poser de sérieux soucis.

De fiabilité du code:
Aucun test automatisé (donc aucune répétition en cas de changement), faire des tests unitaires sur des BDD reste plus compliqué à faire (aucun outil pour Interbase en tout cas).

De performance:
Pourtant à première vue les SGBDR sont optimisés et performants, mettre du code dedans est une bonne idée. Mais ne pas décharger une partie de la logique en amont peut nuire aux performances.
Quand pour des calculs pour arriver à un état final oblige à beaucoup de mises à jour de tables, pour relancer des triggers qui calculent, réécrire n fois les mêmes valeurs et bien on arrive à surcharger la base. Même si les SGBDR optimisent l'I/O et l'accès mémoire.

De scalabilité:
si besoin de répliquer le code métier, notamment la puissance de calcul, pas le choix: il faut faire du load balancing sur la base. Donc réplication. Donc compliqué, surtout lorsque qu'arrive les mises à jours du code métier.

De limitation de code:
Les SGBDR ne sont pas prévus à la base pour la même chose que les language de développement.
C'est complémentaire et non en compétition, comme vous voulez le faire croire. Comment tu gères le mutli threading dans ton code pour faire du calcul parallèle? Peut être qu'oracle a des solutions, la plupart des SGBDR, ou des gens qui font du SQL coderont en procédural mono thread.

Alors bien sur il y a des solutions pour limiter chaque impacte j'imagine, encore faut t'il y avoir des experts BDD qui ont le temps de se pencher sur l'optimisation des procédures de chaque dev etc.

Ici je met en avant certaines contraintes qui nous posent problème, mais il y a beaucoup de points positifs pas de soucis la dessus. Le but est de démontrer qu'il n'y a pas de règle universelle, et surtout qu'il faut arrêter de voir le code BDD et le code logiciel comme des concurrents.

Le but est de trouver un équilibre, qui satisfera les critères importants du projet (pas des équipes, du projet en général hein^^).
La performance? Maintenabilité? scalabilité? Compétences en interne et sur le marché (souvent négligé...)? Fiabilité et intégrité des données (le NoSql montre bien que certains projets ne necessistes pas une intégrité forte)?

[troll /on],Finalement le discours des "pro DB" est aussi limité que celui des "pro logiciel": "C'est mon coté qui est mieux d'abord"! [troll /off]

[kilroyFR]

Personnellement je ne suis pas particulierement pro l'un ou l'autre puisque je travaille sur les 2 niveaux; ce qui me gene plus c'est la tendance naturelle des nouveaux devs (hors BDD) a ne prendre qu'une approche pur logiciel sans regarder si la BDD ne serait pas mieux adaptée dans certaines situations (souvent meme entendu, que SQL c'est compliqué... mais les memes font du Linq en C# avec une syntaxe proche de SQL... va comprendre).

Par exemple on n'utilise pas la BDD pour mettre a dispo des WS (oracle le permet notamment) mais on repousse dans le C# via WS traditionnels (qui peuvent appeler du PL/SQL si la logique de traitement concerne pas mal de traitement de données).

En SOA/micro service on a tendance a faire le contraire chez nous.
Chaque micro service fait une chose simple; par contre toute la logique que tu stockerais dans la BDD et avec les benefices en terme de perfs (les données ne sortent pas de la base), ben tu les perds car les API passent leur temps a faire des lectures/ecritures unitaires sur la BDD (entree/sortie de données via http c'est tres couteux !).
On le vit au quotidien ces derniers temps puisqu'on nous a imposé les micro services.
Resultat, la ou avant on mettait 20 min pour importer un fichier de topologie de reseau + traitement dans BDD (dispatch metier), en micro services (puisque le dispatch metier des données dans les differentes tables du modele), cela prend... 3h ... et on attribue les pbs au reseau, bdd (manque de pot on a la solution precedente qui prouve le contraire).
Pour moi c'est une histoire de curseur à placer au bon endroit.
Autre exemple lorsque Oracle a sorti ses packages pour manipuler du XML, on a essayé mais finalement laisser tomber; pas le role de la BDD de valider des schemas quand c'etait plus simple/adapté de le faire depuis l'appli C# (analyse/parsing puis 'insert into database' betement).
C'est plus cette façon de vouloir generaliser a tout prix qui est destabilisante de nos jours. Comme si la nouvelle techno/nouveau langage allait resoudre tous les pbs.

Concernant les outils de tests unitaires on en utilise sur Oracle (equivalent de NUnit mais en PL/SQL) - il existe du payant et du gratuit qui est largement suffisant.

[aieeeuuuuu]

Bonjour,

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

1/ création d'une appli web en plus/remplacement du client lourd, ou création d'une appli mobile, ou combinaison de tout ça
2/ refonte de l'appli existante souvent dans un autre langage plus à la mode
3/ appli tierce qui doit accéder aux données / appli développée dans un coin pour un besoin marginal, non développée par le SI mais par le stagiaire qui n'est pas forcément informaticien (et même si c'est le cas, quand on voit la formation en SQL dans les cursus informatiques...) et qui ne connait pas la notion de jointure : ça fournit une interface toute prête, ça lui simplifie le travail (pas besoin de comprendre le modéle relationnel) et ça assure au DBA qu'il n'y aura pas de requetes sauvages lancées directement s

Mais selon moi, un des plus gros avantages à mettre la logique métier dans la BDD, c'est qu'ainsi, on maitrise bien mieux les requêtes qui vont être exécutées sur la base. Pour le tunning, c'est un sacré avantage : vous pouvez modifier une requête pour la rendre plus performante sans impacter qui que ce soit. ça évite aussi les requêtes monstrueuses générées par les ORM, pour lesquelles il faut des écrans de 372 pouces. Bref, vous maitrisez tout ce qui rentre et qui sort de la BDD et ça facilite grandement l'administration/optimisation.

Bien sûr, cela demande des compétences en SQL, et s'est souvent là que le bat blesse.

Bien sûr aussi, il ne faut pas être intégriste de cette solution et savoir déporter un traitement lourd, afin d'éviter une charge importante inutile au serveur de BDD qui sont plus difficiles a "scaler-out" que des serveur applicatifs. Je pense à des problématiques couteuses en CPU pour lesquelles le SQL n'est pas forcément le plus adapté, comme des problèmes NP Complets voire des manipulations massives et complexes de chaines de caractères,...

[dfiad77pro]

Ben si, cela s’appelle généralement un domaine SQL et fait partie de la norme. Sur ce point Oracle n'a jamais été bon. Sous SQL Server il suffit d'utiliser les TYPE. Pour les tableaux il y a les variables table...

A +

Tu parle bien des trucs du genre

Code :

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

ma_variable IN shema.table.Colonne%Type

coté oracle?

Ma remarque était basée sur les références de Type de variable, pas sur les Types qui existent biensur coté SQL_server.

[SQLpro]

Visiblement vous êtes à mille lieu des connaissances nécessaire pour aborder un "bon" SGBDR...

Donc reprenons !

La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".

Dire que mettre la logique métier dans la base est une règle fondamentalement meilleure est un non sens, tout comme dire l'inverse.
Il y a du pour est contre des deux cotés, suivant les projets on va privilégier différentes choses...

Je suis d'accord, mais à condition que l'on analyse l'angle d'attaque. Si on ne se soucie pas des performances (jamais, même dans le futur...) alors on peut opter pour la facilité de maintenance du code. Le SQL reste compliqué pour le commun des développeurs, essentiellement parce qu'ils sont mal formé et que le code n'est pas objet.
Et même dans le cas de l'angle des performances, il ne sert à rien d'utiliser un SGBDR si le calcul est unitaire... Un SGBDR manipule un ensemble de données, mais si cet ensemble ne contient qu'une seule donnée, alors c'est comme utiliser une presse hydraulique pour écraser une puce...

Déjà suivant le moteur de base de données, cela peut complètement changer la donne.

Dans mon entreprise actuelle (15aine d'employés), historiquement la logique métier est en BDD (interbase).

Malheureusement Interbase en est a la préhistoire en matière de fonctionnalité de SGBDR... Même MySQL l'a doublé et ne parlons pas de PostGreSQL.... Je m'étonne d'ailleurs toujours de l'utilisation de cet oiseau...

Le logiciel principal un ERP spécialisé, gérant des fonctionnements métiers complexes.

Et bien cela commence à poser de sérieux soucis.

Logique et normal. Son verrouillage est antédiluvien et ses performance guère au dessus d'Access. Son optimiseur est voisin du degré zéro de la chose

De fiabilité du code:
Aucun test automatisé (donc aucune répétition en cas de changement), faire des tests unitaires sur des BDD reste plus compliqué à faire (aucun outil pour Interbase en tout cas).

Encore une fois outil antédiluvien et confidentiel => peu de doc et outils périphériques. Si vous prenez du SQL Server vous trouverez une bonne dizaine d'outils, dont certains sont gratuits ! (SQLTest, SQL Test (je bégaye pas..), Visual Studio Test View, Data Factory, DTM DB Stress...)

De performance:
Pourtant à première vue les SGBDR sont optimisés et performants, mettre du code dedans est une bonne idée. Mais ne pas décharger une partie de la logique en amont peut nuire aux performances.

Je n'ai jamais vu cela... Mais peut être mes 35 années d'expériences ne sont pas suffisantes !

Quand pour des calculs pour arriver à un état final oblige à beaucoup de mises à jour de tables, pour relancer des triggers qui calculent, réécrire n fois les mêmes valeurs et bien on arrive à surcharger la base. Même si les SGBDR optimisent l'I/O et l'accès mémoire.

Il est dommage que vous ne connaissiez pas les vues indexées, le partitionnement, les niveaux d'isolation dynamique, les index verticaux, la compression de données...

De scalabilité:
si besoin de répliquer le code métier, notamment la puissance de calcul, pas le choix: il faut faire du load balancing sur la base. Donc réplication. Donc compliqué, surtout lorsque qu'arrive les mises à jours du code métier.

En plus de 20 ans d'utilisation de SQL Server je n'ai vu qu'une seule base de plusieurs dizaines de To en 2000 qui avait nécessité une scalabilité horizontale. Aujourd'hui la dizaine de To est monnaie courante et le 100 To de données en 1 seule base ça existe... Pour info les sites suivants utilisent des bases de plusieurs dizaines de To : fnac.com, ventes privées, cdiscount, sarenza... pour ne citer que les plus visibles.
De plus SQL Server est doté de 6 mécanismes différents de réplication/répartition de données (je parle bien de données de tables et non pas de bases entières) et de 2 mécanismes de réplication des bases entières :
1) réplication des données :

• Transactionelle
• Snapshot
• fusion
• Peer to peer
• Service broker
• Data Partitionned View

2) réplication des bases :

• Log Shipping
• AlwaysOn

Il est certain que si vous vous êtes cantonné à FireBird, vous êtes passé à côté d’à peu près tout.

De limitation de code:
Les SGBDR ne sont pas prévus à la base pour la même chose que les langage de développement.
C'est complémentaire et non en compétition, comme vous voulez le faire croire. Comment tu gères le mutli threading dans ton code pour faire du calcul parallèle?

Cela existe nativement dans SQL Server depuis la version 7 (1999). Toute requête dépassant un certain seuil est parallélisé. Le développeur n'a heureusement rien à faire.. le "In Memory" à d'ailleurs accentué cette utilisation du parallélisme...

Peut être qu'oracle a des solutions, la plupart des SGBDR, ou des gens qui font du SQL coderont en procédural mono thread.

Effectivement Oracle à un module payant en supplément et fort cher appelé Parallel Query....

Alors bien sur il y a des solutions pour limiter chaque impacte j'imagine, encore faut t'il y avoir des experts BDD qui ont le temps de se pencher sur l'optimisation des procédures de chaque dev etc.

Pour cela certains SGBDR offrent des outils qui facilitent grandement la chose. Par exemple dans SQL Server il existe des vues système pour obtenir toutes les métriques de performances sur toutes les requêtes, procédures triggers et fonction de façon à débusquer très vite les coupables...

Ici je met en avant certaines contraintes qui nous posent problème, mais il y a beaucoup de points positifs pas de soucis la dessus. Le but est de démontrer qu'il n'y a pas de règle universelle, et surtout qu'il faut arrêter de voir le code BDD et le code logiciel comme des concurrents.

Le but est de trouver un équilibre, qui satisfera les critères importants du projet (pas des équipes, du projet en général hein^^).

C'est bien là le problème

La performance? Maintenabilité? scalabilité? Compétences en interne et sur le marché (souvent négligé...)? Fiabilité et intégrité des données (le NoSql montre bien que certains projets ne necessistes pas une intégrité forte)?

Le plus important c'est la formation. La plupart des développeurs sont déformés et incompétents. Alors ils utilisent ce qu'il connaissent au détriment du mieux qu'ils ne connaissent pas. C'est comme cela que l'on en arrive au NoSQL avec des projets inadaptés....

[troll /on],Finalement le discours des "pro DB" est aussi limité que celui des "pro logiciel": "C'est mon coté qui est mieux d'abord"! [troll /off]

Je suis d'ailleurs toujours étonné quand je passe dans des entreprises ou je fais du conseil, du peu de cas que font les développeurs des outils mis à leur disposition.
Par exemple, récemment allant dans le service informatique d'une entreprise de pointe en métallurgie, montrer aux développeur que plus de 50% du code qu'ils avait fait, était réalisé nativement par SQL Server en nettement mieux et plus performant... Exemples : historisation automatique des versions de données, audit de l'accès aux données, intégration du XML...

A +

[SQLpro]

Tu parle bien des trucs du genre

Code :

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

ma_variable IN shema.table.Colonne%Type

coté oracle?

Ma remarque était basée sur les références de Type de variable, pas sur les Types qui existent biensur coté SQL_server.

Le type est un typage.

Il te suffit de faire un CREATE TYPE toto AS ... et de l'utiliser aussi bien pour tes colonnes de table que pour tes variables procédurales.

Si vous utilisez un outil de modélisation comme Power AMC et que vous passez par les domaines SQL, c'est ce qu'il fera....

A +

[SQLpro]

Autre exemple lorsque Oracle a sorti ses packages pour manipuler du XML, on a essayé mais finalement laisser tomber; pas le role de la BDD de valider des schemas quand c'etait plus simple/adapté de le faire depuis l'appli C# (analyse/parsing puis 'insert into database' betement).

Oracle a été très mauvais sur ce coup... Ils ont du s'y reprendre à 3 fois pour arriver à un résultat tout juste potable.
Bref, les gens qui ont utilisé les premières versions ont toutes été dégoutées...
En sus, ils sont succombé à la norme SQL, qui, sur la chose, a été très mauvaise en réinventant la roue. Je m'explique... Au lieu d'utiliser directement YQuery et XPath ils ont inventés différentes fonctions (XMLFOREST, XMLAGG...) toutes plus imbitables les unes que les autres...

SQL Server n'est pas tombé dans ce travers et a utilisé directement le standard XQuery et XPath... Et les performances sont là !
Aujourd’hui il est plus rapide de parser des masse de doc dans SQL Server que de faire des moulinettes en C# ou Java...

A +

[jpouly]

C'est pas trolldi, mais bon .

Généralement, les éditeurs de bases de données vous expliquent que mettre la logique métier dans des procédures stockées, c'est bien.
Ils savent bien que pour changer de produit (c'est à dire aller à la concurrence), ça nécessite des doubles compétences et une requalification complète des applications.
Donc des couts trop importants, par rapport au gain espérer (c'est à dire le prix des licences).

Souvent, les développeurs ne comprennent rien à SQL, ne savent pas concevoir une base de données et pensent que MERISE c'est plus très frais (comme dise les jeunes ).
Et font de gros yeux ronds quand on leurs parle de volumétrie .

C'est sure qu'un Hybernate ou un Entity Framework, ça masque un peu la misère. Par contre quand on regarde les requêtes générées, c'est la catastrophe. Surtout avec des bases volumineuses.
Et puis le mapping verticale (1 table, 1 objet), c'est pas forcement la bonne idée.

Comme souvent en informatique, la solution va dépendre de la complexité du fonctionnelle et de son évolution dans le temps, de la volumétrie des données à traiter, des IHM et des éditions.

[martopioche]

Dans le genre de derive entre des devs orientés BDD et les autres, le cas du JSON. Dans le genre des dernieres demandes : passer a MongoDb car 'on n'a pas a s'emmerder a definir des structures fixes et en plus on stocke le json tel quel depuis le C#; y a rien a faire'...
Voila le genre de comportements qu'on doit subir ces dernieres années.

Ouiii !!!
Et le temps qu'on perd à rappeler que le No de NoSQL ne signifie pas No mais Not Only… Là faut attendre que l'interlocuteur récupère du segmentation fault que vient de faire le cerveau…

C'est malheureusement cette seconde ecole qui, ramenant avec elle tout un vocabulaire 'sexy' pour des managers, a le vent en poupe. Si c'est pas malheureux...

Ce n'est pas que le vocabulaire mais également une promesse de gain d'efficacité avec comme preuve que l'usage actuel ne marche pas. Le tout appuyé par le fait que tout le monde en parle et que les références disent qu'ils le font (Facebook gère ses données en NoSQL, Nokia a publié un rapport comme quoi Scrum marche trop bien, le consultant nous a dit de…)

P.s. je met des smiley , mais c'est bien parce que je m'en suis éloigné, lorsqu'on est dedans,

Y'a aussi un peu les temps de dev ridicule qu'on nous alloue parfois :


Par exemple coté .NET , coder une requête complexe avec Entity Framework est beaucoup plus rapide que de :

- Créer les types complexe oracles/sql server et la procédure stockée

Rien que sur ce point là, on est d'accord que c'est volontairement que vous vous mettez le couteau sous la gorge. Car pour le projet suivant de l'autre équipe qui fait du Java, on est d'accord que vu qu'ils utilisent le même "type complexe" que vous, vous avez déjà la partie en base, je n'ai qu'à chiffrer la partie définition de l'objet et mapping et leur imposer un délais en conséquence…

- on se retrouve vite avec des packages très volumineux genre 5000 lignes de code la ou les normes java /C# demandent de séparer en classe de 1000 lignes grands max.

J'aime bien cette norme… "Grand max"… Donc il doit y avoir un "petit max", il est de combien ? Et pourquoi le grand plutôt que le petit ?
Et puis bon, grand max, si j'en suis à 1001, ah bah plus haut là où j'ai décomposé en 5 appels de méthodes, en fait, je peux faire du one liner à la Perl… Et pas que là, oué…

Développer en objet poussent à développer la partie métier sur la couche client car "normalement ", on peut attaquer différentes Bases de données.

Je ne vois pas le rapport entre "développer en objet" (ça veut dire quoi ? Développer en créant des objets comme avec Java ? Développer selon les principes de la POO ? ) et le fait de pouvoir ainsi "attaquer différentes bases de données". En procédural ou fonctionnel, ce n'est pas possible à envisager ?

Et "on peut"…*Mais est ce que dans la pratique tu a plus de projets qui ont plusieurs applicatifs nécessitant la même base de données ou plus de projets qui nécessitent plusieurs bases d'éditeurs différents (car sinon, tu déploie la même procstock/schéma/contraintes/vues sur les différentes du même éditeur) ayant le même schéma ?

2/ normes de codage c'est souvent fortement inspiré des regles de codage du fournisseur du langage (avec d'eventuelles adaptations; genre prefixer les noms de variables etc en fonction des regles dans l'entreprise).

J'aurai tendance à dire que ça vient surtout du suivi des modes… Et de l'historique de la boite. Quand on voir comment la PEP8 de Python est accueillie dans les boites où beaucoup de normes sont en contradiction…

[martopioche]

La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".

Mais toute cette discussion résulte de querelles de chapelles (db/dev) et le plus généralement de devs qui défendent le "tout logiciel" (parce qu'il est plus courant d'avoir des devs que des dba).

Dire que mettre la logique métier dans la base est une règle fondamentalement meilleure est un non sens, tout comme dire l'inverse.

J'estime que la règle de base est que la BDD est la garante de la cohérence des données. Cette cohérence est définie par le métier et la définition de cette cohérence est une partie du métier. Ne pas déléguer à la BDD la gestion de la cohérence (cf par exemple les ORMs avec l'intégrité référentielle) est un non-sens. Pour le reste du métier, on se rejoins.

Pourtant à première vue les SGBDR sont optimisés et performants, mettre du code dedans est une bonne idée. Mais ne pas décharger une partie de la logique en amont peut nuire aux performances.

Ce qui est intéressant, c'est que régulièrement, cette critique vient d'une mauvaise stratégie d'accès à la base…

Alors bien sur il y a des solutions pour limiter chaque impacte j'imagine, encore faut t'il y avoir des experts BDD qui ont le temps de se pencher sur l'optimisation des procédures de chaque dev etc.

Même sans aller jusqu'aux cas "extrêmes", une compétence BDD (plus poussée que savoir installer MySQL et un ORM) est toujours indispensable…

il faut arrêter de voir le code BDD et le code logiciel comme des concurrents.

Le but est de trouver un équilibre, qui satisfera les critères importants du projet (pas des équipes, du projet en général hein^^).

Malgré mes quelques remarques :

En SOA/micro service on a tendance a faire le contraire chez nous.
Chaque micro service fait une chose simple; par contre toute la logique que tu stockerais dans la BDD et avec les benefices en terme de perfs (les données ne sortent pas de la base), ben tu les perds car les API passent leur temps a faire des lectures/ecritures unitaires sur la BDD (entree/sortie de données via http c'est tres couteux !).
On le vit au quotidien ces derniers temps puisqu'on nous a imposé les micro services.
Resultat, la ou avant on mettait 20 min pour importer un fichier de topologie de reseau + traitement dans BDD (dispatch metier), en micro services (puisque le dispatch metier des données dans les differentes tables du modele), cela prend... 3h ... et on attribue les pbs au reseau, bdd (manque de pot on a la solution precedente qui prouve le contraire).
Pour moi c'est une histoire de curseur à placer au bon endroit.

Pour un problème similaire, Google a su imposer la bonne pratique sur AppEngine : ils ont augmenté la tarification des lectures/écritures… C'est dingue comment un dev peut être inventif quand on ajoute le paramètre du portefeuille…

C'est pas trolldi, mais bon .
Généralement, les éditeurs de bases de données vous expliquent que mettre la logique métier dans des procédures stockées, c'est bien.
Ils savent bien que pour changer de produit (c'est à dire aller à la concurrence), ça nécessite des doubles compétences et une requalification complète des applications.
Donc des couts trop importants, par rapport au gain espérer (c'est à dire le prix des licences).

Et quand un éditeur de logiciel te vends la logique métier en code, le principe est le même, ce qui est critique est emprisonné dans une techno que tu ne changera pas au risque de remettre en cause la fiabilité de ton système. Et plus généralement, c'est valable pour tout (vu pour les ESBs aussi…)

Et puis le mapping verticale (1 table, 1 objet), c'est pas forcement la bonne idée.

Alors celle-là, en effet, c'est l'idée la plus stupide dans un projet… Un objet est une entité de traitement, une table une entité de stockage de donnée. On devrait pouvoir virer pour faute grave celui qui pense que c'est la même chose.[/QUOTE]

[dfiad77pro]

Rien que sur ce point là, on est d'accord que c'est volontairement que vous vous mettez le couteau sous la gorge. Car pour le projet suivant de l'autre équipe qui fait du Java, on est d'accord que vu qu'ils utilisent le même "type complexe" que vous, vous avez déjà la partie en base, je n'ai qu'à chiffrer la partie définition de l'objet et mapping et leur imposer un délais en conséquence…

C'est triste mais dans certains projets/contextes, on ne peut pas imposer un chiffrage. Lorsque tu chiffres 2 semaines et qu'on t'en donne qu'une, ben la qualité de conception s'en ressent.

C'est un des aspect qui m'énerve le plus dans mon métier: quand on sait qu'on se met un couteau sous la gorge et qu'on va le regretter plus tard, mais qu'on a pas le choix.

[SQLpro]

Alors celle-là, en effet, c'est l'idée la plus stupide dans un projet… Un objet est une entité de traitement, une table une entité de stockage de donnée. On devrait pouvoir virer pour faute grave celui qui pense que c'est la même chose.

Ben là il n'y aurait plus aucun développeur !!!!

A +

[SQLpro]

C'est triste mais dans certains projets/contextes, on ne peut pas imposer un chiffrage. Lorsque tu chiffres 2 semaines et qu'on t'en donne qu'une, ben la qualité de conception s'en ressent.

C'est un des aspect qui m'énerve le plus dans mon métier: quand on sait qu'on se met un couteau sous la gorge et qu'on va le regretter plus tard, mais qu'on a pas le choix.

On a toujours le choix de quitter la boite !
C'est ce que j'ai fait toute ma carrière (10 boites avant de créer la mienne) et je m'en porte plus que bien... Parfois je n'ai été là qu'un petit mois...

A +

[martopioche]

C'est triste mais dans certains projets/contextes, on ne peut pas imposer un chiffrage. Lorsque tu chiffres 2 semaines et qu'on t'en donne qu'une, ben la qualité de conception s'en ressent.

C'est un des aspect qui m'énerve le plus dans mon métier: quand on sait qu'on se met un couteau sous la gorge et qu'on va le regretter plus tard, mais qu'on a pas le choix.

Si tu parle du point de vue du dev, des boites qui imposent des délais incohérents avec l'attente, perso, je n'y ai jamais fait long feu.

Mais ma remarque était coté "client" et surtout client contractuel. Pour ma part, il faudra m'expliquer longtemps lors d'une évolution pourquoi "vous" me factures une seconde fois ce qui a été fait la première…

Ben là il n'y aurait plus aucun développeur !!!!

Je n'appelle pas cette catégorie de salariés des "développeurs".

[dfiad77pro]

Je ne suis pas en SS2I, mais dans un grosse boite qui paye bien, heureusement ce genre de soucis est périodique et pas permanent, sinon je partirai rapidement

[martopioche]

Je ne suis pas en SS2I, mais dans un grosse boite qui paye bien, heureusement ce genre de soucis est périodique et pas permanent, sinon je partirai rapidement

Je n'ai pas parlé SSII. Quelle que soit la boite, le dev travaille pour un client, qu'il soit externe ou interne (soit une autre BU soit un autre service).

[ManyTwo]

J'espere qu'il n'est pas trop tard pour continuer la discution (que je trouve intéressante), je n'étais pas trop disponible avant.

Un petit apparte:

Par contre je ne suis pas la pour rentrer dans le jeu de "c'est qui qui a la plus grosse", donc les reflexion du type

Visiblement vous êtes à mille lieu des connaissances nécessaire pour aborder un "bon" SGBDR...

on va éviter. Je ne m'occupe pas personnellement du développement métier coté DB, mais il y a des gens qualifiés qui le font, qui ont une approche orienté DB.
Les optimisations sont faites (autant que possible sur interbase ), les requêtes "contraignantes" sont optimisés par des personnes ayant plus de 25 ans de SQL dans les pattes.

SQLpro le fait d'être rédacteur, avoir "35 ans d'expérience", ne vous a pas appris à avoir un ton légèrement moins condescendant? Entre la citation précédente, ainsi que toutes celles sur les développeurs dans cette discution, je ne comprend pas comment vous comptez faire entendre votre point de vue au gens que vous souhaité "éduquer". On est en plein dans ce que je décrivais: "C'est mon coté le mieux, les autres sont des amateurs". On est pas près d'avancer.

Justement pour moi le but de cette discussion, était de trouver de façon objective quels sont les atouts problèmes des différentes solution, et j'espérais trouver des gens qui ont de l'expérience dans les divers domaines concernés. Après si d'entré ca part sur "Non, il n'y a aucune contrainte sur tel ou tel façon de faire, on devrai TOUJOURS faire cela", désolé je vous ai dérangé pour rien ce n'est pas ce que j'attendais.