Это более общий вопрос, но сама идея мне показалась интересной. Интересной концепцией сохранения структурированных данных.
Увидел это пару недель назад в описании как работают гибридные мобильные приложения.
Там записи наших 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 не влез в родительский объект.