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

  1. #21
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 081
    Points : 31 940
    Points
    31 940
    Billets dans le blog
    5

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  2. #22
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

    Citation Envoyé par vince.f Voir le message
    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 +
    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 * * * * *

  3. #23
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

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

    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 * * * * *

  4. #24
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

    Citation Envoyé par vince.f Voir le message
    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 +
    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 * * * * *

  5. #25
    Membre du Club
    Homme Profil pro
    Développeur SQL
    Inscrit en
    novembre 2014
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur SQL
    Secteur : Conseil

    Informations forums :
    Inscription : novembre 2014
    Messages : 15
    Points : 52
    Points
    52

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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.

  6. #26
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2014
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2014
    Messages : 31
    Points : 30
    Points
    30

    Par défaut

    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.

  7. #27
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 081
    Points : 31 940
    Points
    31 940
    Billets dans le blog
    5

    Par défaut

    Est-ce que, au moins, notre débat, parfois houleux, vous aura aidé à choisir ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #28
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2014
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2014
    Messages : 31
    Points : 30
    Points
    30

    Par défaut

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

  9. #29
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 081
    Points : 31 940
    Points
    31 940
    Billets dans le blog
    5

    Par défaut

    Et donc, quel choix ? Et pourquoi ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  10. #30
    Candidat au Club
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    juin 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gers (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 1
    Points : 2
    Points
    2

    Par défaut J'en veux plus !

    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.

  11. #31
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

    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 +
    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. #32
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2009
    Messages
    542
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mars 2009
    Messages : 542
    Points : 1 023
    Points
    1 023

    Par défaut

    Citation Envoyé par damorni Voir le message
    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 :



    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...

    Citation Envoyé par SQLpro Voir le message
    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
    • ...

  13. #33
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

    Citation Envoyé par bretus Voir le message
    É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 :


    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 +
    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 * * * * *

  14. #34
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2009
    Messages
    542
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mars 2009
    Messages : 542
    Points : 1 023
    Points
    1 023

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Les cas que vous citez n'ont strictement rien à voir avec de l'informatique de gestion.
    Le cas évoqué par notre amis non plus :

    Citation Envoyé par damorni Voir le message
    En bref, je vise un fonctionnement assez similaire à Google, avec Google mail, Google contacts, Google agenda, Google ...
    Citation Envoyé par SQLpro Voir le message
    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.

  15. #35
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 614
    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 : 18 614
    Points : 43 466
    Points
    43 466

    Par défaut

    Citation Envoyé par bretus Voir le message
    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 +
    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 * * * * *

Discussions similaires

  1. Choisir entre partage une base de données ou creer deux bases de données
    Par karima123 dans le forum Sondages et Débats
    Réponses: 7
    Dernier message: 27/01/2016, 18h17
  2. [AC-2010] base de données dite classique et base de données web
    Par mapmip dans le forum Access
    Réponses: 1
    Dernier message: 28/08/2010, 11h15
  3. [base de donnée] accée a la base de données sur eclipse
    Par khalidlyon dans le forum Eclipse Java
    Réponses: 1
    Dernier message: 07/04/2005, 23h12

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