Jointure sur 4 tables

Bonjour,

j’ai un modèle relationel qui comporte une table de jointure sur 4
tables (applications, types d’application, serveurs, roles)…
Je ne sais pas si rails sait gérer nativement ce genre de jointure.

Est-ce que je peux utiliser “has_and_belongs_to_many” avec une jointure
de ce type ?
Comment est-ce que je dois nommer cette table?
Est-ce que l’option “:include” est la solution?

Merci!

rectification, il s’agirait plutot d’une jointure sur 3 tables mais le
problème reste le même :slight_smile:

J’ai un modèle relationel qui comporte une table de jointure sur 4
tables (applications, types d’application, serveurs, roles)…
Je ne sais pas si rails sait gérer nativement ce genre de jointure.

Est-ce que je peux utiliser “has_and_belongs_to_many” avec une jointure
de ce type ?

En fait, une relation has_and_belongs_to_many correspond à une relation
n-n.
Donc oui à priori, elle convient bien à ton problème.

Comment est-ce que je dois nommer cette table?

Tu dois la nommer en assemblant tous les noms des tables concernées
séparées
par une tiret bas “_”. Rails préconise l’ordre alphabétique pour les
tables
de jointures.

Est-ce que l’option “:include” est la solution?

Là je ne saurai te répondre (étant moi même un débutant sur Rails).

PS: Une table de jointure à 4 niveaux n’est vraiment pas recommandé. Je
vois
que tu es repassé sur un triplet, ce qui est le maximum recommandé en
conception de base de données.

J’ai l’impression que je suis obligé d’avoir une jointure sur 4 tables
car dans les règles que l’on m’a donné j’ai un triplet “Serveur -
Application - Type” qui peut avoir plusieurs rôles…

Serveur1 - Application1 - Type1 – Role1
Serveur1 - Application1 - Type1 – Role2

Serveur2 - Application1 - Type1 – Role1
Serveur2 - Application2 - Type1 – Role1

Toutes les associations sont possibles! Ca me donne bien une jointure Ã
4 niveaux non??
Mais je ne suis peut-être pas dans le bon forum je pense :slight_smile:

Toutes les associations sont possibles! Ca me donne bien une jointure à 4
niveaux non??

En effet tout est possible, c’est pour ça qu’il y a énormément d’usines
Ã
gaz …

Les associations n-aires (non binaires, donc portant sur plus que 2
tables)
sont des cas rares. Il est même conseiller d’essayer de les transformer
en
associations binaires.

Reflechit un peu plus à ton model de données, ça me parait vraiment
bisard
que tu te retrouves avec une association n-aire associée à 4 tables.

Vincent J. wrote:

J’ai un modèle relationel qui comporte une table de jointure sur 4
tables (applications, types d’application, serveurs, roles)…
Je ne sais pas si rails sait gérer nativement ce genre de jointure.

Est-ce que je peux utiliser “has_and_belongs_to_many” avec une jointure
de ce type ?

En fait, une relation has_and_belongs_to_many correspond à une relation
n-n.
Donc oui à priori, elle convient bien à ton problème.

Comment est-ce que je dois nommer cette table?

Tu dois la nommer en assemblant tous les noms des tables concernées
séparées
par une tiret bas “_”. Rails préconise l’ordre alphabétique pour les
tables
de jointures.

Est-ce que l’option “:include” est la solution?

Là je ne saurai te répondre (étant moi même un débutant sur Rails).

PS: Une table de jointure à 4 niveaux n’est vraiment pas recommandé. Je
vois
que tu es repassé sur un triplet, ce qui est le maximum recommandé en
conception de base de données.

Entre temps je suis repassé sur une jointure à 4 niveaux donc j’en
déduit que mon modèle n’est pas bon :slight_smile:

Eh bien je sais quoi faire pour finir la journée :slight_smile:

Salut arnaud,

Etant donné que c’est pour une toute petite utilisation en interne et
que je ne suis pas un un pro dans ce domaine, je vais me contenter
de ça pour l’instant…
Je souhaite surtout avancer sur rails histoire de le prendre en main!

Je continue donc avec ma table de jointure sur 4 niveaux meme si ca
fera grincer des dents les puristes :slight_smile:

Je te propose de travailler sur cette idée.

pseudo-code

class Application < AR::B
has_many :configs
end

class Server < AR::B
has_many :configs
end

class Role < AR::B
has_many :configs
end

class Type < AR::B
has_many :configs
end

class Config < AR::B
belongs_to :application
belongs_to :server
belongs_to :role
belongs_to :type
end

(je mets pseudo-code, car je n’ai pas vérifié et tu auras sûrement
des soucis en appelant un modèle Type ; de même Application
n’est pas top comme nom)

Après tu peux peut-être t’amuser à utiliser :through
ce qui se réécrit :

class Application < AR::B
has_many :configs
has_many :servers, :through => :configs
has_many :types, :through => :configs
has_many :roles, :through => :configs
end

Pareil pour les autres (un peu fainéant sur ce coup-là ).

Après pour s’assurer qu’une Config est unique, mmmhh faut
ptêtre regarder du côté de validates_uniqueness_of avec :scope.

