PHP & MYSQL=Stratejik,Tasarruf Ettiren,Performansı Arttıran ALGORİTMA!

Merhabalar...

Stratejik bir konuda en iyi çözümü bulmaya çalışıyorum.

Bilgimin standart düzeyde olduğu bu konuda ideal çözüme ulaşmak için ustaca, profesyonelce olan görüşlerinizi öğrenmek isterim mümkünse...


Projenin çözüm aradığım kısmının yapısının simülasyonu şöyle;


1) 1.000 üye mağaza var

2) Her mağazanın 100 ürünü var

3) Tüm mağazaların tüm ürünleri => table_products_companies => tablosuna kaydediliyor ve oradan çekiliyor.

Toplamda 100 x 1.000 = 100.000 ürün satırı olan bir tablonun performansı çok düşüreceğini zannediyorum.

4) İyi haber şu: mağazaların ürünleri aşağı yukarı aynı;

Toplamda 1.500 civarında ürün var ve bu ürünlerin isimleri aynı.

Mağazalar ürün eklerken bu hazır ürünleri seçiyorlar ama
* kendi fiyatlarını belirliyorlar
* kendi ürün açıklamalarını yazıyorlar



Bu mimariyi nasıl minimalize edebilirim?



Bu ortak kullanılan 1.500 ürün için;

*) table_products_standard => adında ayrı bir veri tablosu oluştursam, tüm standart ürünler bu tabloda olsa

*) table_products_companies tablosu ile join bağlantısı kursam

bunun devamında ne yapmak gerekir ki,

Toplam satır sayısı 100.000'den birkaç bine inebilsin...???



Sizce böyle bir yol varsa bile performans konusunda işe yarar mı?

Yoksa daha karışık işlemleri de beraberinde getireceği için getirisi ve götürüsü düşünüldüğünde gereksiz bir yol olarak tanımlanabilir mi?

Diğer artıları ve eksileri neler olur?




Çok teşekkür ederim şimdiden...

100.000 :) mysql için çerez bu sayı.

php kodun içerisinde bu tabloya attığın sorgular içerisindeki where koşulu olan alanlara index atarsan, milisaniyeler içinde cevaplar alırsın

uyeler
id | uyeadi
(integer) | (varchar)

urunler(1500 adet olan ürünlerin tümü)
id | urunadi
(integer) | (varchar)

satistaolanurunler
id | urun_id | uye_id
(integer) | (integer) | (integer)

Senaryonda ki satır sayısı çok yüksek değil bu arada

Güzel ve ferahlatan bir yanıt, teşekkür ederim üstad.

Ferahlatan bir yanıt daha, sevindim...

Açık ifade edeyim: diğer katkınızıı anlayamadım henüz...

Esas olarak öğrenmek istediğim şu ve/veya benzer yöndeki çözümler;


Mesela:
1.500 ürünün adını, fiyatını, açıklamasını aralarına virgül koymak kaydı ile tek sütuna kaydetmek ve o sütundan çekmek...

NE KADAR MAKUL OLUR KESTİREMİYORUM MEVCUT BİLGİ SEVİYEM İLE...!?


Mesela;
Başka bir örnek yok zihnimde şu an... :)


Ayrıca ben char'ı tercih ediyorum, bu konuda bir şerhiniz var mıdır?


Açıklık kazandırırsanız sevinirim üstadım...

Teşekkürler...

Mesela:
1.500 ürünün adını, fiyatını, açıklamasını aralarına virgül koymak kaydı ile tek sütuna kaydetmek ve o sütundan çekmek...
Böyle yapmanız sorunuzda ki tasarruf vurgusuna ters.
Joinle tablo birleştirme de zorlaniyorsun sanırım.
Yinede yukarıda belirttigin yola basvurmak zorunda kalırsanız virgülle değil tek hücrede json tipinde tutmanız daha mantıklı olurdu.
Bunun için phpmyadmin de sütun tipini json secmelisiniz. Verinizide json formatta insert, update etmelisiniz. Json veriyi kendi içinde bir veritabani tablosuymus gibi kullanmak hem keyifli hem kolay. Tek yapmanız gereken select ile cagirdiginizda json decode edip array olarak basmak.
Virgül ile eklerseniz gereksiz yere implode explode fonksiyonlariyla ugrasmak zorunda kalacaksın.

Char ile Varchar arasındaki farkı başka bir siteden alintiladim. Buna okuduktan sonra sen karar vermelisin.

CHARsabit uzunlukta iken VARCHARdeğişken uzunluktadır. Bu, bir CHAR(x) dizesinin, boşluklar dahil olmak üzere tam olarak x karakter uzunluğunda olduğu anlamına gelir . Bir VARCHAR(x) dizesi en fazla x karakter içerebilir ve sondaki boşlukları keser, bu nedenle belirtilen uzunluktan daha kısa olabilir.

Verimlilik açısından, çılgınca değişken uzunlukta dizeleri saklıyorsanız , o zaman bir VARCHAR kullanın , uzunluk her zaman aynıysa, biraz daha hızlı olduğu için bir CHAR kullanın .

Ayrıca, bir CHAR değerinin uzunluğunun 0 ila 255 arasında herhangi bir değer olabileceği ve bir VARCHAR değerinin maksimum uzunluğunun 65.535 olduğu maksimum uzunluk bakımından da farklılık gösterirler .


Okan_IŞIK Üstadım öncelikle bu cevabınız için de teşekkür ederim.

"Böyle yapmanız sorunuzda ki tasarruf vurgusuna ters.
Virgül ile eklerseniz gereksiz yere implode explode fonksiyonlariyla ugrasmak zorunda kalacaksınız."
Süper! İşte duymak istediğim net ve yol gösterici bir cümle.
Hemen eledik bu seçeneği sayenizde.

