Quelle est une bonne approche pour permettre aux utilisateurs de définir leurs propres types personnalisés?

Question

Supposons que vous concevez une application qui, par nécessité, offre à l'utilisateur la possibilité de créer des types personnalisés (pour gérer ses données, quelles qu'elles soient). Une façon de gérer cela est de définir un schéma qui nous permet d'utiliser des métadonnées pour définir ces types. Cela signifie souvent que le schéma db résultant aura un moyen de stocker des paires clé/valeur (les propriétés appartenant à une instance d'un type), où la partie valeur est généralement stockée sous forme de chaîne (quel que soit le type de données sous-jacent de la colonne). Cela seul présente un certain nombre de problèmes. J'ai lu que somefrown upon en utilisant un db pour suivre les paires clé/valeur.

Le principal problème que j'ai avec elle est de savoir comment cela affecte les requêtes. Par exemple, supposons que l'utilisateur souhaite créer un type appelé Event ayant ces colonnes: event_name, description, start_at et end_at (datetimes). L'utilisation de paires clé/valeur où toutes les valeurs sont des chaînes rend les requêtes plus sensibles à la façon dont les valeurs des paramètres sont formatées; par conséquent, l'interrogation d'un ensemble d'événements compris entre deux dates n'est pas aussi simple que si nous utilisions des colonnes datetime réelles. Cela m'incite à envisager d'autres conceptions qui pourraient accommoder des types personnalisés. Le premier qui m'est venu à l'esprit et qui m'a le plus plu était d'utiliser la base de données elle-même pour définir ces types personnalisés. C'est-à-dire, plutôt que de créer un ensemble séparé de méta-tables dans lesquelles tous les types doivent être définis, laissez simplement à l'utilisateur un privilège limité de créer/modifier ses propres tables dans la base de données (par exemple: usertable-johndoe-album). Le problème le plus important que je vois avec cette approche est le grand nombre de tables qui pourraient éventuellement exister. Je me demande si la plupart des bases de données open-source (MySQL, PostgreSQL, etc.) ont une limite stricte ou pratique sur le nombre de tables qu'elles peuvent gérer sans être entravées. Autrement dit, je sais que la plupart des bases de données prêtes pour la production sont réglées pour gérer des millions d'enregistrements, mais je ne sais pas si elles sont équipées pour gérer des centaines de milliers de tables. Est-ce que quelqu'un sait?

Étant donné la nécessité de permettre aux utilisateurs de créer leurs propres types, préférez-vous les paires clé/valeur ou l'utilisation de la base de données elle-même? Ou si vous avez un autre modèle/idée, s'il vous plaît décrire.

Answer 1

En ce qui concerne votre deuxième idée (hypothèse est que lorsque vous créez usertable-johndoe-album sa structure est un miroir d'une table base-album sous-jacent): Une chose que je dirais est de ne pas créer de nouvelles tables pour chaque utilisateur. Sinon, si vous devez changer la structure de la table sous-jacente dans le futur (pour les correctifs de maintenance, par exemple), vous devrez alors propager la même modification à TOUTES les tables créées par les utilisateurs. Vous pourriez être en mesure de trouver un moyen intelligent d'automatiser cela, mais il ouvre encore la porte à beaucoup plus de problèmes potentiels, IMO (sans compter les limites supérieures strictes des numéros de table). Je pense que les métabaliers sont la meilleure façon d'aborder cette question. Il peut être possible de créer automatiquement des vues sur les types que l'utilisateur définit, cela peut simplifier l'interrogation des métadonnées. Vous pouvez également envisager d'avoir plus que des clés et des valeurs dans la table clé/valeur. Avoir un userID vous permettrait d'indexer par UserID et cela pourrait aider avec des problèmes de performance.

Answer 2

« Compte tenu de l'exigence pour permettre aux utilisateurs de créer leurs propres types, »

« préférez-vous des paires clé/valeur » dépend. Dans le cas général, décrit ci-dessus, cela pourrait être un problème. Dans le cas spécifique de l'ajout de quelques colonnes (décrites dans les commentaires sur cette réponse), c'est la solution évidente et simple.

"ou d'utiliser la base de données elle-même" En quelque sorte. "Le problème le plus important que je vois avec cette approche est le grand nombre de tables qui pourraient finalement exister" Ceci est largement hors de propos - vous n'avez aucune preuve réelle du nombre de types définis par l'utilisateur. Lorsque vous autorisez les utilisateurs à ajouter leurs propres types, vous créez un cadre. Pas une application.

Vous avez des choses à l'appui de vos types intégrés.

Vous disposez d'outils et d'utilitaires prenant en charge des types d'extension supplémentaires.

Les "utilisateurs" se contentent de brancher leur code dans votre framework.

"Mais je veux que les utilisateurs finaux, pas les programmeurs utilisent cela". Mauvaise idée.Civil, les non-programmeurs ne créeront pas leurs propres types. Seuls les programmeurs sont équipés pour comprendre les concepts en créant leurs propres types.

Depuis que vous créez un cadre, essayez et simplifiez les choses afin que les programmeurs puissent ajouter leurs propres types sans douleur.

Answer 3

Je doute que vous atteigniez une limite de table maximale car ils sont généralement liés aux limitations du système d'exploitation plutôt qu'aux limitations du SGBDR. Cependant, il existe une autre approche de modélisation appelée EAV model qui est essentiellement une façon générique de décrire les entités personnalisées et les colonnes associées (attributs). Il y a quelques inconvénients, mais il semble que cela pourrait être un bon ajustement pour vos besoins.

Si vous optez pour des tables personnalisées, j'opterais pour des espaces de noms plutôt que des préfixes de table pour séparer des entités spécifiques à un utilisateur/groupe.

Answer 4

Une autre façon de permettre à un utilisateur final de créer ses propres types est d'utiliser quelque chose appelé aspect programming.

En effet, vous créez un certain nombre d '"aspects" que l'utilisateur combine pour créer son type. Ces aspects ne sont généralement pas créés par l'utilisateur final, mais ils sont fournis par vous, mais l'utilisateur peut combiner les aspects pour créer de nouveaux types.

Exemple:

Dans le traitement numérique, vous pouvez avoir des « objets » dans votre système connecté à la ligne physique/contrôleurs/mètres. Disons qu'un objet est connecté à un thermomètre de sorte que l'objet montre la température actuelle. Le type à partir duquel l'objet a été créé contient un certain nombre d'aspects (sorte de propriétés similaires de l'objet), l'un de ces aspects pourrait être par exemple un affichage pour montrer la valeur - temp. dans ce cas. Chaque fois que l'utilisateur veut connecter un temp. mètre, il inscrivait un objet de ce type et le configurait pour se connecter au compteur physique (en utilisant les aspects).

Maintenant, si l'utilisateur final peut vouloir faire quelque chose de plus, dites qu'il veut ajouter un graphique pour montrer la température. pour les dernières lectures 24h (histoire) - à condition qu'il y ait un aspect pour cela - il peut créer un nouveau type en héritant du type mentionné précédemment et ajouter l'aspect historique au nouveau type. Donc ce qu'il a fait, c'est qu'il a créé un nouveau type. Il peut alors au lieu d'utiliser le type d'origine utiliser ce nouveau type lors de l'instanciation d'un temp. objet. Cela permet une gestion très dynamique des types.