Neden "tablodan seç *" kötü uygulama olarak kabul edilir?


96

Dün bir "hobi" programcısıyla tartışıyordum (kendim profesyonel bir programcıyım). Çalışmalarının bir kısmına rastladık ve her zaman veritabanındaki tüm sütunları sorguladığını söyledi (üretim sunucusunda / kodunda bile).

Bunu yapmamasına ikna etmeye çalıştım, ancak henüz başarılı olamadım. Kanımca, bir programcının sadece "aldatma", verimlilik ve trafik adına gerçekten neyin gerekli olduğunu sorgulaması gerekir. Görüşüme yanlış mıyım?


1
Tablo içeriği değişirse ne olur çünkü? sütun ekleme / çıkarma hala seçiyorsanız * .. böylece bir şeyleri kaçırıyor veya ihtiyacınız olandan daha fazla veri geri çekiyorsunuz.
JF,

2
@JFit Bu onun bir parçası, ama tüm hikayeden çok uzak.
14'te

8
SO'da


@gnat bir soru gerçekten kapalı bir sorunun kopyası olarak düşünülebilir mi? (yani kapalı olan ilk etapta gerçekten uygun olmadığından)
gbjbaanb

Yanıtlar:


67

Ne geri döndüğünüzü ve bunları kodunuzdaki değişkenlere nasıl bağladığınızı düşünün.

Şimdi, birileri doğrudan kullanmadığınız bir sütun bile eklemek için tablo şemasını güncellediğinde ne olacağını bir düşünün.

Sorguları elle yazarken select * komutunu kullanmak sorun değil, kod sorguları yazarken sorun değil.


8
Performans, ağ yükü vb., Sütunları istediğiniz sıraya ve adınıza geri getirme rahatlığından çok daha önemlidir.
14'te

21
@jwenting gerçekten mi? performans doğruluktan daha önemli mi? Her neyse, "select *" in yalnızca istediğiniz sütunları seçmekten daha iyi performans gösterdiğini görmüyorum.
gbjbaanb

9
@Bratch, gerçek hayattaki üretim ortamlarında, aynı tabloları kullanarak yüzlerce uygulamanız olabilir ve tüm bu uygulamaların düzgün bir şekilde sürdürülebilmesi mümkün değildir. Siz duyarlılık konusunda haklısınız, ancak pratikte argüman sadece birlikteliklerde çalışmanın gerçekliğinden dolayı başarısız oluyor. Şema aktif tablolarda yapılan değişiklikler her zaman olur.
user1068

18
Bu cevaptaki noktayı anlamıyorum. Tabloya bir sütun eklerseniz, hem SELECT * hem de SELECT [Sütunlar] çalışır, tek fark kodun yeni sütuna bağlanması gerekiyorsa, SELECT [Sütunlar] 'ın değiştirilmesi gerektiğidir. SEÇ * olmaz. Sütun bir tablodan kaldırılırsa, SELECT * ciltleme noktasında kırılır, oysa SELECT [Sütunlar] sorgu yürütülürken kırılır. Bana göre SELECT * daha esnek bir seçenektir, çünkü tablodaki herhangi bir değişiklik sadece ciltleme için değişiklik gerektirecektir. Bir şey mi eksik?
TallGuy

11
@gbjbaanb, sonra sütunlara ada göre erişir. Sorgudaki sütun sırasını belirtmediyseniz, başka herhangi bir şey aptalca olacaktır.
immibis

179

Şema Değişiklikleri

  • Siparişte al --- Kod, verileri almanın yolu olarak sütun # alıyorsa, şemadaki bir değişiklik sütun numaralarının yeniden ayarlanmasına neden olur. Bu uygulamayı bozacak ve kötü şeyler olacak.
  • Ada göre al --- Kod, adı gibi sütun alıyorsa foove sorgudaki başka bir tablo bir sütun eklerse foo, bu işleme şekli doğru foo sütunu almaya çalışırken sorunlara neden olabilir .

Her iki durumda da, bir şema değişikliği verilerin çıkarılmasıyla ilgili sorunlara neden olabilir.

Ayrıca, kullanılan bir sütunun tablodan kaldırılıp kaldırılmadığını göz önünde bulundurun . select * from ...Sonuç kümesinin dışına veri çekme çalışırken hala hatalar dışarı ama çalışır. Sütun sorguda belirtilirse, sorgu yerine sorunun ne ve nerede olduğu net bir indiciation vererek dışarı hata olacaktır.

Veri ek yükü

Bazı sütunlarda, bunlarla ilişkili önemli miktarda veri bulunabilir. Geri seçildiğinde tüm veriler *çekilir . Evet, işte size seçtiğiniz 1000 satırda, ihtiyacınız olan 4 megabaytlık ek veriye ihtiyaç duymuyorsunuz, ancak yine de tel üzerinden iletiliyor.varchar(4096)

Şema değişikliği ile ilgili olarak, tabloyu ilk oluşturduğunuzda bu varchar orada bulunmayabilir, şimdi orada.

Niyet iletilemedi

Geri dönüp *20 sütun aldığınızda ancak bunlardan yalnızca 2'sine ihtiyacınız olduğunda, kodun amacını iletmezsiniz. select *Birini yapan sorguya bakarken bunun önemli kısımlarının ne olduğunu bilmiyor. Sorguyu, bu sütunları ekleyerek daha hızlı hale getirmek için bu diğer planı kullanmak üzere değiştirebilir miyim? Bilmiyorum çünkü sorgunun döndürdüğü şeyin amacı net değil.


Şema değişikliklerini biraz daha keşfetmek için bazı SQL kemanlarına bakalım .

İlk olarak, ilk veritabanı: http://sqlfiddle.com/#!2/a67dd/1

DDL:

create table one (oneid int, data int, twoid int);
create table two (twoid int, other int);

insert into one values (1, 42, 2);
insert into two values (2, 43);

SQL:

select * from one join two on (one.twoid = two.twoid);

Ve geri almak sütunlar vardır oneid=1, data=42, twoid=2, ve other=43.

Şimdi, bir numaralı tabloya bir sütun eklersem ne olur? http://sqlfiddle.com/#!2/cd0b0/1

alter table one add column other text;

update one set other = 'foo';

Ve aynı sorgudan benim sonuçlar önceki gibidir oneid=1, data=42, twoid=2, ve other=foo.

Tablolardan birindeki bir değişiklik select *, 'diğerini' bir int'ye bağlamanızın bir anda değerini kaybeder ve bir hataya neden olur ve nedenini bilmiyorsunuz.

Eğer öyleyse, SQL deyiminiz

select 
    one.oneid, one.data, two.twoid, two.other
from one join two on (one.twoid = two.twoid);

Birinci tabloda yapılan değişiklik verilerinizi bozmazdı. Bu sorgu değişiklikten önce ve değişiklikten sonra aynı çalışır.


indeksleme

Bunu yaptığınızda select * from, tüm satırları çekiyorsunuzdur ve koşullara uyan tüm tabloları oluşturur. Gerçekten umursamadığın masalar bile. Bu, daha fazla veri aktarılması anlamına gelse de, yığında daha fazla gizlenen başka bir performans sorunu var.

Endeksler. (SO ile ilgili: index ifadesinde select ifadesi nasıl kullanılır? )

Çok sayıda sütunu geri çekiyorsanız, veritabanı planı en iyi duruma getiricisi bir dizini kullanmayı göz ardı edebilir çünkü tüm bu sütunları yine de almanız gerekecek ve dizini kullanmanız ve ardından sorgudaki tüm sütunları getirmeniz gerekecek tam bir masa taraması yapmak için olurdu.

Eğer sadece bir kullanıcının soyadını seçiyorsanız (çok fazla yaptığınız ve üzerinde bir indeksin bulunduğu), veritabanı sadece bir indeks taraması yapabilir ( sadece wiki endeksi taramasından sonra , mysql tam tablo taramasından vs dizin taraması , Yalnızca Dizine Tara: Tablo Erişimini Önlemek ).

