Как я должен представлять табличные данные в формате JSON?

Question

Я пишу API для извлечения данных из Java-сервлета, подключенного к JDBC, через JSON. Я решил использовать JSON, потому что мы хотим выполнять сортировку и другие операции с данными в браузере и получать доступ к данным из разных доменов.

Поскольку я в основном выполняю SQL-запросы в JavaScript, возвращаемые данные имеют табличный характер. Я начал писать это так, что вы получите список меток столбцов, а затем массивы значений, например:

{
  "columns": [
    "given_name",
    "surname",
  ],
  "results": [
    [
      "Joe",
      "Schmoe"
    ],
    [
      "Jane",
      "Doe"
    ]
  ]
}

Но когда я начинаю писать JavaScript для работы с возвращаемыми данными, я думаю, что может быть лучше просто вывести результаты с парами ключ / значение, такими как:

{
  "results": [
    {
      "given_name": "Joe",
      "surname": "Schmoe"
    },
    {
      "given_name": "Jane",
      "surname" : "Doe"
    }
  ]
}

Если вы возвращаете много результатов, это много повторяется. Но мы собираемся передавать gzip, так что я не слишком обеспокоен пропускной способностью.

По сути, я должен спроектировать это так, чтобы получить доступ к своим данным с помощью

$.getJSON(query, function(data) {
  var columns = data.columns;
  var results = data.results;
  $.each(results, function(key, row) {
    console.log(row[columns.indexOf('surname')]);
  });
});

или намного красивее

$.getJSON(query, function(data) {
  var results = data.results;
  $.each(results, function(key, row) {
    console.log(row.surname);
  });
});

По сути, я хочу знать, оправдывает ли потенциальный удар по производительности гораздо более чистый синтаксис последнего варианта.

Последующие действия

Я реализовал оба способа и профиль. Профилирование было отличной идеей! Различия в производительности были незначительными. Различия в размерах передаваемых данных были существенными, но при сжатии Gzip разница была до 5-6% между обоими форматами и между очень большими и очень маленькими наборами данных. Так что я иду с более красивой реализацией. Для этого конкретного приложения я могу ожидать, что все клиенты будут поддерживать Gzip / Deflate, поэтому размер не имеет значения, а вычислительная сложность как на клиенте, так и на сервере достаточно схожа, и не имеет значения.

Для всех, кто заинтересован, вот мои данные с графиками !.

Answer 1

Обобщая другие ответы:

1. Ваш проводной формат не должен совпадать с форматом в памяти.
2. Профиль, который лучше - посмотрите, если он имеет значение.
3. Проще обычно начинать лучше.

Далее:

• Если у вас просто страница результатов и мало пользователей, то второй формат может быть не хуже первого формата.
• Если ваши данные довольно скудны, 2-й формат может хорошо быть лучше.
• Если вы отправляете 1000-е или строки данных и у вас миллионы пользователей, возможно, размер отправляемых вами данных начнет иметь значение, и, возможно, 1-й формат может помочь.
• Вы не можете гарантировать, что все пользовательские агенты поддерживают gzip / deflate, так что имейте это в виду.

Answer 2

Профиль обоих.Оптимизируйте потом.

Answer 3

Вам не нужно привязывать свой код к более компактному, но и более громоздкому формату.Просто напишите простой JS-адаптер, чтобы проверить возвращаемую структуру на наличие columns.Если этого не хватает, вы имеете дело с простым массивом объектов.Если он присутствует, вы можете легко сопоставить громоздкий формат с более удобным форматом.

Answer 4

Просто еще одна структура JSON, из которой я получил очень хорошие результаты:

{
    "recordCount": 2,
    "data": {
        "Id": [1, 2],
        "Title": ["First record", "Second record"]
        "Value": [18192, 18176]
    }
}

Обход всех данных:

for (var i = 0; i < recordSet.recordCount; ++i) {
    console.log("Record " + i.toString() + ":");
    for (var field in recordSet.data)
        console.log("\t" + field + ": " + recordSet.data[field][i].toString());
}

Answer 5

FWIW Я бы выбрал второй вариант: он более понятен JavaScript, как вы уже заметили, и человеку будет легче читать и понимать.Мне кажется, что удобочитаемость превосходит любой небольшой выигрыш в производительности, который вы получаете от варианта 1.

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