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

Veritabanınızı Yapılandırma

Başlamadan önce

Realtime Database özelliğini kullanabilmek için:

Unity projenizi kaydedin ve Firebase'i kullanacak şekilde yapılandırın.
- Unity projeniz zaten Firebase kullanıyorsa kaydedilip yapılandırıldı.
- Unity projeniz yoksa örnek uygulama indirebilirsiniz.
Firebase Unity SDK'sını (özellikle FirebaseDatabase.unitypackage) şuraya ekleyin: derleyip toparlarsınız.

Firebase'i Unity projenize eklemenin hem Firebase konsolunda ve açık Unity projenizde (örneğin, Firebase yapılandırma dosyalarını konsoldan indirip bu dosyalara bunları Unity projenize ekleyin).

Verileri yapılandırın

Bu kılavuzda, veri mimarisi alanındaki temel kavramlardan bazıları ve en iyi Firebase Realtime Database içinde JSON verilerini yapılandırma ile ilgili daha fazla bilgi edinin.

Düzgün yapılandırılmış bir veritabanı oluşturmak için çok fazla kafa yorulması 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.

Verilerin yapılandırması: JSON ağacı

Tüm Firebase Realtime Database verileri JSON nesnesi olarak depolanır. Veritabanını bulutta barındırılan bir JSON ağacı olarak düşünebilirsiniz. SQL veritabanlarının aksine, tablo veya kayıt yoktur. JSON ağacına veri eklediğinizde, bu veriler ilişkili anahtara sahip mevcut JSON yapısına sahiptir. Kendi anahtarlarınızı sağlayabilirsiniz. kullanıcı kimlikleri veya anlamsal adlar gibidir ya da Push() yöntemi.

Kendi anahtarlarınızı oluşturursanız anahtarlarınız UTF-8 kodlamalı olmalı, en fazla 768 bayt uzunluğunda olmalı ve ., $, #, [, ], / veya ASCII kontrol karakterleri 0-31 ya da 127 içermemelidir. Değerlerde de ASCII kontrol karakterleri kullanamazsınız.

Örneğin, kullanıcıların temel bir profil ve kişi listesi depolamalarına olanak tanıyan bir sohbet uygulaması düşünün. Tipik bir kullanıcı profili bir yolda bulunur: /users/$uid alovelace adlı kullanıcının aşağıdaki gibi görünür:

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

Veritabanı bir JSON ağacı kullansa da, veritabanında depolanan veriler Kullanılabilir JSON türlerine karşılık gelen belirli yerel türlerle gösterilir kod yazmanızı ister.

Veri yapısıyla ilgili en iyi uygulamalar

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

Firebase Realtime Database, verilerin 32 seviyeye kadar derine yerleştirilmesine izin verdiğinden bunun varsayılan yapı olması gerektiği düşünülebilir. Ancak veritabanınızdaki bir konumdaki verileri getirdiğinizde, bu konumun tüm alt düğümlerini de alırsınız. Ayrıca, veritabanınızdaki bir düğümde bir kullanıcıya okuma veya yazma izni verdiğinizde, söz konusu düğümün altındaki tüm verilere de erişim izni vermiş olursunuz. Bu nedenle, uygulamada en iyi uygulama, veri yapınızı olabildiğince düz yardımcı olabilirsiniz.

İç içe yerleştirilmiş verilerin neden kötü olduğunu gösteren bir örnek olarak aşağıdaki çoklu iç içe yerleştirilmiş yapıyı inceleyin:

{
  // 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 yerleştirilmiş tasarımda, veriler arasında iterasyon yapmak sorunlu hale gelir. Örneğin, Örneğin, sohbet görüşmelerinin başlıklarını listelemek için tüm chats gerekir ağaçları (tüm üyeler ve iletiler dahil olmak üzere) istemciye indirecektir.

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

Veriler, denormalizasyon olarak da bilinen ayrı yollara bölünürse gerektiğinde ayrı görüşmelerde verimli bir şekilde indirilebilir. Aşağıdaki 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 oda listesinde gezinebilir, odaları kullanıcı arayüzünde listelemek veya görüntülemek için meta verileri hızlıca alabilirsiniz. İletiler ayrı ayrı alınıp geldikçe görüntülenebilir. bu da, kullanıcı arayüzünün duyarlı ve hızlı kalmasına olanak tanıyor.

Ölçeklenen veriler oluşturun

Uygulama oluştururken genellikle bir listenin alt kümesini indirmek daha iyidir. Bu durum özellikle liste binlerce kayıt içeriyorsa yaygındır. Bu ilişki statik ve tek yönlü olduğunda, tablodaki alt nesneleri de içerir.

Bazen bu ilişki daha dinamik olabilir veya bu verileri denormalize edebilirsiniz. Birçok kez, bir sorgu kullanarak verileri normalleştirme aşağıdaki örnekte açıklandığı gibi, verilerin bir alt kümesini almak için Verileri Al.

Ancak bu bile yeterli olmayabilir. Örneğin, kullanıcılar ile gruplar arasındaki iki yönlü ilişkiyi düşünün. Kullanıcılar bir gruba ait olabilir ve gruplar bir kullanıcı listesi. Bir kullanıcının ait olduğu gruplara karar verirken işler karmaşıklaşır.

Kullanıcının ait olduğu grupları listelemek ve yalnızca bu gruplarla ilgili verileri almak için şık bir yönteme ihtiyaç vardır. Grupların 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
      }
    },
    ...
  }
}

Bunun, ilişki saklayarak bazı verilerin yinelendiğini fark edebilirsiniz altında ve grup altında bulabilirsiniz. Artık alovelace bir grup altında dizine eklenmiş, techpioneers ise Ada'nın profilinde listelenmektedir. Ada'yı silmek için: iki yerde güncellenmesi gerekir.

Bu, iki yönlü ilişkilerde gerekli bir gereksizliktir. Kullanıcı veya grup listesi milyonlara ulaştığında ya da Realtime Database güvenlik kuralları bazı kayıtlara erişimi engellediğinde bile Ada'nın üyeliklerini hızlı ve etkili bir şekilde getirmenize olanak tanır.

Bu yaklaşım, kimlikleri anahtar olarak listeleyip değeri True olarak ayarlayın, bir anahtarı kontrol etmek kadar kolay /users/$uid/groups/$group_id ve null olup olmadığı kontrol ediliyor. Dizin daha hızlı ve verileri sorgulamak veya taramaktan çok daha verimlidir.