Mümkünse sadece indekslerden okuma hakkında bir miktar optimizasyon var. Her indeks sayfasında bilgi daha hızlı çekilebilir, çünkü daha az çekiyorsunuz - bunun için diğer tüm sütunları çekmiyorsunuz select *. Bir indeks taramasının sadece sonuçları 100 kat daha hızlı sırayla döndürmesi mümkündür (kaynak: Seç * kötüdür ).

Bu tam dizin taramasının harika olduğunu söylemiyor, hala tam tarama - ancak tam tablo taramasından daha iyi. select *Performansa zarar veren tüm yöntemleri kovalamaya başladığınızda yenilerini bulmaya devam edersiniz.

İlgili okuma


2
@Tonny katılıyorum - ama cevap verdiğimde (ilk) bu sorunun çok fazla tartışma ve yorum getireceğini asla düşünmedim! Sadece adlandırılmış sütunlar için sorgu yapmak açık, değil mi ?!
gbjbaanb

3
Her şeyi bir sütun ekleyerek bölmek, aynı zamanda, kodun her zaman kodlanmış bir sıradan değil, adlarıyla bir veri okuyucundaki sütunlara erişmesi için iyi bir nedendir ...
Julia Hayward

1
@gbjbaanb Bu benim. Fakat birçok insan resmi bir arka plan / eğitim olmadan SQL sorguları yazmaya geldi. Onlar için açık olmayabilir.
Tonny

1
@Aaronaught Ben indeksleme sorunları üzerinde ek bit ile güncelledik. Yanlışlığı için getirmem gereken başka noktalar var select *mı?

3
Vay canına, kabul edilen cevap, aşağı oy kullandığım bir şeyi açıklamak konusunda çok zayıftı. Bu kabul edilen cevap olmadığını hayret. +1.
Ben Lee,

38

