Сохранение подклассов в базе данных Firebase в реальном времени - PullRequest
1 голос
/ 18 апреля 2019

У меня следующая структура класса.

class User{
    String name;
    Thing things[];
}

interface Thing{

}

class ThingA implements Thing{
    String something;
}

class ThingB implements Thing{
    String anotherthing;
}

Каков наилучший способ сохранения User объектов в базе данных?

То, что я сейчас делаю, похоже;

{
    "users": {
        "name": "My Name",
        "thingAs": [{
            "something": "value",
        }],
        "thingBs": [{
            "anotherthing": "value",
        }]
    }
}

Я не могу придумать другой способ сделать это. Есть ли у вас лучшие решения?

Спасибо !!

1 Ответ

1 голос
/ 18 апреля 2019

Главное, чтобы в базе данных был маркер, указывающий тип каждой вещи. В вашей модели данных вы смоделировали этот маркер как ключ узла, под которым вы храните вещи этого типа.

Альтернативная модель - хранить маркер типа для каждого элемента отдельно. Итак:

"userA": {
    "name": "My Name",
    "things": [{
        "type": "ThingA",
        "something": "value",
    }, {
        "type": "ThingB",
        "anotherthing": "value",
    }]
}

Обе модели могут работать, и обе модели имеют свои преимущества и недостатки. Вот некоторые из них, о которых я могу быстро подумать:

  • Ваша модель сохраняет маркер типа только один раз, в то время как альтернативная модель, которую я предлагаю, сохраняет его для каждого элемента.
  • Моя альтернативная модель может поддерживать порядок элементов независимо от их типа, в то время как ваша модель может поддерживать порядок только в пределах того же типа.

Здесь нет единственно правильной модели. Как обычно при моделировании данных NoSQL, все зависит от вариантов использования вашего приложения. Например: если порядок элементов не важен для вашего приложения, то модель в вашем вопросе может сэкономить вам место для хранения базы данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...