Au bon vieux temps, on lançait une application, on ouvrait son fichier et on y travaillait tranquillement sans se poser de questions. Avec l’arrivée du réseau et du travail collaboratif, il a fallu se poser quelques questions supplémentaires, et trouver les réponses adaptées.

Qu’en est-il du travail à plusieurs sur le même sujet et avec quels droits ?

Comment partager et sauvegarder le travail ?

Comment travailler en plusieurs lieux et avec des types d’équipement et de connexion différents ?

Comment gérer des volumes de données sans cesse plus importants tout en conservant des performances raisonnables ?

C’est ainsi que sont nées les bases de données et les architectures distribuées.

Les premières bases de données

Le premier problème à résoudre était de permettre l’accès à plusieurs aux mêmes données.

Pour cela il a fallu structurer les fichiers qui stockent les données en définissant le concept de tables contenant les différentes données et pour chacune des enregistrements contenant un ensemble de données individuelles.

>> Sur ce même sujet – Architectures applicatives et bases de données : le Web et les serveurs applicatifs

On a alors pu ainsi permettre à un utilisateur de manipuler une donnée spécifique et tandis qu’un autre consultait ou modifiait un autre élément des données, le tout en même temps et sans risque de conflit ou d’écrasement. C’est ainsi que son apparus DBase, Btrieve ou MS-Access pour n’en citer que quelques-uns. Ces bases de données dites distribuées dominaient le marché au début des années 90.

Mais tout cela supposait toutefois la coopération des différentes instances des applications, et était souvent sujet à des corruptions de données et était loin d’être performant.

Les serveurs de base de données

On a alors imaginé mettre une application entre le fichier de données et l’application de l’utilisateur.

Les objectifs étaient multiples :

  • S’assurer en un point central de la cohérence des accès
  • Gérer des droits
  • Limiter le trafic réseau en gérant une pré-analyse au niveau du serveur

Le serveur de base de données était né avec les Informix et autres Oracle ou SQL-Server.

Tout cela était très efficace, mais il fallait déjà imaginer la suite, à savoir un langage commun entre les applications et les serveurs.

Le langage SQL

Les normalisateurs de l’époque, l’ANSI et l’ISO en l’occurrence, ce sont mis pour une fois assez rapidement d’accord pour un standard dénommée SQL (Structured Query Language).

Adopté rapidement par les acteurs majeurs, et totalement normalisé en 1992 sous le nom original de SQL 92, il s’est imposé comme langage de référence pour les bases de données et reste toujours largement dominant 30 ans plus tard

Son avantage réside dans une certaine indépendance entre les applications et le serveur de base données (même si le système a rapidement montré ses limites).

Une application dialoguant avec ses données à travers SQL pourra les voir hébergées sur des serveurs d’origines diverses sans souci de compatibilité.

Même si cela est globalement vrai, les éditeurs de base de données ont fait en sorte qu’il faille à peu près systématiquement adapter l’application au type de base données qui l’héberge, mais cela reste un travail mineur.

Cette architecture était standard au début du 21ème siècle, mais l’arrivée du web a changé les règles du jeu…

 

Olivier Piochaud, PDG d’Apsynet

 

Newsletter

Categories: Développement & Web