Perché django e python MySQLdb hanno un cursore per database?

Question

Scenario di esempio:

MySQL in esecuzione un unico server -> HOSTNAME

Due database MySQL su quel server -> Utenti, GIOCHI.

Task -> Scarica 10 giochi più recenti da GAMES.my_games_table, a prendere gli utenti che giocano quei giochi da USERS.my_users_table (assume alcuna unisce)

In Django e Python MySQLdb, perché sta avendo un cursore per ogni database più preferibile?

Qual è lo svantaggio di un cursore estesa che è unico per server MySQL e può passare database (ad esempio tramite una query "utilizzare Utenti;"), e quindi lavorare su database di

connessioni MySQL sono economici corrispondente, ma isn La singola connessione è migliore di molte altre, se c'è un flusso lineare e nessuna transazione complessa che potrebbe richiedere due cursori?

Answer 1

Una risposta più breve sarebbe "MySQL non supporta quel tipo di cursore", quindi nemmeno Python-MySQL, quindi la ragione per cui un comando di connessione è preferito è perché è così che funziona MySQL. Che è una specie di tautologia.

Tuttavia, la risposta è più:

1. A 'cursore', dalla sua definizione, sarebbe certo tipo di oggetto che accede a tabelle e indici all'interno di un RDMS, in grado di mantenere il suo stato.
2. Una "connessione", in base alla definizione, accetta i comandi e alloca o riutilizza un cursore per eseguire l'azione del comando, restituendo i relativi risultati alla connessione.
3. Dalla tua definizione, una "connessione" potrebbe/potrebbe gestire più cursori.
4. Si ritiene che questo sarebbe il modo preferito/performante per accedere a un database poiché le "connessioni" sono costose e i "cursori" sono economici.

Tuttavia:

1. Un cursor in MySQL (e altri RDMS) non è un meccanismo accessibile all'utente per eseguire operazioni. MySQL (e altri) eseguono operazioni come "set", o meglio, compilano il comando SQL in un elenco interno di comandi e fanno numerosi e complessi bit a seconda della natura del comando SQL e della struttura della tabella.
2. A cursor A è un meccanismo specifico, utilizzato all'interno di stored procedure (e solo lì), dando allo sviluppatore un modo di lavorare con i dati in modo procedurale.
3. Una "connessione" in MySQL è ciò che si pensa come un "cursore", una specie di. MySQL non espone il suo interno come un iteratore, o puntatore, che si sposta semplicemente sui tavoli. Espone i suoi interni come una "connessione" che accetta SQL e altri comandi, traduce quei comandi in un'azione interna, esegue quell'azione e restituisce il risultato a te.
4. Questo è il diverso tra uno stile di esecuzione 'set' e uno 'procedurale' (che è in realtà sulla granularità del controllo a cui l'utente ha accesso o, almeno, la granularità inerente al modo in cui gli abstract RDMS via i suoi interni quando li espone tramite un'API).

Answer 2

Come dici tu, le connessioni MySQL sono economiche, quindi per il tuo caso, non sono sicuro che ci sia un vantaggio tecnico in entrambi i casi, al di fuori dell'organizzazione del codice e del flusso. Potrebbe essere più semplice gestire due cursori piuttosto che tenere traccia del database al quale sta attualmente parlando con un singolo cursore, seguendo scrupolosamente le istruzioni SQL "USE". Il chilometraggio con altri database può variare - ricorda che Django si sforza di essere indipendente dal database.

Inoltre, considerare il caso in cui due diversi database, anche sullo stesso server, richiedono credenziali di accesso diverse. In tal caso, saranno necessarie due connessioni, in modo che ciascuna connessione possa autenticare con successo.

Answer 3

Un cursore per database non è necessariamente preferibile, è solo il comportamento predefinito.

La logica è che database diversi si trovano il più delle volte su server diversi, utilizzano motori diversi e/o richiedono diverse opzioni di inizializzazione. (Altrimenti, perché dovresti usare diversi "database" in primo luogo?)

Nel tuo caso, se i tuoi due database sono solo spazi dei nomi di tabelle (che dovrebbero essere chiamati "schemi" in gergo SQL) ma risiedono su la stessa istanza MySQL, quindi usare sempre una singola connessione. (Come configurare Django per farlo è in realtà una domanda completamente diversa.)

Hai anche ragione che una singola connessione è meglio di due, se hai solo un singolo thread e non hai realmente bisogno di due impiegati di database in lo stesso tempo.