Discussion :

[CinePhil]

En terme d’application, je maintiens moi aussi qu’en avoir une dizaine ou plus au même endroit est une mauvaise idée, d’autant plus si elles sont développées indépendamment.

Devons-nous comprendre que, pour vous, l'application et la base de données sont sur le même serveur ?

Il est vrai que si votre domaine de compétence est principalement Access, c'est peut-être le cas.

Vous savez quand même que ce n'est largement pas le cas de toutes les applications d'entreprises ou d'organismes publics, quand même ?

Dans notre relativement petit établissement public, nous avons :
- un serveur Oracle de production, contenant quelques dizaines de schémas pour toutes les données de gestion ;
- un serveur de production pour l'ERP ;
- un serveur Oracle de test qui contient plusieurs copies de la base de prod ;
- deux serveurs pour tests et formations sur l'ERP ;
- deux serveurs MySQL pour les données des applications annexes, les données des sites web... ;
- plusieurs serveurs pour les sites webs et applications annexes.

Les cas où l'application et la BDD sont sur le même serveur sont rares. C'est notamment le cas pour l'application de notre CDI qui a des BDD trop grosses et qui posaient des soucis quand elles étaient sur le serveur MySQL central.

[SQLpro]

En effet pas de clé étrangère entre la table produit (donc dans la base « master data ») et une application X utilisant des produits.

Pour votre information, l'absence d'une telle contrainte est une catastrophe à de nombreux niveaux du fait de la présence de lignes orphelines... Cela conduit à :

