Discussion :

[Patrick22334]

Recommandez-vous l'utilisation de plusieurs types de bases de données au sein d'une même organisation ?

Je me pose la question, puisqu'en ce moment nous utilisons PostgreSQL. Personnellement, je ne vois pas la nécessité d'en utiliser un autre et il me semble, au premier abord, qu'il serait plus judicieux de déployer des applications et logiciels tournant sur celui-ci afin de faciliter les interactions entre ceux-ci. Ceci dit, lorsque vient le temps de faire le choix d'une application ou logiciel, certaines autres caractéristiques peuvent être prises en compte. Donc, est-ce que les considérations concernant le transfert, les échanges entre les différents SGBD, ainsi que l'architecture globale qui nous permet de réaliser nos produits et services devraient être prises en compte et dans quelle mesure ? Admettons que j'utilise PostgreSQL, Oracle et SQL Server...
Merci

[CinePhil]

J'aurais tendance à dire que si PostgreSQL vous suffit et si vous n'avez pas de contrainte externe vous imposant un autre SGBDR, pourquoi vouloir en ajouter un autre ?

Il vous faudrait des compétences sur les deux SGBD (ou trois), ce qui est plus cher et contraignant que d'en avoir sur un seul.

Nous avons Oracle qui nous est imposé par l'utilisation de notre ERP et le SGBD historiquement choisi pour nos développements et applications open source est MySQL/MariaDB. Nous n'avons jamais eu le besoin de passer à PostgreSQL, même si j'aimerais bien.

[Patrick22334]

Merci beaucoup CinePhil

Est-ce que les transferts et échanges entre des SGBDR différents se font de manière fluide généralement ou bien des bugs sont à prévoir ? Admettons que je voudrais concentrer mes données acquises dans une seule SGBDR.

[CinePhil]

Nous ne faisons pas d'échanges entre les bases de données.

Avec PostgreSQL, il est possible de requêter sur plusieurs BDD grâce à DBLink.

Oracle utilise aussi le DBLink.

Avec MySQL, si les bases sont sur le même serveur, les requêtes multibases sont possibles et aussi faciles qu'à l'intérieur d'une base, comme ça peut l'être sur un autre SGBDR entre schémas d'une BDD.

SQL Server, je ne sais pas ; je ne l'ai jamais utilisé.

Dans tous les cas, il est possible qu'une application utilise plusieurs BDD sur plusieurs serveurs en se connectant à celles-ci.

Par exemple, une application de gestion pourrait utiliser une BDD Oracle et un référentiel géographique PostGis donc sur PostgreSQL. Mais ce n'est pas du requêtage multi-bases et l'échange de données éventuel entre les BDD se fait au travers de l'application.

[ced]

Avec PostgreSQL, il est possible de requêter sur plusieurs BDD grâce àDBLink.

Sur les dernières versions de PostgreSQL (depuis la 9.3 de mémoire pour la connexion de serveur PostgreSQL à serveur PostgreSQL), on peut faire tout un tas de liens entre SGBD à l'aide des Foreign Data Wrappers.
C'est très puissant, mais les perfs ne suivent malheureusement pas toujours (tout dépend du driver utilisé).

On trouve même des wrappers pour intégrer des feuilles Excel sous forme de tables étrangères dans PostgreSQL (pratique pour les imports depuis un seul environnement, sans avoir à se casser la tête à faire des exports d'un côté, imports de l'autre).

ced

[SQLpro]

SQL Server, je ne sais pas ; je ne l'ai jamais utilisé.

SQL Server est depuis l'origine naturellement multibase et multi schéma. Au niveau du multibase il est optimisé pour cela, ce qui n'est le cas d'aucun autre SGBDR à ma connaissance. Chaque base ayant son propre JT [1] et ses fichiers de données, et l'optimisation d'une jointure interbase est aussi puissante que celle d'une jointure intrabase. Ni Oracle (avec le multi tenant imposant des REMOTE JOIN et avec un seul JT pour toutes les bases), ni PostgreSQL (à cause du DBLink qui impose des REMOTE JOIN et un seul JT pour toutes les bases), ni MySQL (qui utilise un seul JT pour toutes les bases) n'ont de performance optimale en multibase.

A +

[1] : certaines journalisation de transactions étant faites à part, hors du journal de transaction purement relationnel. Il s'agit : des LOBS dans le cadre du FileStream, des tables temporaires (effectuées dans la base système tempdb), et des mises à jour de tables "In Memory" dont les journal n'est pas un fichier, mais un segment de RAM.

[Patrick22334]

Merci à tous

Alors si je comprends bien, il n'y a pas de problème à se connecter à une autre SGDB pour faire des requêtes, mais c'est moins évident pour faire des jointures et les maintenir surtout si elles ne sont pas sur le même serveur. Et, si je veux rapatrier mes tables qui sont dans différentes SGBD dans une seule SGDB il faudra que j'y aille avec un export - conversion - import.

Si je me trompe ou si ce n'est pas tout à fait exact faites-moi signe, sinon mon problème (ou question, c'est selon) est résolu.

[Patrick22334]

