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

Veritabanınızı Yapılandırma

Bu kılavuz, veri mimarisindeki bazı temel kavramları ve Firebase Gerçek Zamanlı Veritabanınızdaki JSON verilerini yapılandırmaya yönelik en iyi uygulamaları kapsar.

Düzgün yapılandırılmış bir veritabanı oluşturmak için biraz önceden düşünülmesi gerekir. En önemlisi, bu işlemi mümkün olduğunca kolaylaştırmak için verilerin nasıl kaydedileceğini ve daha sonra nasıl alınacağını planlamanız gerekir.

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

Tüm Firebase Gerçek Zamanlı Veritabanı verileri JSON nesneleri olarak saklanı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, 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ğlayabilir veya push() yöntemini kullanarak sizin için sağlanabilir.

Kendi anahtarlarınızı oluşturursanız, bunların UTF-8 kodlu olması gerekir, en fazla 768 bayt olabilir ve içeremez . , $ , # , [ , ] , / 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 profili ve kişi listesini saklamasına izin veren bir sohbet uygulamasını düşünün. Tipik bir kullanıcı profili /users/$uid gibi bir yolda bulunur. alovelace kullanıcısı alovelace benzer bir veritabanı girişine sahip olabilir:

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

Veritabanı bir JSON ağacı kullanmasına rağmen, 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 olan verileri iç içe yerleştirmeye izin verdiğinden, bunun varsayılan yapı olması gerektiğini düşünebilirsiniz. Ancak, veritabanınızdaki bir konuma veri getirdiğinizde, tüm alt düğümlerini de alırsınız. Ayrıca, birisine veritabanınızdaki bir düğümden okuma veya yazma erişimi verdiğinizde, bu düğüm altındaki tüm verilere erişmesine de izin verirsiniz. 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 çoklu 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 tasarımla, veriler arasında yineleme yapmak sorunlu hale gelir. Örneğin, sohbet görüşmelerinin 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 denormalizasyon olarak da adlandırılan ayrı yollara ayrılırsa, 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 görüşme başına yalnızca birkaç bayt indirerek, bir kullanıcı arayüzündeki odaları listelemek veya görüntülemek için meta verileri hızla getirerek oda listesini tekrarlamak mümkün. Mesajlar ayrı ayrı getirilebilir ve geldiklerinde görüntülenebilir ve kullanıcı arayüzünün hızlı yanıt vermesini sağlar.

Ölçeklenen veriler oluşturma

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

Bazen, bu ilişki daha dinamiktir veya bu verilerin normalleştirilmesi gerekebilir. Çoğu zaman Verileri Al bölümünde açıklandığı gibi, verilerin bir alt kümesini almak için bir sorgu kullanarak verileri denormalize edebilirsiniz.

Ancak bu bile yetersiz olabilir. Ö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 içerir. Bir kullanıcının hangi gruplara ait olduğuna karar verme zamanı geldiğinde işler karmaşıklaşır.

Gerekli olan, bir kullanıcının ait olduğu grupları listelemenin ve yalnızca bu gruplara ilişkin verileri almanın zarif bir yoludur. Bir grup indeks 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
      }
    },
    ...
  }
}

Bunun hem Ada'nın kaydı hem de grup altında ilişkiyi saklayarak bazı verileri çoğalttığını fark edebilirsiniz. Şimdi alovelace bir grup altında endekslenir ve techpioneers Ada'nın profilinde listelenir. Bu yüzden 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ıların veya grupların listesi milyonlara ölçeklendiğinde 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ızı sağlar.

Bu yaklaşım, kimlikleri anahtarlar olarak listeleyerek ve değeri true olarak ayarlayarak verileri tersine çevirerek, bir anahtarı kontrol etmeyi /users/$uid/groups/$group_id kadar basit ve null olup olmadığını kontrol /users/$uid/groups/$group_id . Dizin, verileri sorgulamak veya taramaktan daha hızlı ve çok daha etkilidir.

Sonraki adımlar