Configuration de la base de données Rails Polymorphism

Question

Nous devons créer un système de requête qui aura environ 10 types de requêtes différents. Toutes ces demandes appartiendront à l'aspect «comptabilité» de notre application. Nous les avons donc appelés "demandes de comptabilité".

Toutes les demandes ne partagent peut-être que quelques colonnes et chacune a jusqu'à 20 colonnes individuellement. Nous avons commencé à nous demander si avoir des tables séparées pour chaque type de requête serait pratique en termes de vitesse lorsque nous commençons à faire des jointures ou des requêtes très compliquées, par exemple, extraire TOUS les types de requêtes dans une seule table puis trier il. Peut-être serait-il plus simple d'utiliser l'héritage de table unique, car il aura une colonne de type et nous utiliserons une table pour stocker les 10 types de demandes de comptabilité. Que pensez-vous de l'utilisation de l'ITS pour ces nombreuses associations et exigences polymorphes?

Essentiellement, il aurait des modèles comme ceci:

AccountingRequest 
BillingRequest < AccountingRequest 
CheckRequest < AccountingRequest 
CancellationRequest < AccountingRequest 

Chaque sous-classe a à peu près 10+ champs.

---

en train de lire à propos de Multiple Héritage de Table here. Cela semble être la solution qui correspond à mes besoins dans ce cas. Pas encore sûr cependant.

Answer 1

STI est un bon ajustement si vos modèles partagent tous les mêmes attributs.

Cependant, si vos sous-classes commencent à avoir des attributs spécifiques et ne s'appliquent pas aux autres, alors STI peut générer un grand nombre de colonnes nulles. Dans ce cas, je préfère généralement aller avec l'association polymorphe.

Cet épisode railscast est un excellent exemple de la différence entre les 2

Answer 2

Cela semble faisable.

Lorsque j'ai examiné cette question, j'ai constaté que l'utilisation intensive d'objets de valeur aidait à contrôler la non-applicabilité de certains attributs à certains types.

Dans mon cas, j'avais des types de produits, dont certains n'auraient pas de mesures particulières par exemple. Dans ces cas, j'ai utilisé un objet nul pour indiquer "Non applicable", le cas échéant.

Edit: J'ai aussi trouvé la syntaxe composed_of très pratique: https://apidock.com/rails/ActiveRecord/Aggregations/ClassMethods/composed_of

Answer 3

Vous pouvez utiliser des IST dans cette situation. Mais faire STI exigera toutes les colonnes dans une seule table et ce n'est pas la bonne idée. La table ira très grand dans le nombre de champs.

Je pense que vous devriez diviser en deux tables comme comme ci-dessous ...

1. Demande: Une table de demande sera la table polymorphique qui a sauvé les informations pour le type de demandes. RequestItem: La table des éléments de la requête enregistrera tous les enregistrements de 20 champs dans la table et aura une clé étrangère de la table de requête. La table d'élément de requête aura deux champs dans la base de données appelés key et value.

Answer 4

Pour l'instant j'utilise un peu de NoSQL pour de tels cas. Le type Postgresql's JSONB permet de stocker du hash rubis à plusieurs niveaux. Il fournit également des fonctionnalités riches: contraintes de niveau de base de données, index et opérateurs de requête.

Les attributs communs sont stockés de manière standard et spécifique à l'enfant - dans jsonb.Vous pouvez ensuite utiliser tout ce dont vous avez besoin: STI, pattern Value Objects, sérialisation ou simplement créer des étendues pour chaque enfant. Je préfère le dernier - mes modèles sont minces, la plupart des contraintes sont au niveau DB et toute la logique métier est dans les classes de service.

Plus:

1. Éviter alter table sur de grandes tables quand le besoin d'ajouter un type enfant
2. Garder mes requêtes efficaces
3. Prévention de stockage et sélectionner des colonnes inutiles
4. sérialisation de la boîte pour les API JSON

Moins:

1. Un peu de
sans schéma
2. verrouillage Fournisseur