Forum
Aktif konular
Üyeler
Kurallar
Arama
Postgresql Kullanan Müridlere Soru Postgresql Kullanan Müridlere Soru
-
Bulutdoktor isminde bir startup projem var. Daha önce konusunu açmıştım zaten. Şimdi profil sayfaları için arama yaparken şu şekilde yapıyorum. Sistemde tanımlı anahtar sözcükler var. Ve profil sayfaları da bu anahtar sözcüklerden 8-10 tanesine sahip. Bu nedenle 2 tane tablom var. 1.si profile_pages 2.si profile_pages_keywords. Kullanıcı anahtar kelimeyi seçiyor. Seçtiği anahtar kelimenin id sine bakıyorum. Ve bu iki tabloyu join yaparak sonuçları getiriyorum. Klasik normalizasyon örneği aslında.
Şimdi arama işlemine yeni bir kriter daha ekleyeceğim. Anlaşmalı sigortalar kısmı.
Bu durumda karşımda 2 seçenek var;
A) Yeni bir tablo oluştururum. profile_page_insurances isminde burada da profil sayfaları ve anlaşmalı oldukları sigorta firmaları için
normalizasyon yapmış olurum. Ancak bu durumda artık search işlemi için 3 tane tabloyu join yapmam gerekecek.
B) Yeni tablo oluşturmam. Profile_pages tablosunda json veya jsonb tipinde bir alan acarım. Bu alana her bir profil sayfası için anlaşmalı sigortaları yazarım.
Sonra birde bu postgresql in özel indexlerinden atarım bu alana. Ve hala arama işlemlerim için 2 tane tablo arasında join yapmış olurum. Ancak bu durumda profile_pages tabloma veri tipi json olan bir alan gelmiş olur.
Sizce hangisini seçmeliyim? Hangisi daha efektif ve performanslı olur?
SORU 2:
PostgreSQL e biraz baktığımda NoSQL için epey destek verdiğini gördüm. Mesela hstore isminde bir veri tipi var. Anahtar-değer şeklinde saklama yapıyor. Ancak hstore için bazı modülleri aktif etmek gerekiyor sanırım. Benim veritabanı da Aws üzerinde ve sanırım bu tarz modifiye işlemlerine izin vermiyor.
Soru 3:
Bildiğiniz PostgreSQL grupları var mı? Telegram, slack discord vs.
-
Çok detaylı okuyamadım ama anladığım full-text search yapmak istiyorsun. Neden elasticsearch kullanmıyorsun
-
Hannibal_King bunu yazdı
SORU 2:
PostgreSQL e biraz baktığımda NoSQL için epey destek verdiğini gördüm. Mesela hstore isminde bir veri tipi var. Anahtar-değer şeklinde saklama yapıyor. Ancak hstore için bazı modülleri aktif etmek gerekiyor sanırım. Benim veritabanı da Aws üzerinde ve sanırım bu tarz modifiye işlemlerine izin vermiyor.
https://kb.objectrocket.com/postgresql/how-to-query-a-postgres-jsonb-column-1433
jsonb adında bir veri tipi var.
-
Benzer bir yapim olan yer mevcut 3 tane tabloyu joinliyorum. 4. yü join e dahil etmemek için normal arayuzlerde 4. tablomu kullanıyorum. searc de kullanmalik bir tablomda text alan tutuyorum , ile ayrilmiş valuelari de orada tutuyorum. search de like ile orayi searche e dahil ediyorum.
-
cemnet bunu yazdıHannibal_King bunu yazdı
SORU 2:
PostgreSQL e biraz baktığımda NoSQL için epey destek verdiğini gördüm. Mesela hstore isminde bir veri tipi var. Anahtar-değer şeklinde saklama yapıyor. Ancak hstore için bazı modülleri aktif etmek gerekiyor sanırım. Benim veritabanı da Aws üzerinde ve sanırım bu tarz modifiye işlemlerine izin vermiyor.
https://kb.objectrocket.com/postgresql/how-to-query-a-postgres-jsonb-column-1433
jsonb adında bir veri tipi var.
Mysql'in de json column'u var direkt. Neden psql o halde?
-
@sandman fulltext search değil hocam konu. 3 tabloyu join yapmak mı yoksa 2 tablo join + jsonb kullanmak mı? Konu bu.
@cemnet zaten jsonb kullanıcam muhtemelen
@dalyKadir 2 join + jsonb kullanacağım sanırım hocam 3 adet join yapmak yerine. Join sayısı arttıkca performansı olumsuz etkiler mi diye şüphelerim var.
@end bu projede postgresql tercih ettim. Öğrendikten sonra MySQL den daha yetenekli sanırım.
-
bu join için bitane view yaratsan daha iyi olmaz mı ?
-
Hocam tasarımı değiştirmeye ne kadar uygunsun bilmiyorum ancak bugün anlaşmalı firmalar, yarın anlaşmalı bilmemneler falan fıstık derken senin profil_page ine süreç ilerledikçe farklı yeni özellikler gelecektir. Eğer yol yakınsa şöyle bir tasarımı implemente edersen hertürlü filtreleme derdinden kurtulabilirsin diye düşünüyorum.
Filter_Group adında bir tablo oluşturup burada, Keywords, Insurences gibi filtrelemeler için Group oluşturuyorsun.
Filter_Group_Item adındaki tabloda bu group'lara item Item'ları tutuyorsun (Keywordler, Keyword grubuna bağlı. Insurence Itemler'ler filan fıstık burada duracak.)
Profile_Filter_Group_Items tablosu da filter group item ile profil'leri ilişkilendirdiğin tablo olacak.
Bu şekilde bir yapı ile sadece veritabanında oynamalar yaparak bahsettiğin tüm bu join işlerinden kurtulabilirsin ve derli toplu ama esnek bir yapıya sahip olabilirsin.
-
@yolbulucu View den ziyade Terror hocamın dediği efso mantıklı. View ler performans konusunda nasıl bir etki yapıyor ona bakmam lazım birde. Kullanmayınca unutuluyor Sql bilgileri.
@TeRRoR hocam efso mantıklı dediğin. Eğer bir tabloya ilişkin normalizasyon yapmamızı gerektirecek pek çok tablo varsa gerçekten şahane bir çözüm gibi duruyor. Kağıt kalem aldım yazdım önce. Benim senaryoda şöyle bir durum var. Keywords lar konusunda priority mevzusu var. İki profil sayfası aynı anahtar kelimeye sahip olsalar bile listelerken priority(öncelik) değerine bakarak listeliyorum. O nedenle önce şunu düşündüm; profile_pages, profile_page_keywords ve senin önerdiğin profile_filter_group_items tablosu olsun. Ben bu 3 tabloyu joinlerim her zaman. Yeni gelen kriterleri de profile_filter_group_items tablosu üzerinden eklerim dedim. Yani keywords muhabbetini filterın dısında tutacaktım ama sonra şöyle yaptım; http://prntscr.com/vqx9g1 bu durumda 2 tane alt sorgu atarak sadece 1 adet joinle işi kapatmış oldum.
Ancak tabi keywords tablosunu bu senin filter muhabbetine dahil etmeseydim 3 farklı tablo toplamda 2 join olacaktı. Şu anki haliyle 2 farklı tablo ve 2 subquery olmuş oldu. Aslında alternatif olarak 2 farklı şekilde de tutarım kodları.Birde senin önerdiğin filter muhabbetinde 4-5 farklı grup olabilir. Bu durumda kullanıcı yalnızca 3 farklı kriter ile search yapabilir. Group by ile gruplamak gerekiyor. Attığım linkte o şekilde yaptım.
-
Hannibal_King bunu yazdı
@yolbulucu View den ziyade Terror hocamın dediği efso mantıklı. View ler performans konusunda nasıl bir etki yapıyor ona bakmam lazım birde. Kullanmayınca unutuluyor Sql bilgileri.
@TeRRoR hocam efso mantıklı dediğin. Eğer bir tabloya ilişkin normalizasyon yapmamızı gerektirecek pek çok tablo varsa gerçekten şahane bir çözüm gibi duruyor. Kağıt kalem aldım yazdım önce. Benim senaryoda şöyle bir durum var. Keywords lar konusunda priority mevzusu var. İki profil sayfası aynı anahtar kelimeye sahip olsalar bile listelerken priority(öncelik) değerine bakarak listeliyorum. O nedenle önce şunu düşündüm; profile_pages, profile_page_keywords ve senin önerdiğin profile_filter_group_items tablosu olsun. Ben bu 3 tabloyu joinlerim her zaman. Yeni gelen kriterleri de profile_filter_group_items tablosu üzerinden eklerim dedim. Yani keywords muhabbetini filterın dısında tutacaktım ama sonra şöyle yaptım; http://prntscr.com/vqx9g1 bu durumda 2 tane alt sorgu atarak sadece 1 adet joinle işi kapatmış oldum.
Ancak tabi keywords tablosunu bu senin filter muhabbetine dahil etmeseydim 3 farklı tablo toplamda 2 join olacaktı. Şu anki haliyle 2 farklı tablo ve 2 subquery olmuş oldu. Aslında alternatif olarak 2 farklı şekilde de tutarım kodları.Birde senin önerdiğin filter muhabbetinde 4-5 farklı grup olabilir. Bu durumda kullanıcı yalnızca 3 farklı kriter ile search yapabilir. Group by ile gruplamak gerekiyor. Attığım linkte o şekilde yaptım.
tam anlamayamadım hocam yazdıklarım yanlış olabilir kusura bakma. filtreleme için where exist ile filtrenen group_item_if'lere sahip sonuçları getirebilirsin. priority konusunu group_item'a ekleyip oradan kullanabilirsin diye düşünüyorum. ben e-ticaret sitesinde şu şekilde kullanıyorum (https://prnt.sc/vrdlj6) belki ek fikir verebilir.
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla