Gestione MySQL backtick quando si passa motori DB mediante l'interfaccia DOP PHP

Attualmente sto lavorando su un'applicazione PHP che utilizza un database MySQL per il suo backend
Tutte le mie domande contengono backticks per sfuggire i nomi dei campi. In questo modo posso avere campi come "password" in una query senza causare problemi (vedi esempio)
So che i backtick non sono universali tra motori di database relazionali (SQLite usa una virgola doppia, ad esempio)
tutte le query nella mia applicazione PHP vengono eseguiti utilizzando l'interfaccia DOP PHP

mia domanda è questa: Se voglio cambiare motori di database, diciamo da MySQL a SQLite, che cosa devo fare per gestire le backticks in tutte le mie domande? Davvero non voglio dover passare tutto il mio codice e modificare/rimuovere i backtick. Eventuali suggerimenti? Sto facendo qualcosa di sbagliato o non entro i confini delle migliori pratiche?Gestione MySQL backtick quando si passa motori DB mediante l'interfaccia DOP PHP

Esempio di query:

SELECT 
    `username`, 
    `password`, 
    `email_address` 
FROM 
    `users` 
WHERE 
    `id` = '1'

fonte

2010-03-03 Levi Hackwith

In realtà, password non ha davvero bisogno di essere citato ... non è nemmeno una parola riservata: http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html

IMHO, l'approccio migliore si può prendere è:

non utilizzare parole riservate nei vostri identificatori.
Rimuovi preventivi dal codice corrente; è un compito di 2 minuti con qualsiasi editor decente (a meno che non si usi anche l'operatore backtick)

In ogni caso, passare a un altro motore DB è una cosa; costruire un'app indipendente dal DB è un problema molto diverso.

fonte

2010-03-03 17:58:56

Questo è un buon consiglio e cosa farò d'ora in poi. –

Non utilizzare parole riservate e non si ottiene nei guai quando non si utilizza backticks. Sbarazzati di tutti i backtick, non è SQL Standard, tutti gli altri database avranno problemi con loro. Le virgolette sono usate nello standard, la maggior parte dei database le supporta. Ma di nuovo, non usare le parole resettate e non ne hai bisogno.

Configurare il MySQL-server (-Connessione) per utilizzare ANSI-QUOTES e MySQL sarà anche trattare doppie virgolette, come avrebbe dovuto fare in primo luogo: come identificatore

fonte

2010-03-03 17:10:07

È considerato "cattiva pratica" utilizzare parole riservate come nomi di campi? Il motivo per cui sto usando 'password' come nome di campo è perché è la descrizione più chiara e concisa di ciò che contiene quel campo. Faccio la stessa cosa con i miei altri campi come le date (ho usato 'created_at' vs 'date_time_created'). Sono aperto a suggerimenti/correzioni. Qualsiasi consiglio è apprezzato. –

Evitare parole riservate non è pratico. Ho appena iniziato a giocare con una tabella su sqlite3 che ha la colonna chiamata 'release' e non ha avuto problemi. Quando ho provato lo stesso su mysql per controllare qualcosa, ha avuto problemi con esso, probabilmente perché è una parola riservata. Potrei sicuramente cambiare il nome, ma se non avessi provato su mysql, non avrei saputo nulla. – haridsv

RELEASE è una parola chiave anche in SQLite: http://www.sqlite.org/lang_keywords.html È presente nell'elenco di parole chiave SQL: 2008. –

In realtà, SQLite è compatibile con lo stile di citazione dei backtick MySQL.

L'inverso tuttavia, è vero solo se si segue la consulenza @Frank.

fonte

2010-09-06 14:19:39

Gestione MySQL backtick quando si passa motori DB mediante l'interfaccia DOP PHP

risposta

Problemi correlati