Logseq Queries: Query Builder, simple query ve advanced query nasıl ayrılıyor?

Bir query'nin işi "karmaşık kod yazmak" değil.

**Bir node kümesini koşula göre bulmak.**

Önce bu cümleyi netleştir.

Üç giriş yolu

Resmî DB belgesi query oluşturmak için üç yöntem sayıyor.

Query Builder

Slash menüsünden Query komutu.

Görsel builder ile koşul kurarsın.

Yeni başlayan için en güvenli başlangıç.

Simple query

Bir block içinde simple query yazıp Query komutuyla çalıştırırsın.

Kısa ve tekrar kullanılabilir filtrelerde kullanışlı.

Advanced query

Advanced Query komutu ile daha teknik sorgu oluşturulur.

Bu yol daha karmaşık veri ilişkileri ve özel ihtiyaçlar için.

Hepsi #Query

DB sürümünde query'ler #Query tag'i taşır.

Bu yüzden Query page üzerinde query'leri table halinde yönetebilirsin.

Bu önemli bir davranış değişimi:

Sorgu artık yalnız bir metin parçası değil; sistem içinde yönetilebilen bir node türü.

Query ile View'i ayır

Resmî belge query sonuçlarının [[view]] içinde gösterildiğini söylüyor.

Bu iki şeyi ayır:

Query:

**hangi node'lar?**

View:

**bu node'ları nasıl göstereyim?**

Örneğin query:

• Status = Todo
• Priority = High
• Deadline bu hafta

olan task'ları bulur.

View tarafı aynı sonucu:

• Table,
• List

olarak gösterebilir.

Önce soruyu Türkçe yaz

Query yazmadan önce bir cümle kur:

"Bu hafta deadline'ı olan, tamamlanmamış yüksek öncelikli görevleri göster."

Sonra parçala:

• type/tag → Task
• status → Done değil
• priority → High
• deadline → bu hafta

Bu ayrım query'nin veri modeline dayanmasını sağlar.

Typed properties query'yi neden iyileştirir?

Dosya grafiğinde bazı metadata metin olarak tutuluyordu.

DB sürümünde:

• Number sayı,
• Date tarih,
• Node ilişki

olarak saklanır.

Bu, karşılaştırma ve sıralama davranışını daha güvenilir hale getirir.

Örneğin 2, 10 ve 100 değerleri metin gibi değil sayı gibi sıralanabilir.

Date filtreleri de gerçek tarih davranışı kullanır.

Advanced query ne zaman gerekir?

Şu durumlarda:

• birden fazla ilişkiyi dolaşmak,
• status history gibi daha özel veriyi sorgulamak,
• Query Builder'ın sunmadığı dönüşüm/hesap yapmak,
• belirli Datascript davranışı kullanmak.

Ama Query Builder ile çözülen soruyu advanced query'ye taşımak bakım maliyeti yaratır.

Query tasarımında üç hata

1. Metadata yokken sorgu yazmak

Veri tutarlı değilse query karmaşıklaşır.

Önce property/tag modelini düzelt.

2. Query'yi dashboard uğruna çoğaltmak

Her sayfaya on query eklemek bilgi sistemini izleme paneline çevirebilir.

Gerçek karar üreten sorguları tut.

3. Görünüm ile filtreyi karıştırmak

Aynı node kümesini başka biçimde görmek istiyorsan yeni query yerine yeni view yeterli olabilir.

Başlangıç seti

İlk hafta üç query yeter:

1. açık tasks
2. bu hafta deadline'ı olan tasks
3. son eklenen belirli tag'li node'lar

Gerçek ihtiyaç oluşmadan 20 dashboard kurma.

Karar

Logseq DB'de query'nin gücü sorgu dilinin karmaşıklığında değil.

**Typed properties + tags + views aynı veri modeli üzerinde çalışıyor.**

Önce veriyi tutarlı kurarsan query sade kalır.