mysql - kaç sütun çok fazla?

111

70 sütuna kadar çıkabilecek bir tablo kuruyorum. Tabloya her erişildiğinde sütunlardaki bazı verilere ihtiyaç duyulmayacağı için şimdi onu bölmeyi düşünüyorum. Sonra tekrar, eğer bunu yaparsam birleştirme kullanmak zorunda kalırım.

Varsa hangi noktada çok fazla sütun olarak kabul edilir?

sql mysql

— başsız çivi
kaynak

6

Her zaman SELECT * kullanmak zorunda değiliz. Belirli bir durum için her zaman ihtiyaç duyduğumuz sütunları seçme seçeneğimiz vardır.

— APC

3

70 sütun mu ?! Bunlardan kaç tanesi boş olamaz?

— OMG Ponies

1

Asıl soru şu ... tablolarınızı normalleştiriyor musunuz? Performansı kasten denormalize etmediğiniz sürece 70 alışılmadık bir miktardır (çok az şey 70 benzersiz özelliğe sahiptir). Performans uğruna normalden normalleştiriyorsanız, ChssPly76'ya, veritabanının kurtulmanıza izin verdiği her şeyi kullanabileceğiniz konusunda hemfikirim.

— Godeke

2

@KM. bu bir şaka mı olmalı? MySQL'de yeniyim ve alamıyorum, JOIN'in denenecek ve kaçınılacak bir şey mi yoksa iyi bir şey mi olduğunu mu söylüyorsunuz?

— Elia Iliashenko

2

Birleştirmeler SQL'in temel bir parçası olsa da, birleştirme uğruna katılmak, sahip olduğunuz uygulama ne olursa olsun performansı ve sürdürülebilirliği muhtemelen düşürecektir.

— jeteon

142

Veritabanı tarafından desteklenen maksimum sınırın üzerine çıktığında çok fazla olduğu kabul edilir .

Her sorgu tarafından her sütunun döndürülmesine gerek duymamanız tamamen normaldir; bu nedenle SELECT ifadesi, ihtiyacınız olan sütunları açıkça adlandırmanıza izin verir.

Genel bir kural olarak, tablo yapınız alan modelinizi yansıtmalıdır; Aynı varlığa ait gerçekten 70 (100, sizde ne var) öznitelikleriniz varsa, bunları birden çok tabloya ayırmanız için hiçbir neden yoktur.

— ChssPly76
kaynak

29

@KM - bu yüzden "alan modelinde aynı varlığa ait öznitelikler" dedim. Tablodaki çok sayıda sütun, tabloyu normalden arındırmaz; Sütunların önemli olduğunu ifade ettiği şey budur. Ayrıca, normalleşme kesinlikle iyi bir şey olsa da, hayatın tüm sorunlarına bir çözüm DEĞİLDİR. Hileli soru - SO sorusunun / cevabının yanındaki oy sayısının select count(*) from votesher seferinde hesaplandığını mı düşünüyorsunuz, yoksa bunun normal dışı olduğunu mu düşünüyorsunuz? Bu SO veritabanını kötü ve Jeff Atwood'u deli mi yapıyor?

— ChssPly76

@ ChssPly76, bir nesne modeli değil ilişkisel bir veritabanıdır. tablolar, satırlar ve sütunlar vardır, maksimum performans istiyorsanız bu kısıtlama içinde çalışın, performans uğruna kolaylık sağlamak için nesnelerinizi taklit edin. Öyleyse bir kişi hakkındaki her bilgi aynı satırda saklanmalı mı? hayır, onları ayırın ve farklı tablolara gruplayın (önceki yorumumdaki örneğimi kullanarak): "Kişi", "Aktiviteler" "Sağlık Kayıtları". Performans nedenleriyle bir SUM depolamak, birleştirmeleri önlemek için tüm verileri 70 sütunda tutmaktan tamamen farklı bir konudur.

— KM.

20

"NumberOfTeethPulled" Kişi kaydının bir parçası olmalı mı? Hayır, muhtemelen hiç saklanmamalıdır - eğer alan modeliniz bu kadar detay gerektiriyorsa bu bilgiyi "ToothExtractionRecord" dan alırsınız. Ama bu SİZİN (ve daha çok uydurulmuş diyebilirim ki) örnek - benim açımdan benim açımdan hiçbir ilgisi yok: bir tablodaki çok sayıda sütun, tablonun normal dışı olduğu anlamına GELMEZ. Emlak sözleşmelerini / satın alma emirlerini / diğer mali belgeleri birkaç örnek vermek gerekirse düşünün. Birden çok tabloya bölünebilirler mi? Evet. Bunu yapmak için herhangi bir sebep var mı? Pek sayılmaz.

— ChssPly76

1

+1, bu çok komikti. Başka bir tablo oluşturuyorsanız ve bu sadece 1: 1 ilişki olacaksa, muhtemelen onu ana tabloya dahil etmelisiniz. Yerden tasarruf etmeyecek, verileri talep etmezseniz, masada olmasa bile o kadar iyi performans göstermeyecektir. Şu anda aklıma gelen tek yasal neden, SSN, kredi kartı bilgileri vb. Gibi hassas bilgilerin olup olmadığıdır ...