Başka bir kaygı: eğer bu bir JOINsorgu ise ve sorgu sonuçlarını ilişkisel bir diziye alıyorsanız (PHP'deki gibi), hataya açıktır.

Olay şu ki

  1. eğer tablonun foosütunları varsa idvename
  2. tablo halinde barsütun var idve address,
  3. ve kodunuzda SELECT * FROM foo JOIN bar ON foo.id = bar.id

Birisi bir sütun ekler ne olur tahmin nameetmek barmasaya.

Şimdi çünkü kod aniden düzgün çalışmasını durduracak namesütun sonuçlarında görüntülenen iki kez ve sonuçları bir diziye depolamak eğer, ikinci veri name( bar.name) ilk üzerine yazacaktır name( foo.name)!

Çok kötü bir böcek çünkü çok açık değil. Bunu anlamak biraz zaman alabilir ve masaya başka bir sütun ekleyen bir insanın böyle istenmeyen bir yan etki beklemesinin bir yolu yoktur.

(Gerçek hikaye).

Bu yüzden kullanmayın *, hangi sütunları aldığınızı kontrol edin ve uygun olan yerlerde takma adları kullanın.


Tamam, bu durumda (bu tür nadir görüyorum) önemli bir sorun olabilir. Ancak joker karakterle sorgulayarak yine de kaçınabilirsiniz (ve muhtemelen çoğu kişi bunu yapabilir) ve yalnızca aynı sütun adları için bir diğer ad ekleyin.
pastırma,

4
Teoride, ancak kolaylık sağlamak için bir joker kullanıyorsanız, otomatik olarak varolan tüm sütunları vermek için ona güvenirsiniz ve tablolar büyüdükçe sorguyu güncellemek için asla uğraşmazsınız. Her sütunu belirtiyorsanız, cümleye bir tane daha eklemek için sorguya girmeye zorlanırsınız SELECTve bu umarız adın benzersiz olmadığını görürsünüz. BTW Büyük veritabanlarına sahip sistemlerde çok nadir olduğunu sanmıyorum. Dediğim gibi, bir keresinde bir kaç saatimi bu hatayı büyük bir PHP kodunu bulmak için harcadım. Ve şimdi başka bir dava buldum: stackoverflow.com/q/17715049/168719
Konrad Morawski

3
Geçen hafta bir saatimi bir danışman danışmandan almaya çalışıyorum. Bir SQL gurusu olması gerekiyordu ... Sigh ...
Tonny

22

Her sütunu sorgulamak birçok durumda tamamen meşru olabilir.

Her zaman her sütunu sorgulamak değil.

Verileri almak ve size geri göndermek için gerçek bir işle başa çıkmadan önce hangi sütunlarla başa çıkması gerektiğine karar vermek için kendi iç meta verilerinin etrafında dolaşıp dolaşmak zorunda olan veritabanı motorunuz için daha fazla iş. Tamam, dünyadaki en büyük ek yük değil, ancak sistem katalogları kayda değer bir tıkanıklık olabilir.

Ağınız için daha fazla iş var, çünkü yalnızca bir veya ikisini isteyebileceğiniz zaman istediğiniz sayıda alanı geri çekiyorsunuz . Biri [başkası] giderse ve her biri büyük metin parçaları içeren birkaç düzine fazladan alan eklerse, ani bir şekilde kolayca görünür bir nedenden ötürü aniden yere girersiniz. Eğer "where" cümlesi özellikle iyi değilse ve çok sayıda satırı geri çekiyorsanız, bu durum daha da kötüleşmiştir - bu, potansiyel olarak ağ üzerinden size doğru yol açan bir çok veridir (yani yavaş olacaktır).

Uygulamanız için daha fazla iş, muhtemelen umursamadığı tüm bu ekstra verileri geri çekmek ve saklamak zorunda kalmaktır.

Sütunların sırasını değiştirme riski vardır. Tamam, bu konuda endişelenmenize gerek olmamalıdır (ve olmayacak sen hepsini birden almak girelim, birileri [başka] tablo içinde kolon sırasını yeniden karar verirse, size gereken tek sütun seçerseniz) ama Dikkatlice hazırlanmış olan, CSV ihracatını salonun karşısındaki hesaplara verdiğiniz anda birden bire ortaya çıkar - yine de hiçbir kesin sebep yok.

BTW, yukarıda birkaç kez "başkası" demiştim. Veritabanlarının doğal olarak çok kullanıcılı olduğunu unutmayın; onlar üzerinde, senin yaptığını düşündüğün gibi kontrol sahibi olmayabilir.


3
Her zaman her sütunu sorgulamanın şema-agnostik tablo görüntüleme olanakları gibi şeyler için meşru olabileceğini düşünüyorum. Çok yaygın bir durum değil, yalnızca iç kullanım araçları bağlamında bu tür şeyler kullanışlı olabilir.
supercat,

1
@supercat Bu düşünebildiğim bir "SELECT *" için SADECE geçerli kullanım durumuyla ilgili. Ve o zaman bile sorguyu "SELECT TOP 10 *" (MS SQL'de) ile sınırlandırmayı ya da "LIMIT 10" (mySQL) eklemeyi ya da "WHERE ROWNUM <= 10" (Oracle) eklemeyi tercih ederim. Genellikle bu durumda, içerikten ziyade "hangi sütunların olduğu ve bazı örnek veriler" hakkında daha fazla şey olur.
Tonny

@Tonny: SQL Server, TOPsınırlamaları eklemek için varsayılan komut dosyalarını değiştirdi ; Kodun görüntülenmesi önemsediği kadar okur ve sorguyu elden çıkarmasının ne kadar önemli olduğundan emin değilim. Sorgu cevaplarının biraz tembel bir şekilde işlendiğini düşünüyorum, ancak ayrıntıları bilmiyorum. Her durumda, "meşru değil" demekten ziyade, "... çok daha az meşru" demek daha iyi olur ; Temel olarak, meşru davaları, kullanıcının programlayıcıdan neyin daha anlamlı olduğunu daha iyi bir fikre sahip olacağı şeklinde özetlerdim.
supercat,

@supercat Buna katılıyorum. Ve son cümlenize koyma şeklini gerçekten beğendim. Bunu hatırlamak zorundayım.
Tonny

11

Kısa cevap: hangi veritabanını kullandıklarına bağlıdır. İlişkisel veritabanları, ihtiyacınız olan verileri hızlı, güvenilir ve atomik bir şekilde elde etmek için optimize edilmiştir . Büyük veri kümelerinde ve karmaşık sorgularda, SELECTing * işleminden çok daha hızlı ve büyük olasılıkla daha güvenlidir ve 'code' tarafındaki birleştirmelerin eşdeğerini yapar. Anahtar-değer depoları, bu tür işlevlere sahip olmayabilir veya üretimde kullanılacak kadar olgun olmayabilir.

Bununla birlikte, SELECT * ile kullandığınız veri yapısını yine de doldurabilir ve kodun geri kalanını hesaplayabilirsiniz ancak ölçeklemek istiyorsanız performans darboğazları bulacaksınız.

En yakın karşılaştırma veriyi sıralamaktır: quicksort veya bubblesort kullanabilirsiniz, sonuç doğru olacaktır. Ancak, optimize edilmeyecek ve eşzamanlılık ortaya çıktığında ve atomik olarak sıralamanız gerektiğinde kesinlikle sorunlarınız olacaktır.

Elbette, RAM ve CPU eklemek, SQL sorguları yapabilen ve bir JOIN'in ne olduğu konusunda bile belirsiz bir anlayışa sahip bir programcıya yatırım yapmaktan daha ucuzdur.


SQL'i öğren! O kadar zor değil. Uzak ve geniş veritabanlarının "yerel" dilidir. Bu güçlü. Bu zarif. Zamanın testinden geçti. Ayrıca, SQL üyeliğini yapma konusunda gerçekten becerikli olmadığınız sürece, "kod" tarafındaki veritabanına katılmaktan daha verimli olan bir birleştirme yazmanın hiçbir yolu yoktur. Bir "kod birleştirmesi" yapmak için, tüm verileri her iki tablodan da basit bir 2-tablo birleştirmede çekmeniz gerektiğini düşünün. Yoksa endeks istatistiklerini mi çekiyorsunuz ve bunlara katılmadan önce hangi tablo verilerinin alınacağına karar vermek için kullanıyor musunuz? Öyle düşünmedim ... Veritabanını doğru kullanmayı öğrenin, millet.
Craig

@Craig: SQL, uzak ve geniş ilişkisel veritabanlarında yaygındır . Bu, tek DB türünden çok uzak olsa da ... ve daha modern veritabanı yaklaşımlarının genellikle NoSQL olarak adlandırılmasının bir nedeni var. : P Tanıdığım hiç kimse, ağır bir ironi olmadan SQL'e "şık" diyemezdi. İlişkisel veritabanları söz konusu olduğunda, yalnızca alternatiflerin çoğundan daha azını emer.
cHao

@cHao On yıllardır orada bulunan diğer çeşitli veritabanı türlerinin farkındayım . Pick "nosql" veritabanı sonsuza kadar olmuştur. "NoSQL" uzaktan bile yeni bir kavram değil. ORM'ler de sonsuza kadar sürdü ve her zaman yavaşlardı. Yavaş! = Güzel. Zarafete gelince (LINQ?), Bunun bir fıkra için makul veya zarif olduğuna ikna edemezsiniz: Customer customer = this._db.Customers.Where( “it.ID = @ID”, new ObjectParameter( “ID”, id ) ).First();Bkz. Suç Alma Zamanı , sayfa 2.
Craig

@Craig: Beni ORM'ye sokma. Neredeyse dışarıdaki her sistem korkunç bir şekilde yapıyor ve soyutlama her yere sızıyor. Çünkü ilişkisel DB kayıtları nesne değildir - en iyi ihtimalle bir nesnenin bir kısmının serileştirilebilir bağırsaklarıdır. Fakat LINQ gelince, gerçekten oraya gitmek istiyorsun? SQLish eşdeğeri var cmd = db.CreateCommand(); cmd.CommandText = "SELECT TOP 1 * FROM Customers WHERE ID = @ID"; cmd.Parameters.AddWithValue("@ID", id); var result = cmd.ExecuteReader();.... gibi bir şey ve sonra her satırdan bir müşteri oluşturmak için devam edin. LINQ pantolonunu atıyor.
cHao

@Craig: Verilmiş, olabileceği kadar zarif değil. Ama asla .net kodunu SQL'e dönene kadar istediğim kadar zarif olmayacak. :) Hangi noktada söyleyebilirsiniz var customer = _db.Customers.Where(it => it.id == id).First();.
cHao

8

IMO, bunun dolaylı ve dolaysız olduğu konusunda açık Kod yazarken, çalışmasını istiyorum çünkü çalışmasını sağladım, sadece tüm kısımlar orada olduğu için değil. Tüm kayıtları sorgularsanız ve kodunuz çalışırsa, devam etme eğiliminiz olur. Daha sonra bir şeyler değişirse ve şimdi kodunuz işe yaramazsa, orada olması gereken bir değeri arayan çok sayıda sorgu ve işlevi hata ayıklamak büyük bir acıdır ve tek referans değerleri *.

Ayrıca N katmanlı bir yaklaşımda, veritabanı şeması bozulmalarını veri katmanına ayırmak hala en iyisidir. Veri katmanınız * iş mantığına geçiyorsa ve büyük olasılıkla sunum katmanında *, hata ayıklama kapsamınızı katlanarak genişletirsiniz.


3
Bu muhtemelen buradaki en önemli nedenlerden biri ve oyların sadece küçük bir kısmı var. Üzerine gömülmüş bir kod temeli bakımı select *çok daha kötü!
Eamon Nerbonne

6

Çünkü eğer masa yeni sütunlar alırsa, ihtiyacınız olmadığında bile hepsini alırsınız. ile varcharsbu DB'den seyahat etmek gerekiyor ekstra çok fazla veri haline gelebilir

Bazı DB optimizasyonları, sabit uzunluktaki parçalara erişimi hızlandırmak için sabit olmayan uzunluktaki kayıtları ayrı bir dosyaya aktarabilirler;


1

Genel giderden ayrı olarak, ilk başta kaçınmak istediğiniz bir şey, bir programcı olarak, veritabanı yöneticisi tarafından tanımlanan sütun sırasına bağlı olmadığınızı söyleyebilirim. Hepsine ihtiyacınız olsa bile her sütunu seçersiniz.


3
Kabul ediyorum, yine de, her durumda sütun ismiyle belirlenen bir sonuçtan değerler çıkarmanızı tavsiye ederim.
Rory Hunter,

İkincisi, taşındı. Sütun adlarını kullanın, sütun sırasına bağlı değil. Sütun düzeni kırılgan bir bağımlılıktır. İsimler, bazı gerçek tasarım çabalarından türetilmiş olmalı (açıkça), sorgunuzdaki bileşik sütunları veya hesaplamaları veya çakışan sütun adlarını açıkça takas etmeli ve belirttiğiniz açık takma adı belirtmelisiniz. Ama siparişe güvenmek hemen hemen sadece koli bandı ve namaz ...
Craig

1

Yaptığı amaç için kullanmamanız için hiçbir neden görmüyorum - tüm sütunları bir veritabanından alın. Üç vaka görüyorum:

  1. Veritabanına bir sütun eklenir ve kodda da olmasını istersiniz. a) İle * uygun bir mesajla başarısız olur. b) Olmadan * çalışacak, ancak oldukça kötü olan ne beklediğiniz yapmaz.

  2. Veritabanına bir sütun eklenir ve kodda olmasını istemezsiniz. a) İle * başarısız olur; bu, anlamsızlığın "hepsini al" anlamına geldiğinden * artık geçerli olmadığı anlamına gelir. b) Olmadan * çalışacak.

  3. Bir sütun kaldırıldı Kod her iki şekilde de başarısız olacak.

