Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

Veritabanınızı Yapılandırın

Bu kılavuz, veri mimarisindeki bazı temel kavramları ve Firebase Realtime Veritabanınızda JSON verilerini yapılandırmaya yönelik en iyi uygulamaları kapsar.

Düzgün yapılandırılmış bir veritabanı oluşturmak, biraz önsezi gerektirir. En önemlisi, bu işlemi olabildiğince kolay hale getirmek için verilerin nasıl kaydedilip daha sonra alınacağını planlamanız gerekir.

Veriler nasıl yapılandırılır: bu bir JSON ağacıdır

Tüm Firebase Realtime Database verileri JSON nesneleri olarak depolanır. Veritabanını bulutta barındırılan bir JSON ağacı olarak düşünebilirsiniz. SQL veritabanından farklı olarak, tablo veya kayıt yoktur. JSON ağacına veri eklediğinizde, bu mevcut JSON yapısında ilişkili bir anahtarla bir düğüm haline gelir. Kullanıcı kimlikleri veya anlamsal adlar gibi kendi anahtarlarınızı sağlayabilirsiniz veya bunlar push() kullanılarak size sağlanabilir.

Kendi anahtarlarınızı oluşturursanız, bunlar UTF-8 kodlu olmalıdır, maksimum 768 bayt olabilir ve içerebilirler . , $ , # , [ , ] , / veya ASCII kontrol karakterleri 0-31 veya 127. ASCII kontrol karakterlerini değerlerin kendisinde de kullanamazsınız.

Örneğin, kullanıcıların temel bir profil ve kişi listesi depolamasına izin veren bir sohbet uygulamasını düşünün. Tipik bir kullanıcı profili, /users/$uid gibi bir yolda bulunur. Kullanıcı alovelace şuna benzer bir veritabanı girişini sahip olabilir:

{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      "contacts": { "ghopper": true },
    },
    "ghopper": { ... },
    "eclarke": { ... }
  }
}

Veritabanı bir JSON ağacı kullansa da, veritabanında depolanan veriler, daha sürdürülebilir kod yazmanıza yardımcı olmak için kullanılabilir JSON türlerine karşılık gelen belirli yerel türler olarak temsil edilebilir.

Veri yapısı için en iyi uygulamalar

Verileri iç içe yerleştirmekten kaçının

Firebase Gerçek Zamanlı Veritabanı, 32 düzey derinliğe kadar verilerin iç içe yerleştirilmesine izin verdiğinden, bunun varsayılan yapı olması gerektiğini düşünmek isteyebilirsiniz. Ancak, veritabanınızdaki bir konumdan veri aldığınızda, tüm alt düğümlerini de alırsınız. Ek olarak, veritabanınızdaki bir düğümde birine okuma veya yazma erişimi verdiğinizde, o düğüm altındaki tüm verilere erişim izni vermiş olursunuz. Bu nedenle, pratikte, veri yapınızı olabildiğince düz tutmak en iyisidir.

Yuvalanmış verilerin neden kötü olduğuna dair bir örnek için, aşağıdaki çok yuvalanmış yapıyı göz önünde bulundurun:

{
  // This is a poorly nested data architecture, because iterating the children
  // of the "chats" node to get a list of conversation titles requires
  // potentially downloading hundreds of megabytes of messages
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "messages": {
        "m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." },
        "m2": { ... },
        // a very long list of messages
      }
    },
    "two": { ... }
  }
}

Bu iç içe geçmiş tasarımla, verilerde yineleme sorunlu hale gelir. Örneğin, sohbet konuşmalarının başlıklarını listelemek, tüm üyeler ve mesajlar dahil olmak üzere tüm chats ağacının istemciye indirilmesini gerektirir.

Veri yapılarını düzleştirin

Veriler bunun yerine, normalleştirme dengesi olarak da adlandırılan ayrı yollara bölünürse, gerektiğinde ayrı aramalarda verimli bir şekilde indirilebilir. Bu düzleştirilmiş yapıyı düşünün:

