PHP'nin PDO Arayüzü kullanılarak DB motorları Anahtarlama MySQL backticks Taşıma

3 Cevap php
  1. Şu anda onun arkaplanı için bir MySQL veritabanı kullanan bir PHP uygulaması üzerinde çalışıyorum
  2. Benim sorguları tüm alan adlarını kaçmak için backticks içerir. Bu yüzden (bkz. örnek) sorunları neden olmadan bir sorguda "şifre" gibi alanları sahip olabilir
  3. Ben backticks (SQLite örneğin, bir çift teklifi kullanır) ilişkisel veritabanı motorları arasında evrensel olmadığını biliyoruz
  4. Benim php uygulama sorguları tüm PHP'nin PDO arayüzü kullanılarak yürütülen

Benim soru şudur: Ben veritabanı motorları geçmek istiyorsanız, benim sorguları her ne ben backticks işlemek için yapmam gerekiyor, MySQL SQLite demek? Gerçekten benim kod tüm geçmesi ve backticks / kaldırmak değiştirmek zorunda istemiyorum. Herhangi bir öneriniz? Ben iyi uygulamaların sınırları içinde yanlış ya da olmayan bir şey yapıyor muyum?

Örnek sorgu:

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

3 Cevap

Aslında, password gerçekten kote olması gerekmez ... Hatta ayrılmış bir kelime değil: http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html

IMHO, yapabileceğiniz en iyi yaklaşımdır:

  1. Lütfen tanımlayıcılarda ayrılmış sözcükleri kullanmayın.
  2. Geçerli kod tırnak kaldırın; (Ayrıca ters tırnak operatörü kullandığınız sürece) herhangi bir iyi editör ile 2 dakikalık bir görev

Ne olursa olsun, başka bir DB motora geçiş bir şey var; DB-bağımsız bir uygulama bina enterely farklı bir konudur.

Ayrılmış sözcükler kullanmayın ve backticks kullanmadığınız zaman belaya yok. Tüm ters tırnakların kurtulun, SQL standart değil, diğer tüm veritabanları onlarla sorun olacaktır. Çift tırnak standardında kullanılan, en veritabanları onları destekliyoruz. Fakat yine de, Reseved kelimeler kullanmayın ve onlara ihtiyacım yok.

Bir tanımlayıcı olarak: ANSI-QUOTES ve ilk etapta yapılması gerektiği gibi MySQL de çift tırnak tedavi edecek kullanmak için MySQL sunucu (bağlantı) yapılandırın

Aslında, SQLite MySQL ters tırnak tarzı alıntı ile uyumludur.

Eğer @Frank tavsiye izlerseniz ters ancak, sadece doğrudur.