В своем примере вы написали сервис А, вы же не имели ввиду одно трех из приложений в моем случае?
Конечно же, я имел в виду дополнительный сервис. Обычно это REST, как указал ThunderCat .
В моем случае я могу сделать четвертое приложение которое полностью отвечает за работу базы данных и организует доступ к базе для остальных приложений?
Верно. Только еще нужно почитать об аутентикации приложений и авторизации доступа.
FanatPHP, при обновлении характеристик колонка с JSON заменяется атомарно, целиком. Никаких лишних уровней вложенности нет. Ровно минимум необходимого. И никаких поисков ключей не нужно. Не вижу нужды объяснять такую простоту. Тем более, автор вопроса не спрашивал.
FanatPHP, увы, для вывода таблицы эта структура не подходит, т.к. названия ключей могут быть разными для разных товаров, поэтому программа не будет знать под каким ключом нужно искать значение для вывода таблицы.
Нужен массив структур/объектов, состоящих из 1-й (свойство) колонки и 2-й (значение свойства) для построения таблицы. Всё. "Словарь" в данном случае - это ключи "свойство" и "значение свойства". Всё лишь потому, что в JSON нельзя по-другому описать структуру. Опять же, в PHP, Ruby - это ассоциативный массив. Хотя в Ruby можно еще представить данные в Struct. В Go - каждая строка таблицы может быть представлена struct.
type Property struct {
Name string `json:"name"`
Value interface{} `json:"value"`
}
type Properties []Property
FanatPHP, я плохо знаю синтаксис PHP и по-моему указан ассоциациативный массив (словарь). А словарь тут не нужен.
Каждый элемент массива это объект. При построении таблицы из двух колонок просто берешь значение из соответствующего ключа.
Конечно же, я имел в виду дополнительный сервис. Обычно это REST, как указал ThunderCat .
Верно. Только еще нужно почитать об аутентикации приложений и авторизации доступа.