Şimdi en yaygın örnek olay 1'dir (kullandığınızdan beri * ki bu, muhtemelen tümünü istediğiniz bir şeydir); * olmadan iyi çalışan kodlara sahip olabilirsiniz ancak beklenilen şeyi yapmazsınız ki bu kod, uygun bir hata mesajı ile başarısız olan kodun çok, çok daha kötü olduğunu söyler .

Bence hataya açık olan sütun dizinini temel alan sütun verilerini alan kodu dikkate almıyorum. Sütun adına göre almak çok daha mantıklı.


Senin önerin yanlış. Select *daha çok özel amaçlı sorgulama için kolaylık sağlamayı amaçladı, uygulama geliştirme amaçlı değil. Veya select count(*), sorgu motorunun bir indeks kullanıp kullanmayacağına karar vermesini sağlayan istatistiki yapılarda kullanım için, hangi indeksin kullanılacağı vb. Ve gerçek sütun verilerini döndürmüyorsunuz. Veya where exists( select * from other_table where ... ), yine en etkili yolu kendi başına seçmek için sorgu motoruna bir davetiye olan ve alt sorgu yalnızca ana sorgudan sonuçları sınırlamak için kullanılan bir cümle içinde kullanım içindir. Vb
Craig,

@Craig SQL'deki her kitabın / öğreticinin select *tüm sütunları alma anlamında olduğunu söylüyor ; Eğer uygulamanız gerçekten buna ihtiyaç duyuyorsa, kullanmama nedenini göremiyorum. İnşa edilme amacının select *tüm sütunları almak olmadığını belirten bir referansa (Oracle, IBM, Microsoft vb.) İşaret edebilir misiniz?
m3th0dman

