arkadaşlar teşekkürler ilgilendiğiniz için.. zaman buldukça hep forumdayım.. demek istediğini anladım..
başka forumlardan ve kaynaklardan da araştırdığım kadarıyla edindiğim bilgiyi sizlerle de paylaşayım. tabloda 50 sütunun 45i kadarı tinyint tipinde olduğu için yani fazla yer kaplamadığı için istenilen satırı(ları) bulması ve okuması cok zor olmazmış.. ne kadar doğru şu anda bilemiyorum...
ama tabloyu 50 sütunlu hali ile kullanmaya karar verdim..
Bu tabloda tuttuğun veriler ve amaçlanan sorğular önemli. Duruma göre 50 sütun uygun olabilir ama düşük ihtimal. Veri tabanı yapısını kavrama aşamasındayken hepsini aynı tabloda tutma eğilimi vardır.
Tüm durumlar için doğru olmaz ama şöyle bir mantık yazabilirim; amaç veri tekrarı yapmadan amaçlanan sorgulara göre verileri olabildiğince çok tablolara bölmek olmalı.
tabloyu en stabil şekilde kullanmaktır (sakın stabil ne deme pls :) ) örnek vereyim mesela kimlik tablon var içinde ad soy ad il telefon var şimdi en basit optimizasyon örneğini verceğim sen gider il field ında izmir istanbul ankara diye tutarsan bu olmaz tablo şiştikçe şişer peki napacaksın 2 haneli bi alan açıp oraya illerin kodlarını yazdıracaksın 35 34 06 gibi bu kodlarıda il table ı açıp ilkod ilad diye 2 alanla tutup kullanacaksın en basit böyle anlatabilirim sanırım ya da ne bilim şöyle ibşey var tel no dedin bir telefon numarası en fazla kaç hane olur 7 numara 3 de alan kodu de 10 olsun sen alır oraya 30 dersen olmaz bu alana char dediğini düşünelim 1 char=1byte(özel bazı karakterler hariç) kayıt başına 20 byte kaybedersin bu fazla bişey ifade etmiyor gibi görünüyor ama aynı hataya bende düştüm 2 byte kayıptan dağlar tepeler oldu şuan aktif çalışan 4 milyon satırlık tablolara sahip bi sistemim var datasını sallama yaptık baştan gidince akıllandık yeni datayı optimize etmemiz 1 ayımızı aldı ama 2 senedir canavar gibi durmadan çalışıyor neyse çok konuştum galiba umarım yardımcı olmuşumdur. Muhabbetle....
Bu mesaja @_qwerty_, @kopkop21 cevap verdi. Cevapları Gizle
Bu mesaja 1 cevap geldi. Cevapları Gizle
Bu mesaja @kopkop21 cevap verdi. Cevapları Gizle
özel durumlardan kastın ne? biraz açıklar mısın?
Bu mesaja 1 cevap geldi. Cevapları Gizle
< Bu mesaj bu kişi tarafından değiştirildi Guest -- 24 Kasım 2006; 22:43:56 >
Bu mesaja @looter cevap verdi. Cevapları Gizle
Böyle durumlarda hedefli dizini okutma mantıgına gidebilirsin...
Ara yerine şu satırı oku demelisin...Yoksa işlemler çok yavaşlar.
Umarım anlamışsındır
Bu mesaja 1 cevap geldi. Cevapları Gizle
işleri vardır
< Bu mesaj bu kişi tarafından değiştirildi looter -- 25 Kasım 2006; 13:00:54 >
Bu mesaja 1 cevap geldi. Cevapları Gizle
başka forumlardan ve kaynaklardan da araştırdığım kadarıyla edindiğim bilgiyi sizlerle de paylaşayım. tabloda 50 sütunun 45i kadarı tinyint tipinde olduğu için yani fazla yer kaplamadığı için istenilen satırı(ları) bulması ve okuması cok zor olmazmış.. ne kadar doğru şu anda bilemiyorum...
ama tabloyu 50 sütunlu hali ile kullanmaya karar verdim..
Bu mesaja 1 cevap geldi. Cevapları Gizle
Tüm durumlar için doğru olmaz ama şöyle bir mantık yazabilirim; amaç veri tekrarı yapmadan amaçlanan sorgulara göre verileri olabildiğince çok tablolara bölmek olmalı.
Değişiklik: "tekrar" -> "tekrarı"
< Bu mesaj bu kişi tarafından değiştirildi Guest -- 27 Kasım 2006; 8:07:10 >
Bu mesaja @looter cevap verdi. Cevapları Gizle
5-10 tablodan birden sorgu yaptıgı halde çok hızlı işliyor...
Bunları aynı tabloda yapmayı denediğimde oldukça yavaşlamıştı
tabloyu en stabil şekilde kullanmaktır (sakın stabil ne deme pls :) ) örnek vereyim mesela kimlik tablon var içinde ad soy ad il telefon var
şimdi en basit optimizasyon örneğini verceğim sen gider il field ında izmir istanbul ankara diye tutarsan bu olmaz tablo şiştikçe şişer peki napacaksın 2 haneli bi alan açıp oraya illerin kodlarını yazdıracaksın 35 34 06 gibi bu kodlarıda il table ı açıp ilkod ilad diye 2 alanla tutup kullanacaksın en basit böyle anlatabilirim sanırım ya da ne bilim şöyle ibşey var tel no dedin bir telefon numarası en fazla kaç hane olur 7 numara 3 de alan kodu de 10 olsun sen alır oraya 30 dersen olmaz bu alana char dediğini düşünelim 1 char=1byte(özel bazı karakterler hariç) kayıt başına 20 byte kaybedersin bu fazla bişey ifade etmiyor gibi görünüyor ama aynı hataya bende düştüm 2 byte kayıptan dağlar tepeler oldu şuan aktif çalışan 4 milyon satırlık tablolara sahip bi sistemim var datasını sallama yaptık baştan gidince akıllandık yeni datayı optimize etmemiz 1 ayımızı aldı ama 2 senedir canavar gibi durmadan çalışıyor
neyse çok konuştum galiba umarım yardımcı olmuşumdur.
Muhabbetle....