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 Firebase için kayıtlı ve yapılandırılmış demektir.
Unity projeniz yoksa örnek uygulama indirebilirsiniz.
Firebase Unity SDK'sını (özellikle
FirebaseDatabase.unitypackage
) Unity projenize ekleyin.
Firebase'i Unity projenize eklemenin hem Firebase konsolundaki hem de açık Unity projenizdeki görevleri içerdiğini unutmayın (ör. Firebase yapılandırma dosyalarını konsoldan indirip bunları Unity projenize taşırsınız).
Verileri Yapılandırma
Bu kılavuzda, veri mimarisiyle ilgili bazı temel kavramlar ve Firebase Realtime Database'ünüzdeki JSON verilerini yapılandırmayla ilgili en iyi uygulamalar ele alınmaktadır.
Düzgün yapılandırılmış bir veritabanı oluşturmak için oldukça fazla ön hazırlık yapmanız 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? Bir JSON ağacıdır
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 veritabanının aksine, tablo veya kayıt yoktur. JSON ağacına veri eklediğinizde, bu veriler mevcut JSON yapısında ilişkili bir anahtara sahip bir düğüm olur. Kullanıcı kimlikleri veya anlamsal adlar gibi kendi anahtarlarınızı sağlayabilir ya da Push()
yöntemi kullanılarak anahtarlarınız sizin için sağlanabilir.
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 ASCII kontrol karakterlerini de 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, /users/$uid
gibi bir yolda bulunur. alovelace
kullanıcısının veritabanında şuna benzer bir giriş olabilir:
{ "users": { "alovelace": { "name": "Ada Lovelace", "contacts": { "ghopper": true }, }, "ghopper": { ... }, "eclarke": { ... } } }
Veritabanı bir JSON ağacı kullansa da veritabanında depolanan veriler, daha bakımı kolay 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ıyla ilgili en iyi uygulamalar
Verileri iç içe yerleştirmekten kaçının
Firebase Realtime Database, verileri 32 düzeye kadar iç içe yerleştirmeye izin verdiğinden bunun varsayılan yapı olması gerektiğini düşünebilirsiniz. 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 veri yapınızı mümkün olduğunca düz tutmak en iyisidir.
İç 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, sohbet görüşmelerine ait başlıkların listelenmesinin, tüm üyeler ve iletiler dahil olmak üzere chats
ağacının tamamının istemciye indirilmesi gerekir.
Veri yapılarını düzleştirme
Bunun yerine veriler, normalleştirmenin kaldırılması olarak da bilinen ayrı yollara bölünürse gerektiğinde ayrı çağrılarla verimli bir şekilde indirilebilir. Şu 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 listesini yinelemek ve odaları listelemek veya kullanıcı arayüzünde görüntülemek için meta verileri hızlıca getirmek mümkündür. Mesajlar ayrı ayrı getirilip geldikçe gösterilebilir. Bu sayede kullanıcı arayüzü duyarlı ve hızlı kalır.
Ölçeklenebilir veriler oluşturma
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, alt öğeleri üst öğenin altına yerleştirmeniz yeterlidir.
Bazen bu ilişki daha dinamik olabilir veya bu verileri normal dışı bırakmak gerekebilir. Veri Alma bölümünde açıklandığı gibi, verilerin bir alt kümesini almak için bir sorgu kullanarak verileri normalleştirmeden çıkarabilirsiniz.
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 kullanıcı listesinden oluşur. 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 ait verileri getirmenin zarif bir yoludur. Grup dizini burada çok faydalı 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 } }, ... } }
Bu, ilişkiyi hem Ada'nın kaydının hem de grubun altında saklayarak bazı verilerin kopyalandığını fark edebilirsiniz. Şimdi alovelace
bir grup altında dizine eklenmiş ve techpioneers
Ada'nın profilinde listeleniyor. Bu nedenle Ada'yı gruptan silmek için
hesabın iki yerde güncellenmesi gerekir.
Bu, iki yönlü ilişkiler için gerekli bir yedeklemedir. Kullanıcı veya grup listesi milyonlarca öğeye 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.
Kimlikleri anahtar olarak listeleyip değeri doğru olarak ayarlayarak verilerin ters çevrilmesi, anahtarın kontrol edilmesi için /users/$uid/groups/$group_id
okunup null
olup olmadığının kontrol edilmesi yeterlidir. Dizin, verileri sorgulamak veya taramaktan daha hızlı ve çok daha verimlidir.