LINUX.ORG.RU

Формат данных и API

 , , ,


0

1

Всем привет.

Есть документная БД, в ней хранятся записи-документы конкретных смысловых сущностей. Для примера пусть сущность эта зовется Person.

Пусть полный документ Person имеет следующий вид:

{
    "id": 12345,
    "name": {
        "ru": "тест",
        "en": "test"
    },
    "permisions": {
        "perm1": true,
        "perm2": false,
        "perm3": true,
    },
    "contacts": {
        "phone": "+000000000",
        "email": "person@example.com"
    }
}

Дело в том, что для тех или илных Person's может НЕ быть определенных данных. Напрмимер данные контактов могут либо вообще отсутствовать, либо может отсутствовать только часть из них (например телефон). Аналогично c permissions.

Есть http API, которое возвращает на клиент коллекции этих документов, в виде JSON.

Идеологический вопрос. Как лучше хранить И отдавать данные на клиент? Например, если нет данных для контактов, можно записать в БД «расшитые», но пустые контакты, а можно записать объект контактов как null (или пустой объект {}, без расшития на его структуру:

Вар 1.:

"contacts": {
        "phone": null,
        "email": null
    }

Вар 2.:

"contacts": {}

Вар 3.:

"contacts": null

Какой вариант хранения лучше (ВСЕГДА расшитый по максимуму, сжатый, но с сохранением типа [пустой объект], сжатый/зануленный)?

И вопрос со звездочкой, ГДЕ можно прочитать про то, как правильно хранить документы в документной БД, в которой не предусмотрены ограничение целостности данных (монга, еластик и проч)?

Кто как делает в своих проектах?


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

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

TDrive ★★★★★
()

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

TDrive ★★★★★
()
Последнее исправление: TDrive (всего исправлений: 1)

Как лучше хранить И отдавать данные на клиент?

Как клиент должен отображать отсутствие емыла? Отсутствием текста в поле с лейблом Email? Или отсутствием поля с лейблом Email? Ну вот так и отдавай. А как оно в базе будет хранится - это от орагнизации базы, например, зависит. Вообще лучше заморочится и сделать так, чтобы формат базы и формат API не были прибиты друг-к-другу гвоздями. В будущем может сильно помочь.

Stanson ★★★★★
()

Ответ получен, спасибо большое всем.

djnoob
() автор топика

Я в json и хранил, но мне и запросы делать не надо было/часто читать и писать их. А вообще если надо часто читать и писать то придётся нормализовать и раскидывать на кучу таблиц.

peregrine ★★★★★
()

Какой вариант хранения лучше (ВСЕГДА расшитый по максимуму, сжатый, но с сохранением типа [пустой объект], сжатый/зануленный)?

Если для тебя нет разницы, то согласуй с тем, кто будет пользоваться этим API. В моей практике был случай, что mobile-разработчики использовали какой-то фреймворк, который из null делал 0.

dicos ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.