Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Veritabanı optimizasyonu

elementaryos

Veritabanları sıkıştırmaya gidiyorum.
Örnek olarak "yazılar, sayfalar, bilgi sayfaları, haberler" hepsini tek bir yerde toplayınca biraz farklı da olsa başka tablolarda gerekli olanlar bir diğeri için gereksiz olabiliyor. Fazladan tablolar ortaya çıkıyor.
Bu, yeni bir girdide boş sütunların kalmasını gerekli kılıyor fakat bunlar arayüzü kolaylaştırmak için olabilir, veritabanı bu tablolar boşsa zaten bunları tutmayacaktır diye düşünüyorum.
Daha basit sade olan bilgi sayfaları için bolca boş tablo kalıyor herbiri için ayrı yapmak mı daha mantıklı olur yoksa bu şekilde mi ?

10 tabloyu 1 tablo içinde tutmak hakkında fikirlerinizi alabilir miyim ?
Form gerektiren herşeyi bir tablo içine aldığımda benzer olmayan özelilkle cv'ye ait içerikler de birikmiş oldu. Bigdata ve hadoop'a giriş yapmayı düşünüyorum fakat bu analizleri nasıl yapabilirim ? Büyüdükçe bunlar anlaşılmaya başlar fakat yakınlığı bulunan tabloları türlere bölerek kullanmak bana pek mantıklı ve pratik gelmiyor.

Nedeniyse farklı tablolara aldığımda hem zamandan hem hepsini ayrı ayrı uyarlamak gerekiyor. Gerek view'ler olsun her biri için bir dolu controller. Gerekse her biri için crud sorguları girmeye tabloların çoğalmasına bir güncellemede tek tek uğraşmaya ve hatta tablolar arası bilgi taşımaya kadar.

Bu konuda emin değilim çünkü opencart, facebook gibi sitelerin veritabanları 100-150 şeklinde gidiyor. Önceden tabloları ayrı tutuyordum 70'e kadar çıkmıştım bu şekilde optimizasyon girişince 10'a düştü.
Şimdi ben birleştirmeyi daha pratik bulsam da çok kritik bir durum değilse devam edeceğim, eğer öyleyse ki bende öyle olduğuna dair bir izlenim pek oluşmadı bunu sıradan projelerde kullanacağım.

Ayrıca çokta json tutuyorum, inanılmaz pratikleştiriyor bazı tablolarda üçü aşkın json alanı mevcut. Aramalarda sıkıntı oluşturabilir özellikle büyük verilerde diye düşünüyorum sizin düşünceleriniz neler ? Jsonlar için böyle bir arama yöntemi biliyor musunuz.
Bunu şunun içinde soruyorum projede bir veritabanı yönetisi olacaksa bunları nasıl düşünür bilmiyorum ve zaten bu çeşit sorguları büyük verilerde başka sunucular da sadece o alandaki işleri yapması sağlanabiliyor. Jsondan okumak ne kadarlık bir milisaniyeye malolabilir, Borsa da kuruş farkıyla büyük ölçekli zararlar elde edilebildiğinden.
Bu arada benimte fazla zamandır tecrübem var tahmin yürütebiliyorum kendim ama özellikle biliyorsanız yazabilirseniz çok sevineceğim. Fikirden çok bilgi olursa.

elementaryos

Çokta merak ettiğim bir konuydu, fikri olan yok mu ?

mgsmus

Çok fazla içerik tipi ve kayıt yoksa sayfa, haber, makale vs. tarzı içerikleri tek bir tabloda tutmanın bir sakıncası yok. Bir takım konularda da size kolaylık sağlar. Tutacağınız alanlar içerik tiplerinin ortak/benzer alanları olsun. Matematiksel olarak ifade edecek olursak Sayfa ∩ Haber ∩ Makale = {Başlık, Slug, İçerik, Yayınlanma Tarihi} gibi mesela.
İçerik tipine göre ek bilgileri ise, örneğin sayfa özellikleri gibi, JSON olarak tutabilirsiniz çünkü JSON artık veritabanları için önerilen bir format ama gidip de LONGTEXT gerektiren ya da Full-Text index içerisinde yer alacak bir bir alanı da JSON içinde tutmak çok da mantıklı olmaz. Tablo üzerinde string fonksiyonları, regexp gibi özellikleri kullanmanıza sebep olabilir ki bu da yavaşlama demektir.
Sadece bir içerik tipine özel alanlar, üzerinde tarama yapmanızı gerektirecek bir şeyler içeriyorsa ayrı tabloda tutabilirsiniz. Kesin bir şey söyleyemiyorum çünkü çok değişken bir durum.

Optimizasyon kısmına bir şey diyemiyorum, genel optimizasyon kuralları zaten belli, onun dışında elde ettiğiniz sonuçtan memnunsanız optimize etmişsinizdir ya da optimizasyona gerek yoktur demektir.