Bon je te laisse peaufiner ma solution.

-- Jean-François.

Vincent J. wrote:

Toutes les associations sont possibles! Ca me donne bien une jointure à 4
niveaux non??

En effet tout est possible, c’est pour ça qu’il y a énormément d’usines
Ã
gaz …

Les associations n-aires (non binaires, donc portant sur plus que 2
tables)
sont des cas rares. Il est même conseiller d’essayer de les transformer
en
associations binaires.

Reflechit un peu plus à ton model de données, ça me parait vraiment
bisard
que tu te retrouves avec une association n-aire associée à 4 tables.

Etant donné que c’est pour une toute petite utilisation en interne et
que je ne suis pas un un pro dans ce domaine, je vais me contenter de ça
pour l’instant…
Je souhaite surtout avancer sur rails histoire de le prendre en main!

Je continue donc avec ma table de jointure sur 4 niveaux meme si ca fera
grincer des dents les puristes :slight_smile:
En attendant, j’ai nommé ma table (accrochez vous :slight_smile:
apps_roles_servers_types…
J’ai ensuite essayé d’utiliser la commande scaffold sans succès.

ruby scripts/generate scaffold AppRoleServerType Testor

error Before updating scaffolding from new DB schema, try creating a
table for your model (AppRoleServerType)

C’est le nom du modèle qui est incorrect ou celui de la table?

Encore merci pour vos réponses!

ruby scripts/generate scaffold AppRoleServerType Testor

Alors pour commencer je ne vois pas trop l’intérêt du Scaffold dans ce
cas:
Scaffold = Model + Controller + Views (CRUD: Create, Read, Update et
Delete)

Tu devrais plutôt générer juste le modèle (ruby scripts/generate
ModelName)

Deuxièmement, je ne suis pas encore tomber dans le cas d’une association
nécessitant une table de jointure, donc je ne peux pas t’aider sur ce
point.

Sinon concernant l’utilisation de la relation “has_and belongs_to_many”,
tu
ne pourras pas l’utiliser dans ton cas, car elle représente une relation
n-n. Elle permet donc justement de ne pas générer le modèle de la table
de
jointure.

Je te conseil d’aller jeter un oeil sur le wiki de ruby on rails,
notamment
sur cette page:
http://wiki.rubyonrails.com/rails/pages/has_and_belongs_to_many

Jean-François wrote:

Salut arnaud,

Etant donné que c’est pour une toute petite utilisation en interne et
que je ne suis pas un un pro dans ce domaine, je vais me contenter
de ça pour l’instant…
Je souhaite surtout avancer sur rails histoire de le prendre en main!

Je continue donc avec ma table de jointure sur 4 niveaux meme si ca
fera grincer des dents les puristes :slight_smile:

Je te propose de travailler sur cette idée.

pseudo-code
[…]
Après pour s’assurer qu’une Config est unique, mmmhh faut
ptêtre regarder du côté de validates_uniqueness_of avec :scope.

Bon je te laisse peaufiner ma solution.

-- Jean-François.

J’imagine qu’avec un modèle mieux fait, le code s’en trouverait
simplifié je me trompe?
En tout cas c’est une piste :slight_smile:

Alors pour commencer je ne vois pas trop l’intérêt du Scaffold dans ce
cas:
Scaffold = Model + Controller + Views (CRUD: Create, Read, Update et
Delete)

Tu devrais plutôt générer juste le modèle (ruby scripts/generate
ModelName)

Vu que la table de jointure devenait une table principale, il me
semblait normal de manipuler toutes mes données à partir de là …
Il faut que je me fasse à cette logique toute nouvelle.

Au départ, c’est plus contraignant mais tellement plus chic et élégant!

Jean-François wrote:

Salut arnaud,
[…]
pseudo-code
[…]

J’ai remplacé Application par App, Config par Configuration.
Type marche sans problème.

Ta méthode semble fonctionner parfaitement.
Depuis le modèle de Server, j’accède aux Applications en faisant un
simple

   servers.find(xxx).apps

Cela me renvoit ce qu’il faut (une collection d’objet Apps si je ne me
trompe pas).

Il me reste à travailler sur la validation.

Un grand merci pour votre aide!

Salut Arnaud,

J’ai remplacé Application par App, Config par Configuration.
Type marche sans problème.

ça risque de te poser pb et de te péter à la gueule
si tu fais un :

configuration.type

par exemple. #type est une méthode (dépréciée) héritée
de la classe Object qui retourne la classe de l’instance.

Par ailleurs type est le nom de colonne utilisée en héritage
de tables simple (?? Single table Inheritance quoi). Si tu ne
fais pas de STI, ce n’est pas gênant. Mais si plus tard
tu décides d’en faire…

Enfin si ça marche, tant mieux mais moi je déconseille.

Les noms à éviter :
http://wiki.rubyonrails.com/rails/pages/ReservedWords

-- Jean-François.

Jean-François wrote:

Salut Arnaud,

J’ai remplacé Application par App, Config par Configuration.
Type marche sans problème.

ça risque de te poser pb et de te péter à la gueule

Je prend le risque d’avancer sans trop calculer pour mettre en pratique
le plus possible.