Ho una relazione molti per molti: tabelle Client e Broker (solo un esempio). Ovviamente, ogni cliente può avere più broker e ciascun broker può avere più clienti. Quella che è considerata la convenzione di denominazione corretta per la tabella intersect .... è ClientBroker ...?Corretta convenzione di denominazione delle tabelle per una tabella intersect molti a molti
Di solito uso i nomi di entrambe le tabelle di unione.
Quindi, nel tuo caso, ClientBroker.
ho visto spesso il formato "Client_Broker"
preferirei "Clients_Brokers" (pluralizzanti entrambi i nomi per indicare molti-a-molti).
Ho votato a favore da quando qualcun altro l'ha votato. Penso che questa convenzione sia soddisfacente e spesso necessaria. Alcune librerie ORM fornite da framework MVC hanno una convenzione di denominazione per le tabelle che gestiscono automaticamente le relazioni.Conosco almeno 3 framework PHP che usano il nome plurale e la separazione del carattere di sottolineatura per nomi di tabelle pivot molti-a-molti come questo. – wpjmurray
Questo è il vecchio conflitto di denominazione della tabella singolare rispetto al plurale (esteso qui per unire le tabelle). Dai un nome al tavolo al singolare - ad es. "Cliente" perché ogni record rappresenta un cliente? O al plurale perché il tavolo stesso contiene molti "clienti"? È una questione di opinione, non penso che ci sia un motivo per sviare questo. – froadie
Preferisco distinguere tra tabelle intersect e tabelle transazionali reali. Quindi, li interrompo con Mappa. Quindi sarebbe Client_Broker_Map o ClientBrokerMap.
Alcuni programmatori non piace pluralizzando nomi di tabella per un paio di motivi:
Questo ha molto senso se si ha il controllo dell'intero db e livelli aziendali del progetto. Tuttavia, molti framework ora hanno librerie ORM che facilitano il lavoro con tabelle e relazioni. Queste librerie ORM hanno spesso una sintassi di denominazione che deve essere seguita per consentire alla libreria ORM di eseguire la maggior parte del lavoro pesante.
Ad esempio, utilizzo il framework Kohana MVC per PHP che offre una libreria ORM. L'ORM suggerisce la pluralizzazione dei nomi delle tabelle, l'uso di tutti i nomi in lettere minuscole e l'uso dei caratteri di sottolineatura per i nomi di tabelle molti-a-molti. Quindi, per il tuo esempio, avresti le seguenti tabelle: client, broker e brokers_clients (l'ORM suggerisce di ordinare alfabeticamente i nomi delle tabelle per le tabelle many-to-many). Quando si creano modelli per queste tabelle (estensione del modello ORM), si utilizza il valore singolare del nome della tabella, quindi il modello per i client sarebbe Client. L'ORM gestisce la conversione di pluralizzazione. L'ORM di Kohana utilizza anche una libreria di flessioni, pertanto i valori di pluralizzazione insoliti vengono gestiti correttamente. Ad esempio, una tabella denominata "categorie" può utilizzare il nome del modello "Categoria". Infine, se si dispone già di una struttura DB implementata ma si desidera utilizzare la libreria ORM, è possibile sovrascrivere la sintassi di denominazione della tabella ORM predefinita e assegnargli il nome della tabella che si desidera utilizzare.
Sono nel bel mezzo di un progetto in cui sto ricevendo nomi di tabelle e campi utilizzando DESCRIBE. Vorrei usare Client_x_Broker in modo da poter trovare facilmente una tabella e ottenere i campi usando _x_ come criterio, una stringa che non si verificherà di certo in modo naturale nel codice o nei set di dati, ma non nella mia comunque, ed è facile da battere per trovare i nomi dei singoli tavoli. Inoltre, fintanto che sono coerente, posso ottenere molte informazioni solo dal nome della tabella inclusi i nomi delle chiavi primarie. Ci scusiamo per il fatto che, essendo in ritardo eb, andando avanti. :)
Probabilmente andrò con questo. Considerando sia la tabella che i nomi dei modelli. 'Modello ClientsBrokers'? Non così male, probabilmente. E quando lo istanziate? 'Clients_brokers'? Quale sarebbe la forma plurale? 'ClientBrokerMap' è leggermente migliore. Ma ancora meglio è "ClientBrokerRelationship", se me lo chiedi. E 'ClientXBroker' è un buon modo per contrattare questo. –
+1: la punteggiatura deve essere usata con parsimonia, e in questo caso aiuta a distinguere i due lati. –