Aujourd’hui encore, la gestion électronique des données est dominée par le modèle de la base de données relationnelle. Les systèmes de gestion de bases de données relationnelles (SGBDR) les plus couramment utilisés sont classés par ordre alphabétique :
Les informations de tous les systèmes mentionnés ci-dessus sont organisées dans des tables relationnelles. Mais de quoi s’agit-il ? Nous vous présenterons les principes de base de la conception des bases de données relationnelles ainsi que des exemples de bases de données. Enfin, nous identifierons les différences de ce type de base données avec les autres modèles existants.
Le concept central du schéma relationnel de la base de données est la relation. C’est le mathématicien et théoricien britannique, Edgar F. Codd qui inventa les modèles relationnels. Selon lui, une relation représente un ensemble d’entités ayant les mêmes propriétés. Chaque relation est constituée d’une série d’enregistrements de données (appelés tuples) dont les valeurs sont affectées à certains attributs.
Les attributs qu’une relation contient et le type de données auquel correspondent les valeurs affectées aux attributs sont définis à l’aide d’un schéma de relations selon la syntaxe suivante :
R = (A1 : Typ1, A2 : Typ2 ,… , An : Typn)
Le schéma de relation (R) comprend les attributs A1 à An. Un type de données (Type1, Type2, etc.) est affecté à chaque attribut. Ceci peut être illustré par un exemple concret.
Le schéma suivant définit les attributs de la relation « employé » :
employé = ( e_id : integer,
nom : string,
prénom : string,
numéro de sécurité sociale : string,
rue : string,
code postale : string,
ville : string )Afin de pouvoir représenter clairement l’affectation des valeurs individuelles d’un tuple aux attributs définis dans le schéma relationnel, un concept classique d’organisation de l’information est utilisé dans le modèle de base de données relationnelle : la table. Une base de données relationnelle n’est donc rien de plus qu’une collection de tables liées entre elles.
Les tables sont des schémas d’ordre composés de lignes horizontales et de colonnes verticales qui permettent de collecter et d’afficher les informations sous une forme ordonnée. Chaque ligne d’une table de base de données correspond à un tuple. Les valeurs des tuples listés sont affectées aux attributs définis dans le schéma de relation via les colonnes de la table.
L’exemple suivant montre à quoi peut ressembler une table de base de données pour la table des employés répertorié ci-dessus.
e_id | nom | prénom | numéro de sécurité sociale | rue | code postale | ville |
1 | Dupond | Jacques | 25 120512 S 477 | Grand Boulevard 1 | 11111 | Lacité |
2 | Martin | Jean | 25 100615 M 694 | Rue de la Gare 5 | 22222 | Laville |
3 | Petit | Hélène | 25 091225 M 463 | Place du Marché 3 | 33333 | Levillage |
4 | Lefevre | Lisa | 25 170839 K 783 | Rue de l’Eglise 4 | 44444 | Laforêt |
La table d’exemple est utilisée pour enregistrer les données du personnel et se compose de quatre enregistrements de données. Chaque enregistrement de données contient des informations sur un seul salarié.
Le terme « relation » est utilisé comme synonyme de « table » selon Edgar F. Codd. Dans la pratique, toutefois, ce terme est utilisé de manière incohérente, par exemple, pour désigner les relations entre les différentes tables. Afin d’éviter les malentendus, nous éviterons le terme « relation » et parlerons de « tables » lorsque nous ferons référence aux tables d’une base de données relationnelle.
La base de données d’un système de bases de données relationnelles constitue la base de données tabulaire. Leur structure de données est définie par le système de gestion de la base de données, qui est également responsable de la gestion des accès en lecture et en écriture. Les utilisateurs interagissent avec le système de gestion de base de données en utilisant un langage de base de données. Chaque système de gestion de bases de données relationnelles supporte au moins un langage formel qui peut être utilisé pour effectuer les opérations de base de données suivantes :
L'interface standard pour les opérations de base de données énumérées ci-dessus dans le modèle de bases de données relationnelles est SQL (Structured Query Language), un langage de base de données basé sur l'algèbre relationnelle.
Les opérations de base de données telles que l’interrogation, la création, la mise à jour ou la suppression de données sont effectuées à l’aide d’instructions SQL : une combinaison de commandes SQL sélectionnées. Celles-ci sont sémantiquement basées sur la langue anglaise et sont donc largement explicites. La table suivante contient les termes clés du modèle de données relationnelles et leurs équivalents dans la terminologie SQL.
Modèle de données relationnelles | SQL |
Relation | Table (Table) |
Attribut | Column (Colonne) |
Tuple | Row (Ligne) |
Une simple requête de données sélectionnées peut être implémentée avec SQL selon le schéma suivant, par exemple :
SELECT colonne FROM table WHERE colonne = valeur;Tout d’abord, nous utilisons la commande SELECT pour demander au SGBDR de récupérer les données. Nous définissons ensuite les données que nous voulons interroger en spécifiant la table et la colonne souhaitée. De plus, avec WHERE, nous intégrons une condition dans l’instruction SQL. Nous ne voulons pas récupérer toutes les valeurs d’attribut stockées dans la colonne, seulement la valeur d’un enregistrement particulier.
En relation avec notre exemple de table « employés », une telle instruction SQL pourrait ressembler à ceci :
SELECT numéro de sécurité sociale FROM employé WHERE e_id = 3;L’instruction SQL demande au SGBD relationnelle de récupérer une valeur de la colonne numéro de sécurité sociale de la table employé. Comme condition, nous avons défini que la valeur doit être tirée de l’ensemble de données pour lequel la valeur d’attribut de la colonne e_id correspond à la valeur 3.
En conséquence, la base de données nous fournit le numéro de sécurité sociale d’Hélène Petit, l’employée avec l’ID 3 : 25 091225 M 463.
une description détaillée des opérations de base de données basées sur le langage de base de données SQL est fournie par notre Tutoriel MySQL pour débutants.
Lorsqu’ils travaillent avec des bases de données relationnelles, les utilisateurs ont rarement à traiter avec des tables individuelles. En règle générale, on utilise des structures dans lesquelles les données sont triées en fonction de leur signification et stockées dans des tables séparées. Ce concept est associé à la nécessité de relier les tables de données, par exemple lorsque l’on interroge des données stockées dans différentes tables.
En principe, toutes les informations d’une base de données relationnelle peuvent également être stockées dans une table globale complète. Cela aurait l’avantage d’éviter la nécessité de lier les tables de la base de données, ainsi que la syntaxe complexe associée aux requêtes sur plusieurs tables. C’est cependant ce qui fait la force de la base de données et son modèle relationnel. La division de l’information en plusieurs tables sert à réduire les entrées doubles (appelées anomalies) et s’appelle la normalisation. Le degré de normalisation peut être déterminé sur la base de formes normales prédéfinies. Les formes normales courantes pour les tables de bases de données relationnelles sont :
Les conditions préalables s’appliquant aux formulaires normaux énumérés et la façon de transférer une base de données d’un formulaire normal à un autre est l’objet de notre Article de base sur la normalisation.
Les relations entre les tables de base de données séparées sont appelées Relationships dans le schéma relationnel des bases de données et sont créées à l’aide de clés. Les touches relient les tables et sont la base pour interroger ou modifier les données de différentes tables avec une seule et même instruction.
Les tables de base de données telles que la table d'exemple « employés » permettent différentes approches pour interroger des valeurs individuelles ou des enregistrements de données complets. L'accent est mis sur lesdites clés. Dans le modèle des bases de données relationnelles, une clé est un ensemble d'attributs qui peuvent être utilisés pour identifier de façon unique un ensemble de données.
Par rapport à l’exemple de table ci-dessus, la clé suivante permet l’identification unique d’un tuple :
{e_id, nom, prénom, numéro de sécurité sociale}Une telle clé avec les valeurs(e_id = ‘3’, nom = ‘Petit’, prénom = ‘Hélène’, numéro de sécurité sociale = ‘25 091225 M 463’) serait donc appropriée pour identifier l’enregistrement des données de l’employée Hélène Petit sans contradiction. Ce type de clé est connu sous le nom de super-clé. Toutefois, les super-clés n’ont que peu d’importance dans la pratique. L’une des raisons en est que les super-clés contiennent souvent plus d’attributs qu’il n’est nécessaire pour l’identification. En d’autres termes, les super-clés ne sont pas minimales.
Dans les bases de données relationnelles, on travaille donc avec le plus petit sous-ensemble possible d’une super-clef imaginable, ce qu’on appelle les clés candidates. Une table peut très bien contenir plusieurs clés candidates avec lesquelles les enregistrements de données peuvent être identifiés de façon unique.
L’exemple de requête de la section précédente a déjà montré que les enregistrements de données de la table « employés » peuvent être identifiés sans contradiction par le simple numéro d’identification de l’employé. Le numéro de sécurité sociale est une autre clé candidate dans la table de l’exemple. Une clé {nom, prénom} ne serait pas une bonne clé candidate, puisque cette combinaison d’attributs ne peut pas être attribuée de façon unique à un employé : plusieurs employées sous le nom d’Hélène Petit peuvent être salariées dans une même entreprise. L’identification au moyen d’une telle clé ne serait donc pas sans ambiguïté. Toutefois, deux employés ne peuvent pas partager le même numéro d’identification d’employé ou numéro de sécurité sociale.
Les clés candidates suivantes peuvent donc être déterminées de cette manière dans l’exemple de table ci-dessus :
{e_id}
{numéro de sécurité sociale}Les tables de base de données relationnelles sont généralement structurées de telle sorte que l’une des clés candidates possibles spécifie la séquence des enregistrements de données. Cette clé candidate s’appelle la clé primaire. En pratique, les clés primaires sont généralement des ID consécutifs. Avec le e_id, notre table d’exemple a aussi un tel ID.
Parce que les clés identifient de façon unique les enregistrements dans les tables de bases de données relationnelles, elles sont idéales pour corréler différentes tables dans une base de données. Pour ce faire, vous incluez la clé primaire d’une table comme clé étrangère dans l’autre table.
La table suivante contient des données qu’une entreprise peut avoir enregistrées sur son propre parc de véhicules. La clé primaire de la table « véhicules » est un v_id consécutif.
Table : véhicules
v_id | marque | modèle | Plaque d’immatriculation | Année de fabrication | Examen |
1 | VW | Caddy | B KH 778 | 2016 | 18.12.2018 |
2 | Opel | Astra | B PO 654 | 2010 | 12.08.2019 |
3 | BMW | X6 | B MW 780 | 2017 | 01.09.2018 |
Pour savoir quels employés utilisent quelle voiture de la société, vous devez lier la table « voitures » à la table « employés » par exemple, en intégrant la clé primaire de la table véhicule (v_id) comme clé étrangère dans la table des employés.
Table : employés
e_id | nom | prénom | numéro de sécurité sociale | n° | rue | code postale | ville | v_id |
1 | Dupond | Jacques | 25 120512 S 477 | 1 | Grand Boulevard 1 | 11111 | Lacité | 3 |
2 | Martin | Jean | 25 100615 M 694 | 2 | Rue de la Gare 5 | 22222 | Laville | 1 |
3 | Petit | Hélène | 25 091225 M 463 | 3 | Place du Marché 3 | 33333 | Levillage | 1 |
4 | Lefevre | Lisa | 25 170839 K 783 | 4 | Rue de l’Eglise 4 | 44444 | Laforêt | 2 |
La table des employés montre maintenant que le salarié Jacques Dupond utilise une voiture de fonction avec le v_id 3. L’employée Lisa Lefevre conduit un véhicule avec le v_id 2, Jean Martin et Hélène Petit se partagent le véhicule avec le v_id 1.
Si vous voulez déterminer quel employé aura quelle voiture de fonction la prochaine fois, vous devrez interroger à la fois la table « employés » et la table « véhicules ». Comme les deux tables sont liées par des clés étrangères, cela ne peut se faire qu’avec une seule requête. Les opérations de base de données qui impliquent plusieurs tables sont implémentées dans le modèle de base de données relationnelle en utilisant un JOIN.
Un JOIN (jointure en français) est une opération de base de données qui permet à plusieurs tables de base de données d’être interrogées simultanément. Les données des tables sélectionnées sont combinées dans un jeu de résultats et filtrées en fonction des conditions définies par l’utilisateur.
Les bases mathématiques de SQL JOINs sont deux opérations d’algèbre relationnelle : produit cartésien et sélection. Les utilisateurs déterminent quelles données des tables interrogées sont incluses dans le jeu de résultats en sélectionnant le mot clé JOIN et en utilisant une condition de sélection.
Les types de JOIN les plus importants sont les suivants :
Indépendamment de cela, il convient de distinguer les EQUI JOINs (équijointures) et les NON EQUI JOINs (théta jointures).
Les bases de données relationnelles basées sur SQL doivent être différenciées des concepts qui rompent avec la structure rigide des tables et utilisent des approches alternatives pour la structuration des données. Parmi les concepts les plus importants de ce type, on retrouve les bases de données orientées objet et les systèmes orientés documents.
A la fin des années 1980, un nouveau modèle de base de données, la base de données orientée objet, est apparu sur le marché. Il reprend les concepts de programmation orientée objet et permet le stockage des données sous forme d’objets. Cependant, cette approche n’a guère pu s’affirmer jusqu’à ce jour. Au lieu de cela, les concepts orientés objet ont été incorporés dans le développement de systèmes de bases de données relationnelles. Il en résulte des produits avec des extensions relationnel-objet qui permettent le stockage de types de données abstraites dans le modèle de bases de données relationnelles.
A l’ère du Web 2.0, et avec le changement d’utilisation d’Internet, le modèle relationnel des bases de données a été fortement remis en question au tournant du millénaire. Dans le cadre du mouvement NoSQL (abréviation de Not Only SQL), des modèles alternatifs tels que des bases de données orientées documents ont été développés. L’objectif de ce mouvement était de développer de puissants concepts de bases de données pour les applications gourmandes en données.
Les bases de données orientées objet et les bases de données orientées documents se distinguent du schéma relationnel des bases de données surtout par la manière dont les données sont stockées ainsi que par leur accessibilité.
Le modèle de base de données orientée objet permet le stockage des données sous forme d’objets. La modulation des objets est analogue à la programmation orientée objet. Un objet définit une entité et contient :
Un objet est donc un groupe de données dans lequel l’interface est également définie pour accéder à ces données. Les objets appartiennent aux types de données abstraites.
Le système de gestion de bases de données orienté objet (SGBDO) attribue automatiquement un ID à chaque objet. Ceci permet d’identifier l’objet de manière unique d’y accéder à l’aide de méthodes. Cet ID d’objet est sans état, c’est-à-dire découplé des valeurs de l’objet. Il est ainsi possible de donner deux ID différents à deux objets avec les mêmes données (c’est-à-dire avec le même état). Ceci distingue clairement le modèle de base de données orienté objet du modèle relationnel, dans lequel chaque tuple peut être identifié par ses données (par exemple par une clé primaire).
Une autre caractéristique du modèle de base de données orientée objet est l’encapsulation de données. Les données enregistrées ne sont accessibles que par les méthodes définies précédemment. Les données encapsulées dans l’objet sont ainsi protégées contre les modifications via des interfaces indéfinies.
Les structures des bases de données sont définies dans le modèle de base de données orientée objet à l’aide d’un système de classification hiérarchique. Dans la programmation orientée objet, une classe est un ensemble d’objets ayant les mêmes caractéristiques. Chaque classe d’objets repose sur une définition de classe. Ce schéma spécifie les attributs et les méthodes de tous les objets de la classe et détermine ainsi la façon dont ils sont créés et modifiés.
Les utilisateurs interagissent avec la base de données orientée objet à l’aide d’un langage de requêtes de type SQL pour les bases de données orientée objets : l’Object Query Language (OQL). Le résultat d’une requête OQL n’est pas, comme pour SQL, un jeu de résultats, mais une liste d’objets qui correspondent aux conditions de l’instruction OQL.
Les implémentations connues du modèle de base de données orientée objet sont Realm, ZODB et Perst.
Les bases de données orientées objet ont été développées pour résoudre un problème de développement d’applications connu sous le nom d’Object-relational impedance mismatch.
Si des objets d’un langage de programmation orienté objet (par exemple C#, C++ ou Java) doivent être stockés dans une base de données relationnelle, des incompatibilités se produisent inévitablement. Elles sont dues à des différences fondamentales entre les deux paradigmes de programmation.
Une approche pour éviter les problèmes d’incompatibilité mentionnés ci-dessus consiste à renoncer aux bases de données relationnelles et à utiliser une base de données objet dans le cadre d’une programmation applicative orientée objet. Cependant, cela présente inévitablement l’inconvénient que les données encapsulées dans des objets ne sont pas disponibles indépendamment de l’application associée. En outre, les bases de bases de donnée objet ne sont pas très répandues. La plupart des outils et interfaces d’analyse de données sont encore conçus pour les bases de données relationnelles et ne prennent pas en charge le modèle de données orientées objet.
Cependant, les développeurs d’applications qui ne souhaitent pas se passer des avantages du stockage de données relationnelles peuvent compenser les incompatibilités en utilisant des mappeurs objet/relationnel. Les fonctionnalités de mapping objet-relationnel (ORM) sont implémentées via des bibliothèques. Elles créent une couche d’abstraction entre l’application orientée objet et les données stockées dans les tables.
De nombreux fabricants de systèmes de bases de données relationnelles équipent également leurs produits de fonctions qui compensent les incompatibilités avec la programmation orientée objet. Les systèmes de base de données de ce type sont appelés « objet-relationnel ».
Les bases de données orientées objet transfèrent les principes de base de l’orientation objet aux technologies de base de données et sont donc particulièrement adaptées à la programmation applicative orientée objet. Toutefois, les systèmes de bases de données correspondants sont rares et certains d’entre eux ne sont pas encore prêts pour le marché.
Un système de base de données relationnel-objet est un système de bases de données relationnelles qui a été étendu par des concepts d’orientation objet. Les principes éprouvés du modèle de bases de données relationnelles doivent donc être étendus aux types de données abstraites tels que les objets.
Afin de permettre la gestion des types de données abstraites, les bases de données relationnel-objet étendent le modèle de base de données relationnelles en :
Alors que les bases de données relationnelles sont essentiellement limitées aux types de données alphanumériques, les types de données définis par l’utilisateur peuvent également être utilisés pour gérer des fichiers multimédias complexes. Les constructeurs vous permettent de dériver de nouveaux types de données à partir des types de base existants. Comme le langage de base de données SQL ne permet pas de créer des fonctions, les systèmes de base de données relationnel-objet doivent fournir des extensions pour définir les fonctions d’accès et de traitement pour les types de données complexes.
Depuis le début des années 2000, des extensions relationnel-objet telles que les types structurés ont été incluses dans les nouvelles versions de la norme SQL. Toutefois, tous les SGBD ne les prennent pas en charge. Les systèmes de base de données bien connus qui fournissent les extensions correspondantes sont IBM Db2, Oracle Database et Microsoft SQL Server.
Alors que le stockage des données dans des bases de données relationnelles s’effectue dans des tables de base de données, le modèle de bases de données orientées document est basé sur une base de données hétérogène de documents individuels. Il peut s’agir de documents structurés tels que des fichiers JSON, YAML ou XML ainsi que des fichiers non structurés tels que des Binary Large Object (BLOBs) qui sont des fichiers image, vidéo ou audio.
Si des documents structurés sont disponibles, les données sont enregistrées sous forme de combinaisons clé/valeur. Une valeur concrète est attribuée à chaque clé. Dans ce contexte, le terme clé est utilisé comme synonyme du terme attribut et n’a rien à voir avec les clés du système de base de données relationnelles. Les valeurs peuvent être n’importe quelle information. Les listes et les tables avec des données imbriquées sont également des valeurs possibles.
Par exemple, un document au format JSON (Notation des objets JavaScript) qui est utilisé pour stocker les données des employés peut ressembler à ceci :
{
"id" : 1,
"nom" : "Dupond",
"prénom" : "Jacques",
"numéro de sécurité sociale" : "25 120512 S 477",
"rue" : "Grand Boulevard 1",
"code postale" : "11111",
"ville" : " Lacité ",
"v_id" : [1, 4]
}Plusieurs documents peuvent être regroupés pour former des collections de documents. Le document de l’employé affiché peut, par exemple, être « employé » avec d’autres parties de la collection.
Les requêtes sont réalisées à l’aide de fonctions, par exemple via JavaScript. Même les systèmes de gestion de base de données qui fonctionnent orientés document attribuent un identifiant unique à chaque document. Cependant, contrairement au modèle de bases de données relationnelles, il n’existe pas de schéma de base de données qui couvre l’ensemble de la base de données. Les documents d’une base de données basée sur des documents n’ont pas besoin d’être conformes à une forme normale, et il n’existe pas non plus de caractéristiques structurelles prédéfinies qui doivent s’appliquer à tous les documents. En principe, chaque document peut avoir une structure différente. Toutefois, dans le contexte du développement d’applications, il est conseillé de créer des documents dans un schéma correspondant à l’application afin de créer la condition préalable aux requêtes ciblées.
Les relations telles que la liaison de tables de base de données dans le modèle de base de données relationnelle ne peuvent pas être implémentées avec des bases de données orientées document. Bien qu’il soit possible de saisir manuellement l’ID d’un document comme référence dans un autre document, les systèmes de gestion de base de données orientée document n’offrent pas de JOINs. Vous devrez donc programmer vous-même les options de requête correspondantes.
Les systèmes de bases de données orientées documents sont particulièrement adaptés au traitement de grandes quantités de données à structure hétérogène et à faible mise en réseau. Ce modèle de stockage de données est donc particulièrement utile pour les données de grandes taille.
Les systèmes de bases de données relationnelles garantissent que les conditions spécifiées dans les définitions des tables sont remplies à tout moment. Ceci conduit à des vitesses d’écriture relativement lentes lors du traitement de grandes quantités de données. Les systèmes de bases de données NoSQL n’ont pas d’exigences aussi strictes en matière de cohérence des données et sont donc adaptés aux grandes architectures dans lesquelles de nombreuses instances de bases de données sont exploitées en parallèle.
Les applications Web utilisent également de plus en plus de bases de données orientées documents. Si, toutefois, un réseautage solide est nécessaire, le stockage de données documentaires est associé à un effort accru. Dans ce cas, les utilisateurs devraient mieux utiliser les systèmes de bases de données relationnelles.
BaseX, CouchDB, eXist, MongoDB et RavenDB sont des exemples de bases de données orientées documents.
Les bases de données relationnelles ne se sont pas imposées sans raison comme une norme de facto dans le traitement électronique des données. Les points suivants s’appliquent au modèle de bases de données relationnelles.
Selon le scénario dans lequel les systèmes de bases de données relationnelles sont utilisés, des avantages tels que le modèle de données simple basé sur des tables et la division des données en plusieurs tables liées peuvent également être interprétés comme des inconvénients. En outre, les caractéristiques centrales du modèle des bases de données relationnelles sont difficiles à concilier avec les exigences modernes de programmation des applications (telles que l’orientation objet, le multimédia et les données de grande taille).
Le schéma relationnel des bases de données est clair, mathématiquement solide et a fait ses preuves dans la pratique depuis plus de 40 ans. Pourtant, le stockage des données dans des tables structurées ne répond pas à toutes les exigences des technologies modernes de l’information.
L’administration de grandes quantités de données dans le cadre de grandes analyses de données et le stockage de types de données abstraits poussent surtout les systèmes relationnels classiques à leurs limites. C’est là que les systèmes spécialisés tels que les bases de données orientées objet ou les concepts développés dans le cadre du mouvement NoSQL marquent des points. Cependant, le modèle de bases de données relationnelles ne peut pas être complètement amorti. Les bases de données relationnelles offrent de nombreux avantages, en particulier dans les domaines d’activité où le traitement des données de transaction est au premier plan.
Les données relatives aux campagnes clients ou aux mesures de marketing peuvent idéalement être stockées dans des systèmes tabulaires. Les utilisateurs bénéficient également d’une syntaxe qui permet des requêtes complexes malgré sa simplicité.
Ceux qui travaillent au développement de logiciels, connaissant bien le concept de CRUD. Cet acronyme englobe les opérations classiques pour la communication avec les systèmes de base de données qui constituent par défaut la base de la gestion des données. Mais comment peut-on configurer exactement ces fonctions d’accès à la gestion des données ? Et quel rôle jouent les langues de programmation et...
L’une des forces du modèle de base de données relationnelle est la capacité à stocker les informations dans des tables de base de données distinctes structurées selon des relations sémantiques. Ce concept, connu sous le nom de normalisation, est la base pour garder le moins de redondances de données possible, mais nécessite un mécanisme pour fusionner les données de différentes tables pour les...
Les bases in memory permettent l’analyse et la mise à disposition de mégadonnées en temps réel. La rapidité d’accès est obtenue en stockant les données dans la mémoire vive, contrairement aux bases traditionnelles qui utilisent le disque dur. Quelles sont les autres différences entre les bases in memory et les bases de données traditionnelles ? Quelles bases de données in memory devez-vous...
Le système de gestion de base de données PostgreSQL, connu sous le nom de Postgres, possède des décennies d’histoire de développement. Initialement lancée comme projet à l’Université de Berkeley, la base de données open source résiste toujours à la concurrence commerciale car l’équipe de développement travaille en permanence sur sa fonctionnalité et ses performances. Mais qu’est-ce que PostgreSQL...
Habituellement, les bases de données sont fondées sur des lignes de données. Les bases de données orientées colonnes inversent ce système : plutôt que d’enregistrer chaque entrée l’une après l’autre, elles sont stockées catégorie par catégorie. Cela permet un gain de rapidité décisif pour les gros volumes de données. Mais comment fonctionnent ces bases de données ?
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
