Modifications du schéma de base de données nécessaires chaque année. Quelle stratégie devrait être utilisée?

Question

Chaque année, notre société organise une conférence/stand où les participants peuvent montrer leurs produits.

Nous avons une application web qui permet aux participants de s'inscrire à la conférence. Ils peuvent entrer des informations telles que le nom de leur société, les informations de facturation, etc.

Il semble que les exigences relatives à l'information que les participants doivent entrer varient d'une année à l'autre. I.E, un an, les participants pourraient avoir besoin d'entrer la taille du stand qu'ils veulent, l'année suivante, ce n'est plus nécessaire, et ainsi de suite. Une année, il vous suffira peut-être d'entrer un nombre total de m^2 que vous voulez, tandis que l'année suivante, vous devrez peut-être ajouter la longueur, la hauteur et le nombre d'étages que vous voulez.

Au cours de ces années, le schéma de base de données est devenu complètement fou. Nous avons maintenant beaucoup de champs et de tables "obsolètes" dans notre base de données, et cela commence à avoir l'air assez compliqué. Pour des raisons historiques, nous ne pouvons pas simplement réinitialiser le schéma aux bases pour chaque année. Nous pourrions avoir besoin de certaines données des anciennes conférences. Donc: Est-ce que quelqu'un a une bonne idée sur la façon dont nous pouvons faire face à cette situation? Les seules solutions que je peux penser sont

• Version notre base de données pour chaque conférence à savoir
• tous les magasins de l'information « variant » comme xml

Si quelqu'un a quelque chose de bon litterature pour savoir comment gérer des bases de données évolutives et traiter des données obsolètes, ce serait bien!

Answer 1

Bien que je déteste dire cela, cela pourrait être le cas où la structure entité-valeur-attribut fonctionnerait le mieux.

http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

Noter ce n'est pas un modèle à utiliser à la légère, il y a des problèmes importants avec elle. Mais ceci est le genre de problème qu'il est conçu pour résoudre.

Answer 2

Je considérerais l'utilisation d'une approche de nom-valeur pour toutes les données étendues. Essentiellement, vous définissez vos données statiques d'année en année. Ce sera des choses comme les informations de l'entreprise, la définition d'une adresse par exemple ne change pas année après année. Ceux-ci seront modélisés normalement.

Ensuite, vous définissez une table qui contiendra un maître de toutes les questions que vous avez, et sera liée d'une manière ou d'une autre pour vous dire en quelle année ces questions sont valides. Cette table peut également indiquer d'autres attributs de la question qui pourraient vous permettre de créer dynamiquement une interface graphique. Des choses telles que des expressions régulières pour valider le type de données, etc.

Voici une approche vraiment naïve qui même après avoir fait cela ne serait pas l'état final de ce que je modéliserais (j'aurais probablement une autre table qui correspond à une année à une question, et c'est ce que je lierais aussi à l'entreprise, de cette façon nous pourrons réutiliser des questions à plusieurs reprises).

Note: I have a picture to go along with tihs need to find a place to upload it too...Will edit soon as I get that up http://i40.tinypic.com/1582ih2.png

Answer 3

« Nous avons maintenant beaucoup de champs et de tables « obsolètes » dans notre base de données, et il commence à sembler tout à fait désordre. Pour des raisons historiques, nous ne pouvons pas simplement réinitialiser le schéma de retour à l'essentiel pour Nous pourrions avoir besoin de certaines données des anciennes conférences.

Si vous en avez besoin, ils ne sont pas obsolètes.

Je coderais le frontal de manière générique cependant. Cela signifie avoir un système capable de gérer toute forme de configuration de la zone de stand (dans l'exemple que vous donnez), et peut-être plus dans le futur si cela devait se produire. Si vous avez des tables comme "standarea" (zone en m^2), "taille" (longueur, largeur, hauteur, etc) - alors vous auriez des objets dans votre modèle pour les faire correspondre (StandArea, StandSize) - ceux-ci pourraient tous deux étendre une classe de base commune StandData.

Une année, une table reçoit un ensemble de données, l'année suivante une autre table reçoit les données. Votre DAO va essayer de charger chaque objet de chaque table (par un parent, err, stand_uid) et ensuite définir le champ StandData dans votre objet "ConferenceApplication" à tout ce qu'il a découvert.

L'autre option consiste à avoir tous les champs possibles dans une seule table et à les laisser vides.