Sahte Ağaçlar: Daha Basit Bir UI İçin Girinti Kullanmak

Sahte Ağaçlar: girinti kullanarak daha basit bir UI

• UI'da ağaç biçimli bir liste istendiğinde, ebeveyn-çocuk ilişkisini uygulamak çok iş ve karmaşık veri yapıları gerektirir.
• İlişkisel veritabanlarında, ağaç yapısındaki verileri elde etmek için özyinelemeli CTE'ler (Common Table Expressions) kullanılabilir.

Verinin gerçekten ağaç yapısında olması gerekiyor mu?

• Öğelerin gerçekten ebeveyn-çocuk ilişkisine sahip olması mı gerektiği, yoksa sadece öyle görünmesinin mi yeterli olduğu düşünülmelidir.
• Gerçek bir ilişki gerekmiyorsa, ağacı basitçe saklamak için id, sort, indent, name alanları kullanılabilir.
• Bu yaklaşım ekranda görünen şeyi doğrudan temsil ettiğinden, listeyi render eden ve düzenleyen bir arayüz oluşturmak çok daha kolaydır.

"Namespacing" kullanan başka bir örnek

• HissScript'te öğe adında nokta (.) varsa, ilk bölüm kesilip atılır ve öğe girintilenir; böylece namespacing özelliği uygulanır.
• Oyun editörü ve oynatıcı için namespacing önemlidir, ama gerçekte bu yalnızca basit bir addır.
• İnsanların çoğu zaman gerçek ağaç yapısından ziyade yalnızca onun görünümüne ihtiyacı vardır.

Bonus ağaç-liste

• Gerçek bir ağacı taklit ederek yol ve bilgi düz bir listede saklanabilir; ardından derinlik öncelikli veya genişlik öncelikli dolaşım için yol sıralanabilir.
• Düz listeler genelde üzerinde çalışması daha kolay ve bilgisayarlar için daha uygundur.

Fiziksel benzetme

• Kişisel bir albümü düzenlerken, bir insan için grupların nasıl çalıştığı açıktır; ancak gerçekte yerde bu ilişkileri zorunlu kılan fiziksel bir mekanizma yoktur.

Dikkat: Her duruma uyan tek bir çözüm yoktur

• Teknikler belirli senaryolara göre uygulanmalıdır; gerçek ağaç yapısı gerekiyorsa ağaç kullanılmalıdır.
• Öğeler arasındaki gerçek ilişkileri bilmek gerekiyorsa, girinti ya da bir dizge içindeki sembolleri saymaya dayanan hilelere başvurulmamalıdır.

GN⁺ görüşü:

• Bu yazı, yazılım geliştirmede karmaşık ağaç yapıları yerine görsel olarak basit girinti kullanarak kullanıcı arayüzünü sadeleştirmenin bir yolunu sunuyor.
• Geliştiricilere veri yapısını basitleştirerek geliştirme süresinden tasarruf etme ve bakımı kolaylaştırma açısından etkili bir strateji sağlıyor.
• Ağaç yapısının her zaman gerekli olmadığını ve bazen kullanıcıya tanıdık gelen görsel yapının yeterli olduğunu vurgulayarak, geliştiricilere kullanıcı deneyimini iyileştirmek için yeni bir bakış açısı sunuyor.

[GN⁺]

Hacker News görüşü

• İlk yaklaşım olan 'adjacency list', "açıkça tek yöntem" olarak görülen yaklaşım.

• İkinci yaklaşım "çok daha basit bir yöntem"; daha önce görülmemiş bir yaklaşım ve bariz kusurları var, ancak bazı durumlarda yeterince açık.

• Üçüncü yaklaşım olan 'namespacing', 'materialized path' olarak adlandırılır.

• Ağaçları temsil etmenin bir başka yolu da 'nested sets'; bu, ilişkisel veritabanlarının ciddi biçimde ele alındığı dönemlerde iyi bilinen bir yaklaşımdı.

• Postgres, ağaç yapılarını doğal biçimde ele alabilmek için 'ltree' adlı bir veri tipi ve arama operatörleri sunar. Örneğin, 'ltree' kullanarak bir tablo oluşturup veri ekledikten sonra basit sorgularla ağaç yapısı üzerinde arama yapılabilir.

• Yapı içindeki değerler çoğu zaman gösterilen ağaç değil, verinin hiyerarşisidir. Muhtemelen veriyi dolaşmak, ilişkileri göstermek ya da yeniden sıralamak gibi işler yapmak isteyeceksiniz. Veritabanındaki veri yapısının içine görsel bilgi kaydetmek kısa vadeli bir bakış açısı gibi görünebilir.

• Ağaç biçimindeki verilerle çalışan bir şirket kurma deneyimi var. Ağaç yapısını O(n) zamanda girintili bir listeye dönüştürmek mümkün. Bu, mülakat sorularından biriydi ve özyinelemeli sorgular olmadan da ağacın bir kısmını hızlıca getirip render edebilmenin SQL veritabanlarında çeşitli yolları var.

• İlişkisel bir veritabanında ağaç yapılı veriyi SQL sorgularıyla getirmenin bir yolu, özyinelemeli CTE'ler (Common Table Expressions) yazmaktır. CTE'ler aslında eğlencelidir ve bir kez alışınca korkulacak bir şey kalmaz.

• İnsanların çoğu zaman gerçekten bir ağaç değil, sadece ağacın görünümünü istediğini deneyimle öğrenirsiniz. HN ve Reddit bu açıdan farklıdır. HN'de çocuk yorumlar, ebeveyn yorumun bir sonraki kardeşi olur; girinti de ebeveynin girintisine bir seviye eklenerek ağaç görünümü taklit edilir. Reddit'te ise çocuk yorumlar gerçekten ebeveyn yorumun içinde iç içe yer alır.

• Yazının temel fikri, probleme uygun yapıyı kullanmaktır. Ancak anlatının ilerleyişinde kusurlar var. Veritabanından ağaçları almak için CTE gerekli değildir; düz bir liste alıp ağacı yerelde kurabilirsiniz. Ayrıca yeterince büyük ağaçlarda dalları taşımak ya da derinliği değiştirmek istediğinizde doğrusal maliyet ortaya çıkabilir.

• Taksonomi veya başka hiyerarşileri açıklarken, yerel dosya sistemini kullanan basit ve hızlı bir yöntem öğrenildi. 'mkdir' ve 'tree' komutları kullanılıp e-posta, Slack, pastebin vb. yerlere yapıştırılarak paylaşılır.

• Yalnızca kaydetme/yükleme istiyorsanız, veriyi istediğiniz biçimde serileştirip (ör. JSON) bir string olarak saklamak daha basit bir çözüm olabilir. Nokta gösterimi kullanmak, VsCode eklentisi Dendron'un ad hiyerarşilerini ele alma biçimine benziyor.

• Birkaç yıl önce OpenGL hakkında benzer bir farkındalık yaşandı: Hiyerarşik 3D nesnelerden oluşan bir dünyayı çizmek gerekmez; yalnızca sıralanmış bir üçgen listesi çizmek yeterlidir. Bu da birçok optimizasyonu oldukça kolaylaştırır.