• des données fausses (par exemple des statistiques sur des lignes orphelines, du rajustement de stock qu'il n'y a pas lieu de faire) donc, des pertes économiques pour l'entreprise
• des performances en baisse (des lignes orphelines => du volume inutile dans la maintenance, les sauvegardes... et en sus des plans de requêtes moins bien optimisés => les optimiseurs des grands SGBDR savent tirer partit de toutes les contraintes exprimées dans le modèle pour simplifier les requêtes afin de livrer des résultats plus rapidement
• ...

Je comprends que ça puisse causer une syncope dans une salle de cours, mais si c’est le seul point qui vous fait réagit dans mon précèdent message et que le rapport positif/négatif ne vous saute pas aux yeux, je ne sais pas trop ce qu’il vous faut.

Je suis loin d’avoir un point de vue arrêté (ces questions évoluent beaucoup trop rapidement pour ca) donc si vous avez des solutions à partager concernant les problèmes que j’ai énoncés, je serais heureux d’en débattre et pourquoi pas d’adopter votre point de vue. Maintenant la BDD unique ça me parait quand même bien loin de ce que des professionnels devraient recommander en 2017 (à part bien sur si, comme je l’ai dit, les applications ont vocation à rester minuscules).

Le professionnel que je suis ne recommande pas systématiquement le monobase ou mono serveur, mais je constate la plupart du temps les dégâts occasionné par l'éclatement en différentes bases et serveurs des informations....

C’est invariablement le genre d’explications qui mènent aux problèmes cités plus haut. Le manque d’anticipation.

Nous sommes d'accord, encore faut-il mettre ses connaissances à jour !

A +

[SQLpro]

Pour votre information, lisez l'article que j'ai écrit à ce sujet :
https://blog.developpez.com/sqlpro/p...ou_plusieurs_1

A +

[SQLpro]

SQL Pro, ressaisissez-vous et concentrez-vous sur le sujet initial s’il vous plait. Je suis en effet un expert en Access (et aussi toutes les autres merdes du genre) ce qui semble engendrer chez vous un sévère complexe d’infériorité.
Je prépare à ce propos un livre chez Eyrolles que je me ferais un plaisir de promouvoir à chacune de vos interventions erronées sur Access (en incluant à chaque fois la couverture en pleine page). Ou alors je vous expliquerai calmement comment vous améliorer (histoire de démontrer ma grande largeur d’esprit).

je n'ai pas le temps de faire dans la dentelle... Alors effectivement je casse les conneries afin de tenter qu'elles ne soient pas reprises par les faibles d'esprit.

Pour votre information Access n'a rien à voir avec un SGBDR.
C'est pas parce qu'il y a des tables et du SQL que l'on est dans un SGBDR !
La relationnel a été inventé par Franck Edgar Codd en 1970 et, déjà, en 1985 il attirait l'attention, des professionnels sur le fait que certains produits prétendait être relationnels alors qu'ils ne l'était pas.
Pour savoir si un SGBD est relationnel, il suffit de regarder s'il applique les 12 règles de Codd et le concept de transaction.
Or Access ne sait déjà pas faire de transaction et son score sur les 12 règles est le suivant :
Règle 4 : non
Règle 5 : non (ni DCL ni TCL)
Règle 6 : non
Règle 7 : non à priori (d'après mes souvenirs)
Règle 10 : non (manque le catalogue)
Règle 11 : non
Règle 12 : non

Conclusion, commencez par apprendre ce qu'est un SGBD Relattionel et non un gestionnaire de table !

A +

[vince.f]

Devons-nous comprendre que, pour vous, l'application et la base de données sont sur le même serveur ?

Il est vrai que si votre domaine de compétence est principalement Access, c'est peut-être le cas.

Vous savez quand même que ce n'est largement pas le cas de toutes les applications d'entreprises ou d'organismes publics, quand même ?

Dans notre relativement petit établissement public, nous avons :
- un serveur Oracle de production, contenant quelques dizaines de schémas pour toutes les données de gestion ;
- un serveur de production pour l'ERP ;
- un serveur Oracle de test qui contient plusieurs copies de la base de prod ;
- deux serveurs pour tests et formations sur l'ERP ;
- deux serveurs MySQL pour les données des applications annexes, les données des sites web... ;
- plusieurs serveurs pour les sites webs et applications annexes.

Les cas où l'application et la BDD sont sur le même serveur sont rares. C'est notamment le cas pour l'application de notre CDI qui a des BDD trop grosses et qui posaient des soucis quand elles étaient sur le serveur MySQL central.

Non, je n’ai en aucun cas impliqué ça (quelle drôle d’idée) et la partie sur Access était une boutade destinée à SQL Pro (que vous n’avez pas saisie visiblement). Apparemment lui non plus.

[repgarent]

je ne pensais pas que ma petite question allait engendrer un tel débat!

je ne peux pas dire de maniere explicite dans quel entreprise je travaille (confidentialité oblige) mais pour vous mettre sur la voie, la mascotte est "la plus vieille et la plus connue", "la plus populaire", "connue dans le monde entier", ect...

C’est assez commun de se retrouver prisonnier de la « BDD unique » de plusieurs centaines de Go que personne ne veut toucher parce qu’elle affecte toutes les applications de l’entreprise. A moins que vos applications soient minuscules (et que vous soyez sûr qu’elles vont le rester), je vous déconseille vivement de vous infliger ça.

Dans l'entreprise (au sens large), le développement se fait au siege de la boite habituellement. les sujets qui arrivent chez moi(CaD une des usines) sont ceux que le siege ne veut ou ne peut pas traiter, et sont effectivement "minuscule", en terme de données du moins. et le resteront, ou seront transféré sur les serveur du siège.

beaucoup d’entreprise se séparent peu à peu de ces BDD uniques monstrueuses qui coutent plusieurs centaines de milliers d’euros par an en licences (les fameux cœurs que Microsoft facture).
Je ne pense pas que l'entreprise de repgarent en soit là, si j'en juge par son système actuel :
Citation Envoyé par repgarent
en gros on passe du couple infernal excel/access a des appli asp.net

oui et non, si on pouvait éviter d'en arriver là c'a m'arrangerais, plus pour la maintenance que ca implique que pour le coût, c'est pas moi qui paye


Bon je vais pas tout commenter non plus, mais en tous cas, j'ai ma réponse : Le probleme qu'on a sur le site étant principalement la redondance des données, et les données différentes dans plusieurs tables (copie de copie de copie... merci les utilisateurs qui pioche dans les bases au pif...) ainsi que les performance, le multi-table est franchement pas adapté.

P.S.

Je prépare à ce propos un livre chez Eyrolles que je me ferais un plaisir de promouvoir à chacune de vos interventions erronées sur Access (en incluant à chaque fois la couverture en pleine page). Ou alors je vous expliquerai calmement comment vous améliorer (histoire de démontrer ma grande largeur d’esprit).

j'ai pas compris si cette partie est une boutade ou pas, mais au càs où, je te saurais gréer de rajouter, en premiere page, "Ce livre est destinée aux développeur. si vous voulez monter une ptite appli pour votre service, abstenez-vous, ou allez voir le SI!".
Je passe mon temps a refaire des appli de base access monté n'importe comment par les utilisateurs, de mon point de vue, access est le pire des fléau.

[CinePhil]

Est-ce que, au moins, notre débat, parfois houleux, vous aura aidé à choisir ?

[repgarent]

le débat a surtout mis en lumiere les avantage/inconvenients de chaque solution, donc oui, ça m'a aidé a choisir

[CinePhil]

Et donc, quel choix ? Et pourquoi ?

[damorni]

Bonjour à tous.
J'aimerais avoir plus d'informations sur le sujet, et a ce titre, je vais vous expliquer sommairement mon problème qui est similaire, mais pas tout à fait identique, du moins je pense.
En bref, j'ai prévu de créer plus applications qui ont des but différents, mais qui ont quelques partages de données. Je compte toucher des millions d'utilisateurs, et donc des millions de données par application.
Compte tenu de la masse de données que je prévois, dois-je :
- créer une seule base :
- ou découper la base, par exemple, une base utilisateur qui sera commune a toutes les applications, une base par application, et une base pour les différentes données a echanger ?
En bref, je vise un fonctionnement assez similaire à Google, avec Google mail, Google contacts, Google agenda, Google ...
Merci pour vos avis.

[SQLpro]

Une seule base, plusieurs schémas SQL.
Prenez un SGBDR qui sait gérer correctement les schémas SQL (donc pas MySQmerde dans lequel la notion de schémas SQL n'existe pas).
Si vous voulez du libre, PostgreSQL, mais dans ce cas pensez aux limitations :

• taille maximale de la base : quelques centaines de Go
• pas conçu pour du 24h/24 7j/7

A +

[bretus]

En bref, je vise un fonctionnement assez similaire à Google, avec Google mail, Google contacts, Google agenda, Google ...
Merci pour vos avis.

Étrange de voir ce débat... Sûrement lié au fait que la question est dans "Décision SGBR" plutôt que "Général conception web" mais la plupart des systèmes tendent à se décomposer en applications communiquant entre elles via des API :

• Application de gestion de compte : https://myaccount.google.com/
• API d'authentification : https://developers.google.com/identity/protocols/OAuth2
• GMail : https://mail.google.com
• ...
• Les API : https://developers.google.com/apis-explorer/#p/

En outre, il n'est pas nécessaire d'aller vers des systèmes aussi gros pour constater que l'approche où on a une seule et unique grosse base de données SQL pour stocker tous les types de données est marginale. En entreprise ou sur des systèmes avec quelques centaines d'utilisateurs, on trouve déjà des choses du style :

• Un base pour le stockage des utilisateurs (souvent du LDAP en raison du support par les applications tierces)
• Une application de gestion de compte (parfois restreinte au changement de mot de passe)
• En présence d'un SSO, des protocoles d'authentification (OAuth, CAS) voire un reverse proxy d'authentification
• Les applications qui s'appuie sur ce cadre pour authentifier les utilisateurs en stockant un minimum d'information sur ces derniers

C'est pas sans raison...

Une seule base, plusieurs schémas SQL.

• Soit la gestion des droits en lecture/écriture des comptes des applications est un enfer, soit on risque le carnage au moindre changement de structure ou à la moindre faille dans une application
• On est pied et point lié à la base de données sur l'intégralité du système. Changer de marque impose la reprise de l'ensemble des applications.
• Une montée en version du SGBD impose la recette synchrone de l'ensemble des applications
• Bonne chance pour gérer des jeux tests spécifiques aux applications pour automatiser les recettes!
• Bonne chance pour le jour où une application fera tomber la base de données ou l'ensemble des répliques : c'est l'ensemble du système qui tombe
• Bonne chance pour gérer les clés étrangères (surtout vers des objets qui subissent des fusions/scissions demandant des mises à jour de références spécifiques)
• ...

Si on découple les applications, on se retrouve certes à devoir mettre un cadre de déploiement par exemple pour gérer les sauvegardes et homogénéiser les versions, mais :

• On limite la casse en cas de problème de sécurité sur une application
• On s'assure qu'une erreur de conception dans une application B consommant les données d'une application n'impactera pas l'application A (un lien pourri de B vers A et mettre à jour les données A devient impossible)
• On peut faire des choses aussi bête que baser l'une des applications sur wordpress sans donner des sueurs froides au responsable de la sécurité
• On peut revoir la conception service par service quand on monte en charge
• ...

[SQLpro]

Étrange de voir ce débat... Sûrement lié au fait que la question est dans "Décision SGBR" plutôt que "Général conception web" mais la plupart des systèmes tendent à se décomposer en applications communiquant entre elles via des API :

• Application de gestion de compte : https://myaccount.google.com/
• API d'authentification : https://developers.google.com/identity/protocols/OAuth2
• GMail : https://mail.google.com
• ...
• Les API : https://developers.google.com/apis-explorer/#p/

Les cas que vous citez n'ont strictement rien à voir avec de l'informatique de gestion. Les bases que vous présentez sont des bases de métadonnées technique d'utilisation de données hors de portée des utilisateurs finaux… Dans cette discussion, nous parlons des données de l'entreprise et non des métadonnées des informaticiens !

En outre, il n'est pas nécessaire d'aller vers des systèmes aussi gros pour constater que l'approche où on a une seule et unique grosse base de données SQL pour stocker tous les types de données est marginale. En entreprise ou sur des systèmes avec quelques centaines d'utilisateurs, on trouve déjà des choses du style :

• Un base pour le stockage des utilisateurs (souvent du LDAP en raison du support par les applications tierces)
• Une application de gestion de compte (parfois restreinte au changement de mot de passe)
• En présence d'un SSO, des protocoles d'authentification (OAuth, CAS) voire un reverse proxy d'authentification
• Les applications qui s'appuie sur ce cadre pour authentifier les utilisateurs en stockant un minimum d'information sur ces derniers

IDEM, toujours même erreur…. Strictement rien à voir avec de l'informatique de gestion.

C'est pas sans raison...

Soit la gestion des droits en lecture/écriture des comptes des applications est un enfer, soit on risque le carnage au moindre changement de structure ou à la moindre faille dans une application

C'est pourquoi dans les bons SGBDR (je ne parle pas de MySQmerde qui ne connais même pas ce concept) les schémas SQL peuvent être dotés de privilèges (on ne parle pas de droits en matières de SGBDR)...

On est pied et point lié à la base de données sur l'intégralité du système. Changer de marque impose la reprise de l'ensemble des applications.

On est toujours pieds et poings liés par la techno… que ce soit au niveau de la base ou du code… Allez-vous changer de PSHP à C# ou Java ? Donc, remarque sans intérêt !

Une montée en version du SGBD impose la recette synchrone de l'ensemble des applications

Il y a des SGBDR qui savent monter en version sans aucune modification de fonctionnement. 1) MS SQL Sever depuis la version 2008, 2) Azure SQL ou le changement de version n'existe pas puisque les améliorations sont continues !

Bonne chance pour gérer des jeux tests spécifiques aux applications pour automatiser les recettes!

Il existe de nombreux outils pour cela et pour certains éditeurs des outils gratuits spécifiques (exemple pour Microsoft SQL Server RML, Ditributed Replay…)

Bonne chance pour le jour où une application fera tomber la base de données ou l'ensemble des répliques : c'est l'ensemble du système qui tombe

Si vous avez un mauvais SGBDR et des mauvais DBA, c'est possible. Pourtant il existe de nombreuses entreprises utilisant des ERP de grande dimension (SAP pour ne pas le citer) qui fonctionnement 24h sur 24, 7j sur 7 sans jamais tomber en panne ni s'arrêter… Evidemment pas avec du MySQmerde ni du PG !

Bonne chance pour gérer les clés étrangères (surtout vers des objets qui subissent des fusions/scissions demandant des mises à jour de références spécifiques)

Cela n'a jamais été un problème, sauf pour ceux qui n'ont toujours pas compris comment modéliser correctement et comment le SGBDR était capable d'utiliser les FK pour optimiser les requêtes !

Si on découple les applications, on se retrouve certes à devoir mettre un cadre de déploiement par exemple pour gérer les sauvegardes et homogénéiser les versions,

Et à la restauration on se retrouve avec des points de synchro différents dans toutes les bases donc des connées manquantes un peu partout… Bref, trois mois pour recoller les morceaux !!!!

mais :

On limite la casse en cas de problème de sécurité sur une application

Visiblement vous ne connaissez pas les fonctionnalité des SGBDR moderne, il est parfaitement possible de rendre étanche une partie d'une base aussi bien au niveau logique (privilège) que physique (stockage)

On s'assure qu'une erreur de conception dans une application B consommant les données d'une application n'impactera pas l'application A (un lien pourri de B vers A et mettre à jour les données A devient impossible)

Même remarque que précédemment

On peut faire des choses aussi bête que baser l'une des applications sur wordpress sans donner des sueurs froides au responsable de la sécurité

Avec comme support des données une daube comme MySQmerde...

On peut revoir la conception service par service quand on monte en charge

Rien ne l'empêche dans une base muti schéma…

Je remarque que la plupart de vos propose des résument à la connaissance d'un SGBD (non relationnel d'ailleurs) comme MySQL !
Il serait sans doute temps de vous cultiver en allant voir ce dont sont capables les vrais SGBDR !

