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

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, biraz öngörü gerektirir. En önemlisi, bu süreci olabildiğince kolaylaştırmak için verilerin nasıl kaydedileceğini ve 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, mevcut JSON yapısında ilişkili bir anahtarla bir düğüm haline gelir. Böyle bir kullanıcı kimlikleri veya anlamsal adları gibi, kendi anahtarlarını sağlayabilir, ya da kullandığınız için sağlanabilir POST isteği .

Kendi anahtarlarını oluşturmak, bunlar UTF-8 kodlu, 768 bayt uzunluğunda olabilir olmalı ve içeremez . , $ , # , [ , ] , / , Ya, değerler kendilerini ASCII kontrol karakterleri kullanamazsınız 0-31 veya 127. veya ASCII kontrol karakterleri.

Örneğin, kullanıcıların temel bir profil ve kişi listesi saklamasına izin veren bir sohbet uygulamasını düşünün. Tipik bir kullanıcı profili, bir yolda gibi bulunduğu /users/$uid . 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ı kullanıyor olsa da, veritabanında depolanan veriler, daha sürdürülebilir kod yazmanıza yardımcı olmak için mevcut JSON türlerine karşılık gelen belirli yerel türler olarak temsil edilebilir.

Veri yapısı için en iyi uygulamalar

Verileri yuvalamaktan kaçının

Firebase Gerçek Zamanlı Veritabanı, verileri 32 seviyeye kadar iç içe yerleştirmeye izin verdiğinden, bunun varsayılan yapı olması gerektiğini düşünebilirsiniz. Ancak, veritabanınızdaki bir konumdan veri getirdiğinizde, onun tüm alt düğümlerini de alırsınız. Ayrıca, birine veritabanınızdaki bir düğümde okuma veya yazma erişimi verdiğinizde, o düğümün altındaki tüm verilere de erişim izni vermiş olursunuz. Bu nedenle, pratikte veri yapınızı olabildiğince düz tutmak en iyisidir.

İç içe geçmiş verilerin neden kötü olduğuna dair bir örnek olarak, aşağıdaki çoklu iç içe 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, sohbetlerini başlıklarını listeleyen tüm gerektiren chats tüm üyeler ve mesajlar, müşteriye indirilecek dahil ağacı,.

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

Bunun yerine veriler, denormalizasyon olarak da adlandırılan ayrı yollara bölünürse, gerektiğinde ayrı çağrılarda 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, konuşma başına yalnızca birkaç bayt indirerek, odaları listelemek veya bir kullanıcı arayüzünde görüntülemek için meta verileri hızla getirerek odaların listesini yinelemek mümkün. Mesajlar ayrı olarak alınabilir ve ulaştıklarında 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

Uygulamalar oluştururken, genellikle bir listenin alt kümesini indirmek 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 öğenin altına yerleştirmeniz yeterlidir.

Bazen bu ilişki daha dinamiktir veya bu verilerin normalleştirilmesi gerekebilir. Birçok kez tartışıldığı üzere, veri alt kümesini almak için bir sorgu kullanarak veri denormalize edebilir verisini al .

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 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 veri getirmenin zarif bir yoludur. Grupların bir endeks burada bir hayli 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, ilişkiyi hem Ada'nın kaydı hem de grup altında saklayarak bazı verileri çoğalttığını fark edebilirsiniz. Şimdi alovelace bir grup altında dizine ve techpioneers Ada profili listelenir. 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ıların veya grupların listesi milyonlara ulaştığında 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 getirmenize olanak tanır.

Bu yaklaşım, anahtarları olarak kimlikleri listeleme ve true değerini ayarlayarak verilerin tersini, okuma olarak basit olarak bir anahtar kontrol yapar /users/$uid/groups/$group_id ve öyle olmadığını kontrol null . Dizin daha hızlıdır ve verileri sorgulamaktan veya taramaktan çok daha verimlidir.

Sonraki adımlar