"Joinle tablo birleştirme"
Çok şükür orada bir sıkıntı yok ama joinden sonrasını canlandıramadım zihnimde...



"Yinede yukarıda belirttigin yola basvurmak zorunda kalırsanız virgülle değil tek hücrede json tipinde tutmanız daha mantıklı olurdu.
Bunun için phpmyadmin de sütun tipini json secmelisiniz. Verinizide json formatta insert, update etmelisiniz. Json veriyi kendi içinde bir veritabani tablosuymus gibi kullanmak hem keyifli hem kolay. Tek yapmanız gereken select ile cagirdiginizda json decode edip array olarak basmak."


json tipi sütun , insert, update yöntemi => virgül, implode, explode yönteminden çok çok daha iyi.

Bu bilgi de çok net ve yol gösterici oldu üstad.

FAKAT ŞURASI ÇOK KRİTİK ŞU ANDA;
BU YÖNTEM DE "tasarruf vurgusuna ters" MİDİR!?

Bir başka ifade ile;
WHERE SORGUSU ile çalışmak satır sayısının çoğalması haricinde her açıdan daha iyi diyebilir miyiz?


Bu 3 seçenek dışında da başka seçenek yok sanırım... !?

&

Char ile Varchar kıyaslaması için paylaştığınız yazı çok yararlı oldu.
Yeni detaylar öğrendim sayenizde.

Çok sağolunuz, bugün vaktinizi aldık ama son netleştirici bir yanıt daha verirseniz çok makbule geçer...

Her halikarda tekrar teşekkür ederim...

Hakkınızı helal ediniz lütfen...

Üst mesajlarda olası bir tablo kurgusu yapmıştım.
Bu kurgu ile kullanmak daha mantıklı
Birbirinden farklı 1500 adet ürün var demiştiniz, iyi haber bu ürünler tüm bayiler için standart. Yani bu ürünlerin dışında ürün yok, kabaca hesap yaparsak 100 üye var.
100x1500 = 150.000 adet çoğu birbiriyle aynı ürünlerin listesi olduğu yığın olmuş oldu. Öyle ki her ürün farklı üyeler için gereksiz yere 100 kere tekrar ediyor. Sende bundan kaçmak istiyorsun,
olası tüm ürünleri 1500 adet olarak bir tabloda tutalım.
uyenin id si ve 1500 luk ürün tablomuzdaki datamizdan uyelerin satmak istediği ürünün idsini de 3.bir tabloda tutalım.
satista_olan_urunler
id | uyeid | urunid
int | int |int

Bu 3. tabloda sadece uye id, urun id, ve tablonun kendi id si olan 3 sutunluk verimiz olur.
Kabaca hesabimiz yaparsak satır sayısı bakımından yine makximum 100×1500 adet satirimiz olur ancak, maksimum dememin nedeni anladığım kadarıyla her magaza 1500 ürünün tamamını satmıyor. Dolayısıyla bu sayı 150.000 satırdan çok çok az olacaktır.
Bu üçüncü tabloda ürünün adı, fiyati, rengi, ağırlığı, stok adedi, bedeni iviri ziviri artık tekrar edilmiyor. Avantajın bu 150.000 kere bu bilgileri tekrar etmemiş oldun 1500 kere etmiş oldun. 150.000 kere tekrar ettiğin şey tabloların sadece kimlik numaraları oldu.
Yani üst mesajlarda verdiğim tablo örneği senin için en uygun olanıdır.

Okan_IŞIK üstadım önce şunu bir söyleyeyim;

"ALLAH RAZI OLSUN..."

Verdiğiniz içten cevap ve emek için teşekkür edebiliyorum sadece, bir gün belki ben de size katkı sağlayıp ödeşebilir hale gelirim umarım...

Bu son cevabı yazmadan önce tekrar tekrar değerli önerinizin üzerinden geçtim.

Sanırım 99% anladım aktarmak istediğiniz mantığı ve yöntemi.

Atladığım bir yer yoksa eğer sizin önerinizin kapsamadığı detay şu;

İlk mesajımda şunu ifade etmiştim:

"Mağazalar ürün eklerken bu hazır ürünleri seçiyorlar ama
* kendi fiyatlarını belirliyorlar
* kendi ürün açıklamalarını yazıyorlar"

Bu kısmı daha iyi vurgulamalıydım sanırım...

&

Sizin senaryonuz fiyatların ve açıklamaların aynı olduğu varsayımına dayanıyor yanlış anlamadıysam...

&

(Bu arada renk, stok, beden sütunları yok.)

Sütunlar tam olarak şunlar;

* product_id => malum
* product_number => farklı sıra numarası verebiliyorlar
* product_category => farklı isim verebiliyorlar
* product_name => standart isim
* product_desc => farklı açıklamalar yapıyorlar yada boş bırakabiliyorlar
* product_price => farklı fiyatlar veriyorlar
* product_price_c => farklı kampanya fiyatları veriyorlar yada boş bırakabiliyorlar
* product_fav => favori ürün olarak belirleyebiliyorlar yada boş bırakabiliyorlar


Yani product_name dışındaki tüm sütunların içindeki değerler değişkenlik gösteriyor...

Bu da işleri değiştiriyor sanırım...

Yollar WHERE SORGUSUNA ÇIKIYOR gibi... !?

Aynı fikirde iseniz birşey yazmamanızdan bunu anlarım.

Tekrar teşekkür ederim...

Farklı olabilme ihtimali olan alanları da 3. tabloya taşımalıyız o halde. 3. Tabloda olan veri miktarı her halükarda az olacaktır. Satır sayısı bakımından özellikle.