Сжатие JSON

Если вы включите GZip сжатие при отдаче с сервера, то получите тоже самое, но прозрачно — архиватор построит частотное дерево для повторяющихся строк и заменит каждую из них несколькими битами.

Использование найденного вами подхода также ограничивает формат данных — все записи должны иметь одинаковую структуру.

Вопервых это слишком специфичная оптимизация. Я допустим ни разу не встречал необходимости в подобном. Это все же не оптимизация даже, а способ агрегации данных.

Во вторых — да, это экономия на спичках. Даже если у вас этих данных мегабайт, то вы еще должны будете на клиенте/сервере данные обработать. Я бы лучше поэкономил процессорное время.

Эта «оптимизация» больше зависит от того, как эти данные будут обрабатываться и использоваться.

Первый вариант имеет право на жизнь, поскольку он позволяет в потоке «кусками» передавать строки таблицы (структура данных и предложенная оптимизация больше похожа на описание таблицы), более того, позволяет пропускать значения конкретных «столбцов» считая что обработчик на автомате подставит туда `null` значения — данных то нет.

Второй вполне логичная оптимизация, однако потоком такую «таблицу» уже не передать, поскольку структура не предусматривает это by design и `null` значения уже не пропустить, иначе собьется порядок следования значений «стоблцов».

Итого: it depends. Необходимость этой «оптимизации» зависит не от экономии, а от способа обработки данных.

P.S. Если нужно получить более компактное представление JSON данных, при этом не пугает binary-формат и не хочется связываться с gzip — можно попробовать UBJSON — при полной совместимости размер обычно меньше процентов на 20-40, особенно при малом количестве ascii-строк и обилии unicode и числовых значений.

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

Если рассматривать данный подход как некую контентозависимую архивацию — то он имеет право на жизнь. Но его эффективность нужно сравнивать с другими решениями — для бинарных данных (контентонезависимыми) и текстовых. Сравнивать необходимо выигрышь при сжатии и скорость архивации и разархивации. Даже если вы и выиграете — конечно только в специфическом json — врятли в типичном. А чтобы еще и овчинка стоила выделки (то есть разница со стандартными архиваторами имела бизнес значение на проекте) — по моему нужно совсем какие то экзотические условия.

Но я могу и ошибаться — вы можете провести исследования и проверить.
Или используйте готовые решения для сжатия текстовых данных.
Для xml в отличие от json — есть сжатие специфическое для xml над сжатием текста — там с этим намного проще.