Hannibal_King bunu yazdı SORU 2: PostgreSQL e biraz baktığımda NoSQL için epey destek verdiğini grdü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? 0x0480 takilin madem

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 szcükler var. Ve profil sayfaları da bu anahtar szcü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 grdü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 Mühendis kahveyi projeye dnüştüren bir insan evladıdır.

bu join için bitane view yaratsan daha iyi olmaz mı? 29.99cm, titanyum kaplamalı, çift damarlı, su ve yağ soğutmalı.

@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 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.

SORU 2: PostgreSQL e biraz baktığımda NoSQL için epey destek verdiğini grdü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.

@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 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. herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

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.

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 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. herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

@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.