Bu sorgu gereksiz bilgi almak mı?

4 Cevap php

I have this classifieds website, and I have about 7 tables in MySql where all data is stored. I have one main table, called "classifieds".

Ilanlar tabloda, classified_id adında bir sütun var. Bu PK, ya da herhangi bir anahtar değildir. Bana birlikte tablo kayıtları JOIN için kullanılan bir sayıdır.

Ex:

 classifieds table:           fordon table:
       id => 33                   id => 12
classified_id => 10             classified_id => 10
  ad_id => 'bmw_m3_92923'

Bu, yukarıda classified_id kolonu ile birbirine bağlı değildir.

Şimdi Q, ben sütun ad_id bu durumda $ ad_arr denilen bir dizi içindeki değerlerin herhangi eşleşen tüm kayıtları almak için bu yöntemi kullanın:

SELECT mt.*, fordon.*, boende.*, elektronik.*, business.*, hem_inredning.*, hobby.*
    FROM classified mt
    LEFT JOIN fordon ON fordon.classified_id = mt.classified_id
    LEFT JOIN boende ON boende.classified_id = mt.classified_id
    LEFT JOIN elektronik ON elektronik.classified_id = mt.classified_id
    LEFT JOIN business ON business.classified_id = mt.classified_id
    LEFT JOIN hem_inredning ON hem_inredning.classified_id = mt.classified_id
    LEFT JOIN hobby ON hobby.classified_id = mt.classified_id 
    WHERE mt.ad_id IN ('$ad_arr')";

Bu iyi mi, yoksa bu aslında gereksiz bilgi almak istiyorsunuz?

Ben gün önce birkaç yayınlanmıştır Bu Q göz atın. Yorumlarında HLGEM o ne düşünüyorsunuz vs vs yanlış olduğunu açıklamasının mi?

http://stackoverflow.com/questions/2782275/another-rookie-question-how-to-implement-count-here

Teşekkürler

4 Cevap

Mutlaka soruyu cevaplamak için, gereksiz sonuçları dönüyor.

Içine almak için kötü bir alışkanlıktır.

Kesinlikle marr75 katılmıyorum. Öncelikle sorguları çoğunda bu zavallı techinie yaparsanız, hemen hemen her sorgu için gereksiz yük ekliyoruz yapmamı. Veritabanı sorguları sonra bnack gitmek ve bilinen kötü techinique kullanılan yapmamı sizin datbase her sorguyu yeniden yazmak için son derece acı verici olduğu kadar iyi optimize lar olası yazılması gerekir. Datbases olarak üstlenmeden zordur ve performans tasarım, o baştan performansını artırmak için bilinen techiniqes kullanmak için erken optimaization değildir dikkat edilmesi gereken, iyi bir tasarım.

Sonra, bakım sorunu var. Eğer belli bir düzen içinde olmak sütunlar onthese bağlı ve birisi databe yapısını değiştirir Eğer liuck dışında. Birisi (ortak Hangi) kullanıcıya göstermek istemediğiniz bir sütun ekler varsa ihtisasını, şans dışında. Bu çok kötü bir techinique ve seçin * ina üretim sistemi kullanılmaktadır neredeyse asla. Birisi bir sütun ekler varsa, bu sorgu inthe iade edilecektir ama niye eklendi bilmek gerekir ve arayüzü zaten yapması gereken ne, bu nedenle bu kötü tekniği kullanarak hiçbir bakım tasarruf yapmak için.

Ad Hoc Queries

Bunlar bir kez, ya da nadir durumlarda çalıştırmak yazmak sorgular vardır.

Eğer bir SELECT * sütun adlarını yazın dışarı daha yapmak için uzun alacağını ne kadar büyük bir sonuç veri kümesi dönmelidir?

Eğer bir sütun unutmak nasıl muhtemeldir, bunu ekleyin ve tekrar çalıştırmak zorunda?

Sizin zamanlı CPU zaman daha pahalıdır. Eğer bir kez çalıştırıyorsanız, veritabanı çalışma yapalım. Bu size zaman kazandıracak eğer SELECT * ad hoc sorguları için gayet iyi.

Orada büyük veri kümeleri üzerinde Blob alanlar gibi istisnalar vardır, ama sen noktası olsun.

Production Queries

Bunlar uygulama veya veritabanında saklanır sorguları vardır. Bu sorgular genellikle çalıştırılır.

Kaç kere bunu sütunları isim alacağını zamanı telafi etmek için bir sorgu çalıştırmak zorunda mı? Bu kadar hızlı ekler.

Uygulama daha iyi ölçekleme ve maksimum verimlilikle gerçekleştirmek için izin üretim sorguları içinde sütunları Ad. Orada diğer küçük avantajları vardır, ama onlar kadar heyecan verici değil.

Summary

  • Hoc sorgular ekleyin: SELECT * genellikle tamam.
  • Üretim Sorguları: SELECT * her zaman kötü.
  • Biraz tembel olabilir, ama bu konuda akıllı olmak tamam.

Bu görüş meselesidir. Eğer performansı olan veya sorunları ölçeklendirme vardır? Eğer değilse, daha sonra özel olarak dönmek için sütun muhtemelen erken optimizasyonu meselesidir hangi. Tamsayı sütun birleştirme çoğaltma bant genişliği bankaya yakında her zaman kırmak için gitmiyor.

etiketler