Et, SQLpro, si je t'ai bien compris, lorsque tu parles des performances de SQL Server avec les multibases et multischémas c'est entre des SGDB SQL Server et non pas nécessairement entre SQL Server et PostgreSQL ou Oracle ou MySQL ?

[SQLpro]

Merci à tous

Alors si je comprends bien, il n'y a pas de problème à se connecter à une autre SGDB pour faire des requêtes, mais c'est moins évident pour faire des jointures et les maintenir surtout si elles ne sont pas sur le même serveur. Et, si je veux rapatrier mes tables qui sont dans différentes SGBD dans une seule SGDB il faudra que j'y aille avec un export - conversion - import.

Si je me trompe ou si ce n'est pas tout à fait exact faites-moi signe, sinon mon problème (ou question, c'est selon) est résolu.

Il est toujours possible de se connecter d'un serveur A à un serveur B même si celui-ci n'est pas du même éditeur.

• Dans SQL Server cela se fait par le biais des "linked server" (puisque les jointures entres bases sont natives)
• Dans Oracle et PostgreSQL cela se fait par le biais des DB Link (puisque les jointures entres bases ne sont pas natives)
• Dans MySQmerde, je ne sait ps et vu que c'est un ersatz de SGBDR, je ne choisirait pas cette chose pour un projet critique au niveau, perf ou sécurité...

ATTENTION cependant… Il n'y a pas de difficultés majeures à faire des requêtes d'extraction. Mais pour des requêtes de mise à jour (INSERT, UPDATE, DELETE, TRUNCATE, MERGE….) il est parfois nécessaire d'utiliser un coordinateur de transaction distribuées afin d'assurer de "commit à deux phases" ce qui ne va pas sans certaines risques. Lisez l'article que j'ai écrit à ce sujet :
https://blog.developpez.com/sqlpro/p..._a_deux_phases

Pour ce qui est de rapatrier les données il existe différentes techniques.

• Par import via de simples fichiers ou un ETL intégré (par exemple SSIS dans MS SQL Server)
• Par le biais d'un mécanisme de réplication des données (par exemple la réplication transactionnelle dans MS SQL Server)
• Par de biais d'une architecture SODA (Service Oriented Database Architecture - par exemple via Service Broker dans MS SQL Server)

Tout dépend de la fréquence, la latence, le but fonctionnel de la migration des données...

A +

[SQLpro]

Et, SQLpro, si je t'ai bien compris, lorsque tu parles des performances de SQL Server avec les multibases et multischémas c'est entre des SGDB SQL Server et non pas nécessairement entre SQL Server et PostgreSQL ou Oracle ou MySQL ?

Oui, ne pas confondre le multibase (Oracle, pour se distinguer une fois de plus, l'appelle "multi-tenant") et l'accès croisés à de multiples serveurs (aussi appelées instances et malheureusement "cluster" dans le monde PotGreSQL).

A +

[escartefigue]

SQL Server est depuis l'origine naturellement multibase et multi schéma. Au niveau du multibase il est optimisé pour cela, ce qui n'est le cas d'aucun autre SGBDR à ma connaissance. .

DB2 for Z/OS est également multibase et multischema depuis des lustres (et probablement depuis toujours mais je n'ai pas moyen de le vérifier).
Par contre, sauf erreur de ma part, le journal des transactions est obligatoirement unique pour toutes les bases.

[fsmrel]

DB2 for Z/OS est également multibase et multischema depuis des lustres (et probablement depuis toujours mais je n'ai pas moyen de le vérifier).
Par contre, sauf erreur de ma part, le journal des transactions est obligatoirement unique pour toutes les bases.

Voir la 11e des 12 règles de Codd (1985) :

Distribution independence:. Codd a donné un point à DB2 car les programmes SQL opérationnels avec SYSTEM R fonctionnaient aussi avec le prototype System R*. Par distribution, il s’agit bien sûr de celle des données et non pas des traitements.

Concernant System R* lui-même, on remonte à l’année 1980 avec la publication de Pat Selinger et Michel Adiba :

Access Path Selection in Distributed Data Base Management Systems

Pour sa part, Chris Date relève, je le cite (An Introduction to Database Systems, Eighth Edition, page 688) :

« R* provides location independence, but no fragmentation or replication »

Date a consacré le chapitre 21 de son ouvrage à la distribution des bases de données (sujet dont il traitait déjà dans la 4e édition de son ouvrage). Page 651, il énonce les 12 règles qu’il a développées dans Relational Database, Writings 1985-1989, « What Is a Distributed Database System? ».

Voir aussi le papier de Jim Gray et Irving Traiger, daté de 1979 :
Transactions and Consistency in Distributed Database Systems

On remonte encore dans le temps, en 1977, mais cette fois-ci on quitte IBM, pour se diriger du côté de Ingres, l’enfant chéri de Mike Stonebraker (University of California, Berkeley) : « A Distributed Data Base Version of Ingres ». Date consacre plus de 20 lignes à l’article (toujours dans l’ouvrage que j’ai mentionné, aux pages 687 et 688).

Capitaine, j’arrête là ma plongée dans le passé…