Регистрация  |  Вход

Сохранение объекта в виде JSON стринга в БД

Это более общий вопрос, но сама идея мне показалась интересной. Интересной концепцией сохранения структурированных данных.

Увидел это пару недель назад в описании как работают гибридные мобильные приложения.
Там записи наших SF объектов являюся JS объектами (что предсказуемо), но сохраняют они их в SQLite - просто в виде JSON стринга.
В начале мне это показалось возмутительным упрощением - ну нужно же все поля объекта раскидать по полям записи БД.

А потом как-то лежал-дремал и думал: а ведь это просто и удобно.

Вот напрмер от SOAP - сервера я получаю ответ который тутже обормляется в виде объетка. Я мне его нужно сохранить в какой-то рабочей записи. И чего я буду парится, раскидывать его по нескольким полям, просто серилизую и сохраню, и потом при чтении просто создам из JSON стринга новый объект, и работай с ним.

Ваше мнение, коллеги?

Это более общий вопрос, но сама идея мне показалась интересной. Интересной концепцией сохранения структурированных данных.

Увидел это пару недель назад в описании как работают гибридные мобильные приложения.
Там записи наших SF объектов являюся JS объектами (что предсказуемо), но сохраняют они их в SQLite - просто в виде JSON стринга.
В начале мне это показалось возмутительным упрощением - ну нужно же все поля объекта раскидать по полям записи БД.

А потом как-то лежал-дремал и думал: а ведь это просто и удобно.

Вот напрмер от SOAP - сервера я получаю ответ который тутже обормляется в виде объетка. Я мне его нужно сохранить в какой-то рабочей записи. И чего я буду парится, раскидывать его по нескольким полям, просто серилизую и сохраню, и потом при чтении просто создам из JSON стринга новый объект, и работай с ним.

Ваше мнение, коллеги?

Den Brown, ты только что изобрел NoSQL базу данных.

Очень даже жизнеспособная конструкция - хранить данные в виде JSON. Если искать по ним средствами самой базы данных не нужно, то лучше и не придумаешь.

Если не сталкивался с NoSQL то советую попробовать MongoDB для профессионального развития. На многие вещи начинаешь смотреть по другому.

:) Den Brown, ты только что изобрел NoSQL базу данных.

Очень даже жизнеспособная конструкция - хранить данные в виде JSON. Если искать по ним средствами самой базы данных не нужно, то лучше и не придумаешь. 

Если не сталкивался с NoSQL то советую попробовать MongoDB для профессионального развития. На многие вещи начинаешь смотреть по другому.

Очень актуально для SF, так как все кастомные объекты "весят" по 2 килобайта. Вернее SF их так считает, даже если завести в объекте кучу полей типа Long Text Area (притом, что хотя бы один заполненный филд такого типа будет "весить" ~ 64кб = 32768 * 2b), то всё-равно объект будет считаться по 2 килобайта. Однако есть ограничение, каждый объект может содержать не более чем 1.6 млн. символов в полях типа Long Text Area и Rich Text Area, это примерно 3 мегабайта.

Кому интересно, вот сколько весят объекты SF:
Leads -- 2KB
Contacts -- 2KB
Accounts -- 2KB
Person Accounts - 4KB
Opportunities -- 2KB
Forecasts -- 2KB
Events -- 2KB
Tasks -- 2KB
Cases -- 2KB
Case Team Member – 2KB
Solutions -- 2KB
Notes -- 2KB
Custom Reports -- 2KB
Campaigns - 8KB
Campaign Members – 1KB
Contracts – 2KB
Google Docs – 2KB
Quotes – 2KB
Tags: unique tags – 2KB
Custom Objects – 2KB
Quote Template Rich Text Data - 2KB
Articles - 4KB

Приходилось мне реализовывать похожие вещи (хранение в SF JSON объектов), кому понадобиться могу привести примеры кода по разбивке JSON по филдам объекта и назад, а так же использовании подчинённых объектов, если один JSON не влез в родительский объект.

Очень актуально для SF, так как все кастомные объекты "весят" по 2 килобайта. Вернее SF их так считает, даже если завести в объекте кучу полей типа Long Text Area (притом, что хотя бы один заполненный филд такого типа будет "весить" ~ 64кб = 32768 * 2b), то всё-равно объект будет считаться по 2 килобайта. Однако есть ограничение, каждый объект может содержать не более чем 1.6 млн. символов в полях типа Long Text Area и Rich Text Area, это примерно 3 мегабайта.

Кому интересно, вот сколько весят объекты SF:
Leads -- 2KB
Contacts -- 2KB
Accounts -- 2KB
Person Accounts - 4KB
Opportunities -- 2KB
Forecasts -- 2KB
Events -- 2KB
Tasks -- 2KB
Cases -- 2KB
Case Team Member – 2KB
Solutions -- 2KB
Notes -- 2KB
Custom Reports -- 2KB
Campaigns - 8KB
Campaign Members – 1KB
Contracts – 2KB
Google Docs – 2KB
Quotes – 2KB
Tags: unique tags – 2KB
[b]Custom Objects – 2KB[/b]
Quote Template Rich Text Data - 2KB
Articles - 4KB

Приходилось мне реализовывать похожие вещи (хранение в SF JSON объектов), кому понадобиться могу привести примеры кода по разбивке JSON по филдам объекта и назад, а так же использовании подчинённых объектов, если один JSON не влез в родительский объект.