schéma de base de données pour suivre les paramètres aléatoires dans le site Web pour la commercialisation

Question

je Flex à base de consommateurs website où je voudrais changer divers look and feel paramètres de type en fonction de critères aléatoires et d'autres, puis suivre ces jusqu'à ce que les résultats dans la plupart des ventes . Par exemple, je pourrais changer complètement la page d'accueil, montrer des choses différentes selon l'origine des gens. Je pourrais montrer ou cacher certaines fonctionnalités, ou changer certains textes. Les choses que je pourrais changer sont encore indéfinies et deviendront probablement assez compliquées.

Je veux concevoir le schéma de base de données le plus flexible mais il doit être efficace et facile à chercher. Actuellement, j'ai une table 'SiteVisit' qui contient des informations sur chaque visiteur distinct.

Je veux trouver le bon équilibre entre une seule table avec des colonnes pour chaque paramètre, et une table contenant juste des paires de valeurs clés.

Des suggestions?

Answer 1

Ok, c'est très difficile. La raison pour moi de dire que parce que vous demandez deux choses:

• schéma du référentiel détendu de sorte que vous pouvez stocker diverses données et modifier ce qui est enregistré dynamiquement plus tard
• schéma de base de données fixe de sorte que vous pouvez interroger efficacement les données

La solution sera un compromis. Vous devez comprendre cela.

Supposons que vous avez la table de l'utilisateur:

+---------------- 
| User 
+---------------- 
| UserId (PK) 
| ... 
+---------------- 

1) approche blob XML Vous pouvez sauvegarder vos données comme un blog (grand XML) dans une table (en fait un sac de propriété), mais l'interrogation (filtrage) sera un cauchemar. L'avantage est que vous (la logique métier) possédez le schéma. C'est en même temps un inconvénient de cette solution. Un autre inconvénient énorme est que l'interrogation/filtrage sera extrêmement difficile et lent!

2) Tableau par propriété Une autre solution consiste à créer une table spéciale par propriété (page d'accueil, etc.). Cette table contiendrait une valeur par utilisateur (realship basé sur FK à la table User). L'avantage de cette approche est que vous pouvez très rapidement voir toutes les valeurs pour cette propriété. Inconvénient: vous aurez trop de tables (une par propriété personnalisée) et vous joindrez souvent les tables lors des opérations de requête.

3) Table CustomProperty Dans cette solution, vous avez une table contenant toutes les propriétés personnalisées.

+---------------- 
| CustomPropertyEnum 
+---------------- 
| PropertyId (PK) 
| Name of type string 
+---------------- 

+---------------- 
| CustomProperty 
+---------------- 
| PropId (PK) 
| PropertyId (FK) 
| UserId (FK) 
| Value of type string 
+---------------- 

Dans cette solution, vous stockez toutes les propriétés personnalisées dans une table. Vous disposez également d'une table d'énumération spéciale qui vous permet d'interroger plus efficacement les données. L'inconvénient est que vous joindrez des tables souvent pendant les opérations de requête.

Choisissez par vous-même.Je déciderais entre 2 et 3 selon votre charge de travail (très probablement 3 car c'est plus facile).

Answer 2

Ceci est un cas classique pour l'utilisation d'une base de données NoSQL. Il pourrait être utilisé pour stocker diverses paires de valeurs clés facilement et sans aucun schéma prédéfini.