Les bases de données relationnelles sont conçues pour stocker plusieurs lignes par table. Il existe tout un tas de mécanismes pour faciliter les grands tableaux, tels que :
- Index sur n'importe quelle combinaison de champs pour accélérer les recherches
- Mise en cache des pages afin que les pages couramment utilisées restent en mémoire
- Partitionnement vertical (bases de données en colonnes) pour accélérer davantage les requêtes
- Algorithmes avancés tels que les jointures par hachage et les groupes par (au moins dans les bases de données autres que MySQL)
- Utilisation de plusieurs processeurs et disques pour traiter les requêtes
Il y a une chose qui est plus difficile lorsque l'on place des données dans une seule table, c'est la sécurité. Et, en fait, dans certaines circonstances, il s'agit d'une préoccupation majeure et nécessite essentiellement que les données soient placées dans un tableau séparé. Ces applications sont rares et espacées.
Pour donner un exemple de la mauvaise qualité du stockage des données dans plusieurs tables, imaginez que dans votre système, vous ayez un enregistrement par entreprise et que vous le stockiez dans une table. Cet enregistrement stocke des informations sur l'entreprise -- quelque chose comme le nom, l'adresse, peu importe. L'appel correspond à 100 octets d'informations.
Dans votre schéma, il existe une table distincte pour chaque "entreprise", c'est-à-dire une ligne par table. Cet enregistrement résidera sur une page de données. Une page de données peut faire 16 Ko, vous gaspillez donc environ 15,9 Ko pour stocker ces données. Le stockage de 1000 de ces enregistrements occupe 16 Mo au lieu d'environ 7 pages (112 Ko). Cela peut être un impact significatif sur les performances.
De plus, avec plusieurs tables, vous ne tenez pas compte des défis liés à la maintenance de toutes les tables et à la garantie de l'exactitude des données dans les différentes tables. Les mises à jour de maintenance doivent être appliquées à des milliers de tables, au lieu d'une poignée.