Tabii ki, select *tüm sütunları almak için ... uygun bir özellik olarak, geçici sorgulama için, üretim yazılımında harika bir fikir olduğu için var. Nedenler bu sayfadaki cevaplarda zaten oldukça iyi ele alınmıştır, bu yüzden kendi ayrıntılı cevabımı oluşturmadım: •) Ağ üzerinden hiç kullanmadığınız verileri ağ üzerinde tekrar tekrar marşlayan performans sorunları, •) sorgu planı optimizasyon hataları (bazı durumlarda indekslerin kullanılamaması), •) sınırlı
Craig

Belki burada ya da burada select *gerçek bir üretim uygulamasında kullanımını haklı çıkaran bir kenar davası vardır , ancak bir kenar davanın doğası, bunun genel durum olmadığıdır . :-)
Craig

@Craig Sebepleri, kullanılmayan bir veritabanından tüm sütunları almaya karşı select *; Söylediklerimi gerçekten tüm sütunlara ihtiyacınız varsa, kullanmamanız için hiçbir neden göremiyorum select *; çok az olmasına rağmen tüm sütunların gerektiği senaryolar bulunmalıdır.
m3th0dman

1

Bu şekilde düşünün ... sadece birkaç küçük dize veya sayısal alan içeren bir tablodaki tüm sütunları sorgularsanız, toplam 100k veri. Kötü uygulama, ancak gerçekleştirecek. Şimdi bir resim veya 10 MB kelimelik bir belge tutan tek bir alan ekleyin. Şimdi hızlı performans sorgunuz derhal ve gizemli bir şekilde kötü performans göstermeye başlar, sadece masaya bir alan eklenmiş olduğundan ... bu büyük veri öğesine ihtiyaç duymayabilirsiniz, ama Select * from Tablebunu zaten yaptınız çünkü .


6
Bu sadece ilk birkaç cevapta , birkaç saat önce yapılmış bir noktayı ve diğer cevapların birkaçında tekrarlanan noktaya benziyor
gnat
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.