L'intégration d'une structure de données dans un champ peut fonctionner pour des cas simples, mais cela vous empêche de tirer parti des bases de données relationnelles. Les bases de données relationnelles sont conçues pour rechercher, mettre à jour, supprimer et protéger vos données. Avec un champ intégré contenant ses propres wad-o-data (tableau, JSON, xml, etc.), vous finissez par écrire tout le code pour le faire vous-même.
Il y a des cas où le champ intégré pourrait être plus approprié, mais pour cette question à titre d'exemple, je vais utiliser un cas qui met en évidence les avantages d'une approche de table liée.
Imaginez un exemple d'utilisateur et de publication pour un blog.
Pour une solution de publication intégrée, vous auriez un tableau comme celui-ci (psuedocode - ce ne sont probablement pas des ddl valides) :
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Avec des tables liées, vous feriez quelque chose comme
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Outils de mappage objet-relationnel (ORM) :Avec la publication intégrée, vous écrirez le code manuellement pour ajouter des publications à un utilisateur, naviguer dans les publications existantes, les valider, les supprimer, etc. Avec la conception de table séparée, vous pouvez tirer parti de l'ActiveRecord (ou de tout autre système relationnel utilisez) des outils pour cela qui devraient garder votre code beaucoup plus simple.
Flexibilité :Imaginez que vous vouliez ajouter un champ de date à la publication. Vous pouvez le faire avec un champ intégré, mais vous devrez écrire du code pour analyser votre tableau, valider les champs, mettre à jour les messages intégrés existants, etc. Avec la table séparée, c'est beaucoup plus simple. De plus, supposons que vous souhaitiez ajouter un éditeur à votre système qui approuve tous les messages. Avec l'exemple relationnel, c'est facile. Par exemple, pour trouver tous les messages édités par 'Bob' avec ActiveRecord, il vous suffirait de :
Editor.where(name: 'Bob').posts
Pour le côté intégré, vous devrez écrire du code pour parcourir chaque utilisateur de la base de données, analyser chacun de leurs messages et rechercher "Bob" dans le champ de l'éditeur.
Performances :Imaginez que vous ayez 10 000 utilisateurs avec une moyenne de 100 messages chacun. Maintenant, vous voulez trouver tous les messages publiés à une certaine date. Avec le champ intégré, vous devez parcourir chaque enregistrement, analyser l'ensemble du tableau de tous les articles, extraire les dates et vérifier celle que vous voulez. Cela va mâcher à la fois le processeur et le disque i/0. Pour la base de données, vous pouvez facilement indexer le champ de date et extraire les enregistrements exacts dont vous avez besoin sans analyser chaque message de chaque utilisateur.
Normes :L'utilisation d'une structure de données spécifique à un fournisseur signifie que le déplacement de votre application vers une autre base de données peut être pénible. Postgres semble avoir un riche ensemble de types de données, mais ils ne sont pas les mêmes que MySQL, Oracle, SQL Server, etc. Si vous vous en tenez aux types de données standard, vous aurez beaucoup plus de facilité à échanger les backends.
Ce sont les principaux problèmes que je vois d'emblée. J'ai fait cette erreur et j'en ai payé le prix, donc à moins qu'il y ait une raison super impérieuse de faire autrement, j'utiliserais le tableau séparé.