{
  // Chats contains only meta info about each conversation
  // stored under the chats's unique ID
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "lastMessage": "ghopper: Relay malfunction found. Cause: moth.",
      "timestamp": 1459361875666
    },
    "two": { ... },
    "three": { ... }
  },

  // Conversation members are easily accessible
  // and stored by chat conversation ID
  "members": {
    // we'll talk about indices like this below
    "one": {
      "ghopper": true,
      "alovelace": true,
      "eclarke": true
    },
    "two": { ... },
    "three": { ... }
  },

  // Messages are separate from data we may want to iterate quickly
  // but still easily paginated and queried, and organized by chat
  // conversation ID
  "messages": {
    "one": {
      "m1": {
        "name": "eclarke",
        "message": "The relay seems to be malfunctioning.",
        "timestamp": 1459361875337
      },
      "m2": { ... },
      "m3": { ... }
    },
    "two": { ... },
    "three": { ... }
  }
}

Artık, her görüşme için yalnızca birkaç bayt indirerek, bir kullanıcı arayüzünde odaları listelemek veya görüntülemek için meta verileri hızlı bir şekilde getirerek oda listesini yinelemek mümkün. Mesajlar ayrı ayrı alınabilir ve geldiklerinde görüntülenebilir, bu da kullanıcı arayüzünün duyarlı ve hızlı kalmasını sağlar.

Ölçeklenen veriler oluşturun

Uygulama oluştururken, genellikle bir listenin alt kümesini indirmek daha iyidir. Liste binlerce kayıt içeriyorsa bu özellikle yaygındır. Bu ilişki statik ve tek yönlü olduğunda, alt nesneleri üst öğenin altına kolayca yerleştirebilirsiniz.

Bazen bu ilişki daha dinamiktir veya bu veriyi normal dışı hale getirmek gerekebilir. Çoğu zaman, Verileri Alma bölümünde açıklandığı gibi, verilerin bir alt kümesini almak için bir sorgu kullanarak verileri normalleştirebilirsiniz.

Ancak bu bile yetersiz kalabilir. Örneğin, kullanıcılar ve gruplar arasında iki yönlü bir ilişki düşünün. Kullanıcılar bir gruba ait olabilir ve gruplar bir kullanıcı listesi oluşturur. Bir kullanıcının hangi gruplara ait olduğuna karar verme zamanı geldiğinde işler karmaşıklaşır.

İhtiyaç duyulan şey, bir kullanıcının ait olduğu grupları listelemenin ve yalnızca bu gruplar için verileri almanın zarif bir yoludur. Bir grup dizini burada çok yardımcı olabilir:

// An index to track Ada's memberships
{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      // Index Ada's groups in her profile
      "groups": {
         // the value here doesn't matter, just that the key exists
         "techpioneers": true,
         "womentechmakers": true
      }
    },
    ...
  },
  "groups": {
    "techpioneers": {
      "name": "Historical Tech Pioneers",
      "members": {
        "alovelace": true,
        "ghopper": true,
        "eclarke": true
      }
    },
    ...
  }
}

İlişkiyi hem Ada'nın kaydı hem de grup altında depolayarak bunun bazı verileri kopyaladığını fark edebilirsiniz. Şimdi alovelace bir grup altında indeksleniyor ve techpioneers Ada'nın profilinde listeleniyor. Yani Ada'yı gruptan silmek için iki yerde güncellenmesi gerekiyor.

Bu, iki yönlü ilişkiler için gerekli bir fazlalıktır. Kullanıcı veya grup listesi milyonları bulduğunda veya Gerçek Zamanlı Veritabanı güvenlik kuralları bazı kayıtlara erişimi engellediğinde bile Ada'nın üyeliklerini hızlı ve verimli bir şekilde almanıza olanak tanır.

Bu yaklaşım, kimlikleri anahtarlar olarak listeleyerek ve değeri doğru olarak ayarlayarak verileri tersine /users/$uid/groups/$group_id , bir anahtarı /users/$uid/groups/$group_id ve null olup olmadığını kontrol etmek kadar basit hale getirir. Dizin daha hızlıdır ve verileri sorgulamaktan veya taramaktan çok daha etkilidir.

Sonraki adımlar