deathisonitsway

Bazı bilgiler teoride iyi gozukuyor yada öyle duruyor ancak gerçek hayatta cok sıkıntılar doğurur. Fikirden çok bilgi verilemez maalesef çünkü deneyimsel bir bilgidir bu teorik işlemez...

10 tabloyu 1 tablo içinde tutmak hakkında fikirlerinizi alabilir miyim ?

Cümle çok masum durmuyor maalesef.Big data ile ilgili olmazsa olmaz tek şey,datanın developer tarafından iyi maintenable edilebiliyor olması gerekir.
Bir diğer etken --her ne kadar aynı gibi dursalarda -- sürdürülebilirlik.

10 tabloyu 1 tabloda tutmak çok masum değil,bunu 10 kere düşündükten sonra karar vermelisin.O data büyüyecek ve bir çok farklı endpoint tarafından yoğun bir bombardıman atışına tutulacak demektir.Bu da okumayı ve yazmayı güçleştirecektir.Birleştirmek o tablonun fieldlarını çoğaltır ve dokumantasyon ihtiyacı doğurur.Büyük projeler için sağlıklı değildir.Her tablo spesifik olarak kendi işini yapmalıdır.Ha joinlemek daha mı iyi? herşeyi 1 yerde tutmanın getirdiği dezavantaja-avantaja göre değişir bunun cevabı.

En nihayetinde iyi düşünmen gerekir,zaten database mimarisi applicationun iyi mi kötü mü olduğunu belirlemede öncül etkendir.Big data zor iş.Her big data sana şunu gösterir aslında.Bu databaseden ben sağlıklı rapor çıkartabiliyor muyum? Önemli olan bunun cevabıdır.Yoksa insert çöplüğüdür yani bas geç...

Json data tutmak çok iyi bir şey,ki bende çok severim ve yaparım.Ama güncellemesini iyi yapan bir kod yapısına sahip olmanız gerekir.Cok iyi tasarlandığında süper bir nosql gibi hizmet eder uygulamana.

Ben büyük projelerin yada big dataya sahip olacak projelerin yoğun baskı altında ne türden yada hızda cevap verebileceklerini mühendislik adı altında bir kategoriye konulup öyle incelenilmesi gerektiğine inanan biriyim.Her developer maalesef bu türden bir soruya cevap verebilecek kapasitede değiller.Kod yazmak ayrı bir şeydir,Algoritma yeteneği ve sürdürülebilirlik başka bir şeydir.Maalesef bizim ülkede bu türden şeyler çok sağlıklı yürümüyor.En iyi firmalar bile kötü tasarımı yolda düzeltiriz mantığıyla yola çıktıkları için o tasarım düzelmiyor maalesef...

elementaryos

Cevaplar için teşekkür ederim ben de aynı şekilde düşünüyorum zaten hissettirirse o an yapmak şimdi yapmaktan iyidir diye düşünüyorum böyle çok fazla güce sahip oluyorum. wordpresste olması uygun olabilecek ama olmayan akıllıca kullanımlar buldum. Fazla dinamik interaktif çalışıyor. Özellikle jsonlar da barındırdığı için page builder yazmayı bile düşünüyorum. Önceden sürünüyormuşum diyorum. Benimsediğim buna benzer yöntemlerle alışılagelmiş şeyleri son aylarda çok fazla bozuyorum . Bu nedenle benzeri şeyler de var terkettiğim. Gördüğümüzü gördüğümüz gibi yazıyoruz sonuçta.
Bir paneli canavar gibi geliştirmek istiyorum daha nasip olmadı ama bakalım.

deathisonitsway

elementaryos yazdıCevaplar için teşekkür ederim ben de aynı şekilde düşünüyorum zaten hissettirirse o an yapmak şimdi yapmaktan iyidir diye düşünüyorum böyle çok fazla güce sahip oluyorum. wordpresste olması uygun olabilecek ama olmayan akıllıca kullanımlar buldum. Fazla dinamik interaktif çalışıyor. Özellikle jsonlar da barındırdığı için page builder yazmayı bile düşünüyorum. Önceden sürünüyormuşum diyorum. Benimsediğim buna benzer yöntemlerle alışılagelmiş şeyleri son aylarda çok fazla bozuyorum . Bu nedenle benzeri şeyler de var terkettiğim. Gördüğümüzü gördüğümüz gibi yazıyoruz sonuçta.
Bir paneli canavar gibi geliştirmek istiyorum daha nasip olmadı ama bakalım.

Ticari bir şey değilse,open source repona at pr lıyarak katkıda bulunuruz

zaten laravel nasıl düzeldi bugüne kadar,pr'larla...ilk çıktığında çekirdeği çok kötüydü.Şimdi herşeyi düzelttiler.