Les tables sont des entités beaucoup plus complexes que les lignes et la gestion de la création d'une table est beaucoup plus complexe qu'une insertion qui doit se conformer à un modèle existant, la table. Il est vrai que l'instruction de création d'une table est une opération SQL standard, mais le fait de dépendre de la création dynamique de ces tables relève d'une mauvaise décision de conception.
Maintenant, si vous créez juste un ou deux et c'est tout, ou une base de données entière dynamiquement, ou à partir d'un script une fois, cela pourrait être ok. Mais si vous dépendez de la nécessité de créer de plus en plus de tables pour gérer vos données, vous devrez également joindre de plus en plus et interroger de plus en plus. Un problème très sérieux que j'ai rencontré avec une application qui utilisait la création dynamique de tables est qu'une seule requête SQL Server ne peut impliquer que 255 tables. C'est une contrainte intégrée. (Et c'est SQL Server, pas CE.) Il a suffi de quelques semaines en production pour que cette limite soit atteinte et que l'application ne fonctionne plus.
Et si vous vous mettez à modifier les tableaux, par exemple en ajoutant ou en supprimant des colonnes, le casse-tête de la maintenance s'aggrave encore. Il y a aussi la question de la liaison entre les données de votre base de données et la logique de votre application. Un autre problème est la mise à niveau des bases de données de production. Ce serait un véritable défi si une base de données avait été enrichie d'objets de manière dynamique et que vous deviez soudainement mettre à jour le modèle.
Lorsque vous devez stocker des données d'une manière aussi dynamique, la pratique standard est de faire appel à Modèles de VAE . Vous disposez de tables fixes et vos données sont ajoutées dynamiquement sous forme de lignes, de sorte que votre schéma ne doit pas changer. Il y a bien sûr des inconvénients, mais c'est généralement considéré comme une meilleure pratique.