A +

[bretus]

Les cas que vous citez n'ont strictement rien à voir avec de l'informatique de gestion.

Le cas évoqué par notre amis non plus :

En bref, je vise un fonctionnement assez similaire à Google, avec Google mail, Google contacts, Google agenda, Google ...

Je remarque que la plupart de vos propose des résument à la connaissance d'un SGBD (non relationnel d'ailleurs) comme MySQL !
Il serait sans doute temps de vous cultiver en allant voir ce dont sont capables les vrais SGBDR !

Je travaille principalement avec PostgreSQL/PostGIS depuis plus de 10 ans. Après, j'avoue : Je passe plus mon temps à résoudre des problématiques métiers qu'à suivre les dernières évolutions de PostgreSQL.

Mes DBA ne sont pas mauvais mais les architectes qui m'encadrent semblent préférer éviter de faire reposer trop de responsabilités sur les DBA (et plus généralement sur des configurations de restrictions de droits)

Sinon, je suis tout à fait d'accord pour dire qu'à l'échelle d'une application, on travaille avec une seule base et plusieurs schémas.

Pour le reste, je vous laisse avec avec vos certitudes et votre informatique de gestion. Je saurais difficilement définir la chose surtout à l'heure des croisements de données et j'ai un sérieux doute sur le fait que les frontières soit aussi hermétiques que vous le laissez entendre.

