Vi chiedo solo un consiglio "personale", quindi in parte soggettivo, sulla nomenclature tabelle mysql, basandovi sulla vostra esperienza.
Ho Contact che è in N<–>N con ContactGroup
le tabelle sono
contact e contact_group
come chiamereste la tabella che collega contact a contact_group ?
-contact_contact_group è poco chiarissimo 
-contact_to_contact_group è più chiaro ma lunghissimo (ci sono 4 lettere di prefisso anche…)
Perché usi un prefisso nel nome delle tabelle? Usi lo stesso database su più applicazioni?
Che cosa contiene ContactGroup?
Come mai vuoi passare da nomi di tabella UpperCamelCase a nomi di tabelle nel formato underscore-separated compounds?
Io farei ContactContactGroup, che poi è la somma dei due nomi.
2 e 3)
mi sono spiegato malissimo, perdonatemi…
Contact e ContactGroup sono due nomi di classi, a cui corrispondono rispettivamente le tabelle …_contact e …_contact_group
Secondo me è la scelta iniziale di chiamare una contact e una contact_group a mettere confusione.
di solito io cerco di non confondere le entità.
Una tabella che si chiama contact_group per come imposto io i nomi sarebbe ad occhio già una tabella di collegamento tra tabella contact e tabella group
ora è troppo tardi, dovevi pensarci prima… il pastrocchio è combinato! eheeh
fai così: contant - contantgroup - contant_contantgroup
beh… se ho una tabella che definisce i gruppi di contatti … group non mi basta come nome…
nello stesso db ho <qualcosa>_group di altre 10/12 entità … dovevo per forza tenerle divise. In quei casi però ogni entità appartiene ad un unico gruppo…
Diciamo che io odio le molti a molti, piuttosto avrei modificato la progetttazione del db, ma anche quella non dipende da me…
… e allora perchè il nome si ? perchè oggi avevo voglia di scambiare due chiacchere con voi e sono solo in ufficio
contact, group, contact_group.
PS. Non è mai troppo tardi per correggere il codice, anzi, … se testate il vostro codice, potete rifattorizzarlo come e quando volete.
sarei daccordo su tutta la linea, e poi con yii… rinominare una tabella vuol dire fare pochissimi interventi
però il fatto è che group in un db dove TANTE entità formano relativi <entita>_group … beh … non rende l’idea del gruppo di cosa ci sia dentro quella tabella…
E’, in effetti, un problema che è sempre stato una croce. Tempo fa ho provato ad adottare questo pattern:
tabella_a, tabella_b, join_a_b
Nel tuo caso abbiamo contatti, gruppi di contatti, ed abbiamo bisogno del join:
contact, group_contact, join_contact_group
Come soluzione non è troppo verbosa, di facile lettura. In oltre percepisci da subito che "join_" è una tabella creata per uno scopo ben preciso. Non conosco Best Practice in questo campo, ma questa mi sembra una buona soluzione. In alternativa, per essere ancora più sintetico potresti fare questo:
contact, group_contact, _contact_group
oppure:
contact, group_contact, _contact__group_contact
Anche in quest’ultimo caso sei sintetico, riesci a leggere immediatamente il nome delle due tabelle. Io, personalmente, non sono per la sintesi. Mi focalizzo sul codice PHP piuttosto che sul nome della tabella. Questo perché cerco di avere un approccio completamente staccato dal database: le modifiche tendo a farle con le migrations. Quindi, secondo questa logica avremmo le classi:
Contact
ContactGroup
Il resto, per me, è poco importante: io ho gli occhi sempre puntati sul codice, e non sul database. Gestire il database con le migrations ed usare le fixtures ti può aiutare a rimodellare il database ogni volta che vuoi. A condizione che tu stia testando il tuo codice perché in caso contrario questa operazione diventa più complessa.
si, efettivamente anche io sto al 99% sul codice… era giusto una conversazione informale sull’argomento.
mi è piaciuta moltissimo questa
la proporrò… grazie. 
Anche io uso una soluzione simile:
<prefisso><prefisso_join><nome_tabella1>_<nome_tabella2>
viene fuori una cosa tipo:
myapp_mm_user_group
in questo caso mm sta per Many to Many, i nomi delle tabelle in relazione le scrivo per esteso anche se può creare nomi tabella lunghi non me ne preoccupo, una volta usavo abbreviazioni sulle tabelle relazionate e ho visto che questo crea confusione quindi ora sono prolisso
Visto che ci siamo, vi racconto un vecchissimo standard adottato da una azienda per la quale programmavo con le vecchissime ASP. Quello standard prevedeva questa forma:
XXXxXXXX
I primi tre caratteri indicavano le prime tre consonanti della tabella. Il quarto carattere il tipo di dato. I restanti il nome del campo. Un questo modo il campo username della tabella utenti poteva essere UTNsUten, la sua data di nascita UTNdNasc, e così via. Per fortuna la guerra è finita e nel 2012 a me piace leggere cose come "nome_della_tabella".
Io sono per i nomi "schifosamente prolissi". Mi piace leggere il codice senza dovermi ricordare nemmeno una sigla. Ora vi mostro un esercizio di behavioral coding (il termine mi è stato detto ieri parlando con un amico):
class NicknameLinkable extends NicknameLinkableBase
{
public function __construct($content)
{
parent::__contruct($content);
$this->cercaTuttiINicknameCheTroviNelMessaggio();
if($this->seNeTroviQualcuno()) {
do {
if($this->eSeEsisteUnAccountAssociato()) {
$this->rendiLinkabileIlNickname();
}
} while ($this->eProseguiFinoAQuandoCiSonoDeiNickname());
}
}
}
Può essere "strano" leggere codice simile, ma il disagio più grosso che "provo" quando vedo codice di altri è che non capisco mai che cosa voglia significare una abbreviazione. Detto questo, basta che un team definisca un proprio standard e qualsiasi regola è buona e valida dal momento che è condivisa.
concordo in pieno