Reprise du message précédent :
J'vais voir du côté de CakePhp pour voir comment c'est foutu, pis leur site à l'air bien clair et y a pas mal d'explications  

2 minutes de doc :

lolilolzor

Rien que ça suffit à ce que je n'en veuille pas, c'est tout

Mais tu pourrais développer un peu plus car pour moi ça reste un peu vague ce que tu a quoté  

Aucune cohérence dans le nommage des fichiers/classes, contraintes sur le nommage des tables () et pour des noms de tables au pluriel en plus.
Bref,

[HS]jme demande toujours, une table article, article ou articles ?[/hs]

Je vois pas la différence entre les 2 premiers.

article, pour moi, sinon, pour répondre à la question...

ok, c'est une convention ? (c'est deja ce que je faisais mais bon)

Plus ou moins, vu ce que fait cakephp.
Mais ça aurait plutot sa place sur blabla@sql, ça.

ok
sujet clos alors

T'inquiète, yavait aussi une trentaine d'autres fichiers ouverts en permanence, c'est le minimum si tu veux comprendre comment créer une page "promo"

Des trucs qui pourraient être mieux, rien de très très grave

devraient

C'est ce qu'on apelle du Convention over Configuration... (cf http://en.wikipedia.org/wiki/Conve [...] guration). Quasi tout les bon framework MVC utilise ça pour simplifier encore plus leur utilisation.

C'est pareil dans Rails l'exemple type de framework MVC. D'ailleurs c'est plus un obligation du à un ORM intégré qu'au framework en lui même je pense.
ActiveRecord en Ruby impose la même règle, qui est finalement courante en faite. (perso je range pas mes objet Article dans une table Feuille_de_choux...)

Mes articles je les range dans un table article. Je m'amuse pas à coller du pluriel dans un nom de table pour faire plaisir à un ORM.
C'est à l'outil de s'adapter au développeur, pas au développeur de s'adapter à l'outil. Vouloir trop simplifier les choses ne fait que les rendre plus opaques et compliquer les choses dès qu'on a besoin de sortir du moule.

Tout ça pour un S dans le nom d'une table quoi...    
 
D'un côté le principe de l'ORM est d'avoir une couche d'abstraction. A la rigueur la table s'appelerais A37E52F tu t'en balancerais tout autant... Tu n'as en principe AUCUNEMENT besoin de traficoter dans le BDD à la main.
Sérieusement même les gros ORM type JPOX/Hibernate te font tes tables sans te demander ton avis. Et c'est plus compliquer/long de paramétrer l'ORM pour suivre un schéma existant/voulu, que de le laisser faire sa tambouille.

un s ou un x suivant les cas
et la table qui fait le jonction entre deux autres,  tu mets les s ou ?

l'orm que j'ia testé ( Doctrine ) a besoin d'un nom de table, que ce soit le nom physique ou pas, ça ne change rien . A noter que meme si dotrine conseille les noms de table au pluriel , il n'est pas chiant

Pour moi c'est pas le boulot d'un ORM de créer la base. Ne serait-ce que parce-que la plupart du temps tu n'interroges pas la base que via une appli web.
Et c'est sans compter les projets qui doivent utiliser une base existante.
Bref, en ce qui me concerne un outil qui force les choses comme ça est bon pour un petit projet qui démarre de rien, mais c'est bien tout.

Un ORM n'est pas l'exclusivité des appli Web.
 
Et justement l'ORM sont rôle c'est de géré la persistance des tes Objet dans une BDD relationnelle. Et ça peut donc inclure aussi de créer le modèle de donnée.

 
TIP: on est en cat' php, là.
 

 
C'est pas parce-que l'outil sait le faire que c'est forcément une bonne idée de le lui faire faire.
Enfin bref, on est complètement hors sujet, là.

 
Juste pour corriger, les conventions rails ne sont pas un impératif, on peut très bien les ignorer et utiliser une base qu'on a créé à la main
 
Sinon le pluriel dans le nom des tables me parait logique

pourquoi?
quand tu décris une table d'articles, tu décris comment en composé un article, pas une liste d'articles...Tu fais pareil avec le nom de tes classes?
A l'époque lointaine de mes cours sur les bases de données, le prof nous enlevait même des points sur ce genre de conneries.

 
Bah tu dis bien "une liste d'articles" ou "un tableau d'articles", je vois ca comme ca, tu mets plusieurs articles dans ta table
Tu as peut-etre un traumatisme d'enfance ? (sinon non je ne mets pas de pluriel dans mes classes)

 
Une classe représente visuellement 1 objet, alors qu'une table est un conteneur de plusieurs objets
 
Cela dit c'est vachement plus pratique d'écrire les tables au singulier, ça fait bizarre au début mais en fait c'est bien. Genre dans les requêtes SQL, c'est plus compréhensible d'écrire "WHERE shop.id = 3" que WHERE "shops.id = 3".
 
Faut voir le nom de la table comme le nom du type d'objet qu'elle contient (shop), et pas/plus comme le nom du contenu (shops).
 
Et puis t'as plus aucune réflexion à avoir sur "là je mets au pluriel ou pas ?", "comment on fait quand le pluriel prend pas de S ?"

 
Je fais des aussi des script en ligne de commande en PHP perso.
Et bon même si on est en PHP, les ORM ne sont pas l'exclusivité du PHP (bien au contraire, même Doctrine fait un peu amateur comparé a Hibernate).

Déjà quand t'as un ORM tu met pas le nom de la table, mais le nom de la classe dans la requête.
Et en plus, vive les alias... Et là t'aurais "where s.id = 3" que ça soit "shops s" ou "shop s".

Spa faux. Il reste le dernier argument

 
En contre argument je dirais surtout que je trouve pas très logique de dire "select * from shop"

Pourquoi?
Tu trouves ça étrange de vouloir récupérer toutes les données qui composent un magasin?

 
Bah on peut récupérer plusieurs magasins non ?
Je crois que ce "débat" n'aura pas de fin

tu fais beaucoup de select * from table, sans where ?

Déjà en pratique on fait jamais de select *...

Bah dans ce cas tu veux un Mapper, pas un ActiveRecord

je suis en plein reflexion,  
je bosse sur un mvc home made, avant tout pour apprendre, tester, bidouiller,
 
la partie controlleur c'est ok, la partie model aussi,  
par contre je bloque un peu pour la partie view,  
 
si j'imagine une appli ecommerce par exemple,  
je vais avoir besoin de pas mal de vues :
 
la vue d'accueil, qui va afficher le header, menu, les x nouveautés, les x meilleures ventes, ..., les liens vers les pages d'infos, l'arbre de categ, ...
 
ensuite, une vue "categorie" qui affichera header, menu, les sous categ; une selection d'articles de cette categorie, ...
 
ensuite une vue "article" qui affichera l'article, les liens pour ajouter au panier, ...
 
une vue panier, ...
 
donc je remarque qu'a chaque fois, j'afficherais le header, le menu, l'arbre de categ, ...
je peut donc en faire des vues ce ces "modules", et les appeler pour construire la vue principale,  
 
mais comment gerer ca ? à coup d'includes / requires ?  
 
donc un fichier /views/head.php :
 

<html>
<head><title><?php echo $page_title; ?></title></head>
<body>
    <div id="header">Header</div>

 
puis un views/menu.php
 

<div id="menu">
   <a href="toto">Lien 1</a>
   <a href="toto">Lien 1</a>
   <a href="toto">Lien 1</a>
</div>

 
et apres dans la vue /views/accueil.php :
 

<?php require('header.php'); ?>
<?php require('menu.php'); ?>
<div id="main">
    <?php foreach ($nouveautes as $article){
        echo '<div class="article">' . $article->libelle . ' - ' . $article->prix . '</div>';
    } ?>
</div>
</body>
</html>

 
c'est la bonne voie ?    

Je préfère les systèmes par héritage de templates (à la django) perso

ca fonctionne comment en gros ?

<?php require('header.php'); ?>
<?php require('menu.php'); ?>
<div id="main">
    <?php foreach ($nouveautes as $article){
        echo '<div class="article">' . $article->libelle . ' - ' . $article->prix . '</div>';
    } ?>
</div>
</body>
</html>

Si tu fais ça tu vas te répéter tout le temps, et c'est la merde le jour ou tu veux rajouter un module news ou un footer par ex (faut bouger toutes les pages)

En gros faut plutot faire l'inverse : inclure le contenu des différentes pages à l'intérieur d'un template commun. L'héritage de template de Django (et ZF il me semble) c'est ça, en plus évolué. Symfony 1.x que je connais mieux, c'est ça aussi, avec un seul niveau d'héritage. Ca donne en très gros :

main_layout.php

<html>
<head>
</head>
<body>
  <h1>Mon Super Site</h1>
  <div id="content">
    <?php  echo $content; ?>
  </div>
</body>
</html>

+ accueil.php

<h2>Yo</h2>
<p>Ca déchire</p>
<?php 
  foreach ($nouveautes as $article){
    echo '<div class="article">' . $article->libelle . ' - ' . $article->prix . '</div>';
  } 
?>

Et c'est le FW qui fait le lien entre les deux.