— Vandel212

1

Bir tablomda 15 sütun varsa ve diğerinde 300 sütun varsa, iki tablonun birincil anahtarı aynıdır. İki tablodan bir sütun seçin, performans önemli ölçüde farklılık gösterir mi?

— bir teklif

28

Tabloyu daha az sütunla birkaç taneye bölmenin bazı faydaları vardır, buna Dikey Bölümleme de denir . Burda biraz var:

Çok sayıda satır içeren tablolarınız varsa, MySQL'in tablodaki tüm dizinleri yeniden oluşturması gerektiğinden, dizinleri değiştirmek çok uzun zaman alabilir. Dizinlerin birkaç tabloya bölünmesi bunu daha hızlı hale getirebilir.
Sorgularınıza ve sütun türlerinize bağlı olarak, MySQL diske geçici tablolar (daha karmaşık seçim sorgularında kullanılır) yazıyor olabilir. Bu kötü, çünkü disk giriş / çıkış büyük bir dar boğaz olabilir. Bu, sorguda ikili verileriniz (metin veya blob) varsa oluşur.
Daha geniş tablo, daha yavaş sorgu performansına yol açabilir.

Zamanından önce optimize etmeyin, ancak bazı durumlarda daha dar tablolardan iyileştirmeler elde edebilirsiniz.

— jonstjohn
kaynak

5

MySQL'in neden sadece tek bir tane değiştirilmişse tablodaki tüm dizinleri yeniden oluşturması gerekiyor?

— Petr Peller

Aynı şeyi ben de merak ediyordum . MySQL neden tablodaki tüm dizinleri yeniden oluşturuyor? Yukarıda belirtilen ifade doğru mu?

— maj

13

Normalleşme kurallarını ihlal ettiğinde çok fazla. Veritabanınızı normalleştiriyorsanız bu kadar çok sütun elde etmek oldukça zordur. Veritabanınızı, belirli bir db platformu için optimizasyonla ilgili herhangi bir yapay kural veya fikir etrafında değil, sorunu modelleyecek şekilde tasarlayın.

Aşağıdaki kuralları geniş tabloya uygulayın ve muhtemelen tek bir tabloda çok daha az sütununuz olacaktır.

Yinelenen öğeler veya öğe grupları yok
Birleştirilmiş bir anahtara kısmi bağımlılık yok
Anahtar olmayan niteliklere bağımlılık yok

İşte size yardımcı olacak bir bağlantı .

— JohnFx
kaynak

17

It is pretty hard to get that many columns if you are normalizing your database.Göründüğü kadar zor değil.

— Petr Peller

5

Kesinlikle o kadar zor değil. İnsanlar buradaki kısımların etrafındaki normal formları gerçekten anlamıyor gibi görünüyor. 10000 sütununuz olabilir ve STILL normalize edilebilir (en yüksek normal forma bile).

— Hejazzman

2

@foljs Ve tam da kabul edilen denormalizasyon uygulamasının devreye girdiği yer burasıdır. Bir kavşaktaysanız ve bir araba size doğru gelmek üzereyse, ışığın yeşile dönmesini beklemek aptalca olur. Yoldan çekilmelisin. Kırmızı ışıkta geçmek teknik olarak yasal olmayabilir, ancak durum = denormalizasyon

— kullanıcı3308043

3

Arabalardan bahsetmeye başladığında beni kaybettin. Alaka düzeyinin ne olduğu hakkında hiçbir fikrim yok.

— JohnFx

2

Bununla birlikte, bu senaryoda tek bir veri tablosu ile karmaşık sorguları nasıl yaparsınız, yapamazsınız, bunun çalışması için programlama diline ve diğer çeşitli şeylere büyük ölçüde güvenmeniz gerekir! Bu yüzden, 170 sütunlu bir tabloya geri dönebilirim, çünkü "JOIN" sorguları ve ayrı tabloların çalışması gereken ekstra karmaşık programlara sahip olmak bana zaman kaybı gibi görünüyor. Sanırım KISS prensibinin büyük bir hayranıyım.

— Vlad Vladimir Hercules

0

Tüm özellikler aynı varlığa ait olmadığı ve birbirine bağlı olmadığı sürece bu bir sorun değildir. Hayatı kolaylaştırmak için içinde JSON dizisi depolanan bir metin sütununa sahip olabilirsiniz. Açıkçası, her seferinde tüm özellikleri almakta bir probleminiz yoksa. Her ne kadar bu, onu bir RDBMS'de depolama amacını tamamen ortadan kaldıracak ve her veritabanı işlemini büyük ölçüde karmaşıklaştıracaktır. Bu nedenle, veritabanı boyunca izlenmesi önerilen bir yaklaşım değildir.

— Zeeshan Ch
kaynak

0

Aynı tabloda çok fazla sütun olması, çoğaltmada da büyük sorunlara neden olabilir. Master'da meydana gelen değişikliklerin slave'e kopyalanacağını bilmelisiniz. Örneğin, tablodaki bir alanı güncellerseniz, tüm satır w olacaktır.

— Bugün
kaynak