Citation:
Envoyé par
bretus
É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 !
Citation:
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.
Citation:
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)...
Citation:
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 !
Citation:
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 !
Citation:
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…)
Citation:
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 !
Citation:
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 !
Citation:
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 !!!!
Citation:
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)
Citation:
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
Citation:
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...
Citation:
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 +