Laravel ile Yemek Uygulaması Veritabanı Tasarımı Hakkında Yorumlarınız

Herkese merhabalar;

Devamlı yemek işleri ile uğraşan bir arkadaşım kendi tariflerini mobil uygulama ekleyebileceği bir mobil uygulama istedi benden. Veritabanı kısmında bir tasarım yaptım.Laravel ile api kısmını yapmak istiyorum. Veritabanı ile yeni tanışıyorum. Takipçilerin olduğu kısım tam olması gerektiği gibi mi. ? Bir bakabilir misiniz. ?

https://drive.google.com/file/d/1_7e...ew?usp=sharing

• Turkce isimlendirmeler kullanmayin ve isimlendirmeleri snake_case olarak yapin
• Gereksiz on ekler kullanmaktan kacinin. Orngenin food_name ismi gerksiz, name tek basina yeterli cunku tablo adi zaten food.
• tarifAdinlar tablosunda niye tarif_adi diye field var anlayamadim. Zaten tarif_id var. Tarif adi iliskiden cekilebilir. Tekrarlayan data tutmaniza gerek yok.
• Food tablosundaki person_numb var char olmasian gerek yok. smallint olarak tutabilirsiniz.
• Tarih varchar olmamali. Ayrica Laravel kullaniyorsaniz tarih ile ilgili ekstra field olusturmak cok gerekli olmuyor. Default olarak gelen created_at ve updated_at fieldlari is goruyor.
• Malzemeler tablosu cok icime sinmedi birim ve nekadar alanlari o tabloda olmamali bence. Mesala malzeme pirinc olabilir ama bu birim olarak bir kasik da olabilir 1 kilo da olabilir, bu yuzden malzemeler tablosunda bu datalara gerek yok gibi.

• Turkce isimlendirmeler kullanmayin ve isimlendirmeleri snake_case olarak yapin -> Dediğiniz gibi düzenliyeceğim.
• Gereksiz on ekler kullanmaktan kacinin. Orngenin food_name ismi gerksiz, name tek basina yeterli cunku tablo adi zaten food. -> Dediğiniz gibi düzenliyeceğim.
• tarifAdinlar tablosunda niye tarif_adi diye field var anlayamadim. Zaten tarif_id var. Tarif adi iliskiden cekilebilir. Tekrarlayan data tutmaniza gerek yok. -> O kısım "adim" olarak değiştireceğim. Uygun mu acaba. ? Yanlış yazmışım. Tarife ait adımlar olacak.
• Food tablosundaki person_numb var char olmasian gerek yok. smallint olarak tutabilirsiniz. -> Dediğiniz gibi düzenliyeceğim.
• Tarih varchar olmamali. Ayrica Laravel kullaniyorsaniz tarih ile ilgili ekstra field olusturmak cok gerekli olmuyor. Default olarak gelen created_at ve updated_at fieldlari is goruyor. -> Dediğiniz gibi düzenliyeceğim.
• Malzemeler tablosu cok icime sinmedi birim ve nekadar alanlari o tabloda olmamali bence. Mesala malzeme pirinc olabilir ama bu birim olarak bir kasik da olabilir 1 kilo da olabilir, bu yuzden malzemeler tablosunda bu datalara gerek yok gibi. ->malzemeler tablosunu kaldırıp sadece tarifMalzemeler tablosu üzerinden yapabilirim.
• Kullanıcıya ait takip ve takipçi sayılarını tutmak için follower_user adında tablom var hocam. Yapısı uygun mu. Verdiğiniz bilgiler için ayrı ayrı teşekkür ederim.Saygılar.

Bende bir kaç ek yapayım:

• Çok fazla tablo var. tarifResimleri tablosunu ayrıca ilişkilendirmeye gerek yok. İki tabloyu birleştirebilirsiniz.
• Malzemeleri adımlar ile ilişkilendirmeniz daha doğru olacaktır. Bu şekilde "hangi adımda hangi malzeme kullanılıyor?" ve "Bu tarif için hangi malzemeler gerekli?" sorularına aynı anda cevap verebilirsiniz
• Görselden yorum ve adımların nasıl bağlanacağını tam kavrayamadım. Ancak eğer tarif > 1.adım ( + adıma ait yorumlar) > 2. adım (+adıma ait yorumlar) şeklinde ise olabilir. değilse neden 2 tablo var?
• JWT token kullanacaksanız access_token tablosuna ihtiyacınız yok. Tymon/jwt-auth paketini kullanabilirsiniz.
• Kullanıcı bilgilerini 2. bir tabloda tutmanız gerekmiyor. Bir kalemde bir kullanıcıya ait tüm verileri çekebilmeniz daha verimli olacaktır
• Ufak bir fikir, her adımın ne kadar sürdüğünü not edebileceğiniz bir "TIME" sütunu fena olmaz.

- Resimler tablosunu birleştirdiğimde aynı sonuç çıkıyor. Çok iyi oldu.
- Güncelleme listesine bu kısmı da ekleyebilirim.
- tarifadimlar tablosu yukarıdaki food tablosuyla ilişkili.
- Bir kursta db ile yapıyordu hocam. Bunun yerine sanctum da kullanabilirim. O da tablo tutuyor. Jwt ile birka. örnek yaptım ama beceremedim. Ben de bu şekilde ile çözüm buldum.Mantığı yanlış mı sizce. ? Mobil tarafında kontrollerini yapacağım.
- Kullanıcı verileri bu şekilde çekildiğinde çok alan olmaz mı. ? Bu şekilde daha sağlıklı olur diye ayırmıştım.
- Adım başına süre yerine yemek başına süre düşündüm.

Cevaplarınız için teşekkür ederim hocam.

- Kullanıcı tablosunda yüzlerce sütun olsaydı belki dediğiniz doğruydu. Ama 5-10 sütun sorun çıkartmayacaktır. Çalıştığım şirket 650.000 satırlı 40-50 sütunlu tablodan milisaniyeler içerisinde cevap alabiliyorsa, sizin 10 sütunlu tablonuz hayli hayli çalışır. Optimizasyon ile alakalı birşey
- JWT konusunda da, https://jwt-auth.readthedocs.io/en/d...-installation/ buradaki adımları harfi harfine uygularsan kullanabilirsin.
- Relations ve collection özellikleri ile süreyi kolayca toplayabilirsin. Uzun vade düşünüyorsanız eklemek daha faydalı olacaktır kanaatindeyim

Cevaplarınız için teşekkür ederim hocam. Laravelde yeniyim. Hayırlısı ile başlayadık. iyi günler dilerim. JWT birkez daha bir bakayım.