Discussion :

[RunCodePhp]

Bonjour à tous.

J'ai une question qui me turlupine depuis que j'utilise l'ORM de Kohana (qui est un Framework).
Jusqu'à lors je ne l'utilisais pas (module non activé), donc ça allait.

Mais posons directement la question :
Est-il normal d'être obligé de créer des clés primaires auto_increment (un seul champ en faite) sur toutes les tables ?
En somme, de mettre des champs "id" partout.

Avec Kohana ça m'a l'air d'être le cas, car en passant par l'ORM, il m'est (apparemment) impossible de mettre à jour une table ayant une clé primaire double zone, donc avec 2 champs.
Genre table "articles_lang", clé primaire : (id_article, id_lang)


Ou alors j'aurais raté un truc par là ?
Ou serait-ce une spécificité (contrainte) propre à Kohana ?


Autre question (accessoirement), quelle serait la meilleur convention de nommage pour les noms des champs ?
Est-il mieux nommer id_article ou plutôt article_id ?
(pour les clés étrangères par exemple)

Concernant l'ORM Kohana, ça n'a pas vraiment d'importance, mais en voyant le fonctionnement, ça tendrait plutôt vers : article_id
En faite on obtient quelque chose comme lors d'une jointure (pour exemple) :
article_lang->id et article_lang->article->id


Merci pour tout éclaircissement

[RunCodePhp]

C'est la misère

Pour les up, je sais que c'est pas bien ... (pas taper )

Je sais aussi que Kohana c'est pas un FW très connu/utilisé, mais pour ce qui est des autres qui on des ORM, permettent-il d'avoir des clés primaires doubles, triples, ... ?
Ou est t'ont obligé de créer une clé unique auto_increment sur chaque table ?


Apparemment Kohana à une propriété $_primary_key, et on ne peu pas mettre autre chose qu'une chaine, donc 1 champ.
Je m'attendais à pouvoir mettre un tableau pour plusieurs clés.
Du coup si je fais un Objet->create() ça va insérer selon la valeur d'1 table (la clé).
Si la table a une clé double par exemple, et bien ça n'ira pas.


Est-ce un comportement normal selon vous ?

[FirePrawn]

Hello,

Bizarre ce comportement.
J'ai pas en mémoire de problème similaire avec Hibernate (J2EE).
Donc j'aurais tendance à dire que c'est lié à ton framework

[RunCodePhp]

Merci pour ce retour.

Donc j'aurais tendance à dire que c'est lié à ton framework

Je crains que ça soit une restriction de l'ORM de ce FW.

Après moult recherches (pas si étonnant de ne pas trouver le moindre exemple de code pour ce cas), je tombe sur ces discussions :
How can I use joint primary keys and Kohana 3 ORM?
KohanaPHP » Kohana v3.x » ORM
Qui dit (entre autre) :

Kohana doesn't support compound primary keys

(en traduction avec GG) :

Si quelqu'un a cette mise en œuvre proprement assez, nous pouvons la considérer, mais personnellement, je ne vois pas un usage assez commun pour ce que je suis le déplacer pour réexamen 3.3.0.

La façon la plus simple pour sélectionner une ligne de table qui a plusieurs clés primaires est d'ajouter une colonne id auto incrémentation de la table et utiliser à la place de la clé sur plusieurs colonnes.

Nous n'allons pas à l'inclure dans ORM de sitôt. Dans l'avenir, nous pouvons créer une nouvelle question si nécessaire pour cela.

Du coup, j'ai une autre question :
- Est-il mieux de créer un ID auto incrémenté dans ces cas là pour exploiter l'ORM
- Ou vaut il mieux ne pas le faire (respecter les base des conception de Bdd) et ne pas exploiter l'ORM dans ces cas là pour faire les requêtes directement (car c'est possible, l'ORM n'est une obligation partout).


Pour le moment j'en suis au début d'un site Web, donc rien est irréversible.
Au feeling comme ça, je dirais qu'il serait mieux de créer un ID auto incrémenté pour exploiter pleinement l'ORM, plus particulièrement pour la partie validation (formulaire ou autre) qui prévoit de placer les règles dans le Model (ce qui évitera de les (re)définir dans le Controler dans le cas contraire.


Tout retour sur ce point sera le bien venu.

[rawsrc]

Bonjour,

Est-il mieux de créer un ID auto incrémenté dans ces cas là pour exploiter l'ORM
- Ou vaut il mieux ne pas le faire (respecter les base des conception de Bdd) et ne pas exploiter l'ORM dans ces cas là pour faire les requêtes directement (car c'est possible, l'ORM n'est une obligation partout).

Je vais t'éclairer un peu. Pour ce que je m'en souvienne, les moteurs de base de données gèrent automatiquement un id autonum pour absolument toutes les tables. Donc si tu ne l'affiches pas, il est quand même présent pour le bon fonctionnement de l'ensemble.
J'ai toujours pour habitude de démarrer mes tables avec un id autonum et après je fais ma salade au niveau des index, index composés, des liens...
D'expérience, j'ai aussi arrêté d'abuser des clés composées (sauf cas rarissimes). Il est plus simple de jouer avec une seule clé externe qu'avec un paquet.

Pour ce qui est de l'usage d'un ORM en PHP, il faut faire attention au goulet d'étranglement dès la montée en charge.

[RunCodePhp]

J'ai toujours pour habitude de démarrer mes tables avec un id autonum et après je fais ma salade au niveau des index, index composés, des liens...
D'expérience, j'ai aussi arrêté d'abuser des clés composées (sauf cas rarissimes). Il est plus simple de jouer avec une seule clé externe qu'avec un paquet.

Donc tu sous entendrais par là que cette restriction que je perçois serait un faut problème, voire à mieux concevoir les choses (plus simple, ...).

C'est vrai que je me dis que ce ne serait pas si contraignant que ça, car rien m'empêche de créer cet ID auto incrémenté et de créer un INDEX UNIQUE pour les clés composées.
Du coup plus de problème de doublons possible (ce qui est recherché en créant des clé primaires composées).
Je pense que faire comme ceci devrait faire l'affaire.

Pour ce qui est de l'usage d'un ORM en PHP, il faut faire attention au goulet d'étranglement dès la montée en charge.

C'est la 1ère fois que je m'aventure à utiliser une ORM, et je remarque qu'on récupère beaucoup de données inutiles, sans compter que les Objets sont assez conséquents/volumineux aussi.
Faudra faire attention c'est vrai.


Plutôt rassurant ton intervention. Merci