[SQLpro]

Je travaille principalement avec PostgreSQL/PostGIS depuis plus de 10 ans...

Pour le reste, je vous laisse avec avec vos certitudes et votre informatique de gestion. Je saurais difficilement définir la chose surtout à l'heure des croisements de données et j'ai un sérieux doute sur le fait que les frontières soit aussi hermétiques que vous le laissez entendre.

D’où votre méconnaissance des technologies embarquées dans les SGBDR modernes (PostgreSQL est à peine à 10 % de ce que fait Oracle ou SQL Server) :
Quelques exemples simples :

• PG n'a pas de type XML intégré et ne sait pas faire des requêtes XQuery/XPath directement en SQL...
• PG vient de se mettre au parallélisme pour 3 opérations, alors que dans SQL Server toutes les opérations se font en // depuis la version 7 datant de 1998.
• pas d'index verticaux (pour les très grandes tables > 10 000 000 de lignes)
• pas de tables "in memory"
• pas de tables de graphes
• pas de possibilité d'aller vers du big table (SQL Server accepte des tables avec 30 000 colonnes...)
• pas de possibilité de faire du "document DB" (absence de DataLink et donc impossibilité de faire du Full text sur des doc électroniques)
• pas d'outil de type ETL intégré
• pas de moteur décisionnel
• pas d'outil de data mining
• pas de possibilité de base hybrides (une partie locale une autre dans le cloud)
• pas d'optimisation des requêtes interbase (passage obligatoire par DBlink => remote join !!!! Bonjour les perf....)

J'arrête là mais il faudrait parler aussi de la sécurité et l’inaptitude de PG à réellement mettre en œuvre la RGPD....

Aujourd'hui un SGBDR qui ne fait que du relationnel et n'est pas capable d'aller sur le cloud est mort d'avance. Les grand éditeurs ont intégré depuis plusieurs versions toutes les technologies matures des bases noSQL...

A +