Как должна выглядеть структура json, которую можно выводить с конц, можно обращаться по номеру и удалять?

Question

[accountnujen]

{
  "tags": {
    "юр": [1,0],
    "зозпп": [0],
    "oracle": [2],
  },
  "data": [
    {
      "title": "Заголовок 1",
      "content": "Запись 1",
      "tags": [
        "юр",
        "зозпп"
      ]
    },
    {
      "title": "Заголовок 2",
      "content": "Запись 2",
      "tags": [
        "юр"
      ]
    },
    {
      "title": "Заголовок 3",
      "content": "Запись 3",
      "tags": [
        "oracle",
      ]
    }
  ]
}

Есть вот такой json. Я делаю его parseJSON.
И вот такие операции я хочу совершать:

• Выводить все записи data, но в обратном порядке (начиная с последних)
  
• Добавлять запись в конец этого объектомассива
  
• Обращаться к записи по id.
  
• выводить все записи по тегу
  
• Удалять запись, используя его id
  

К примеру вывод записи в обратном порядке я делаю вот так:

jsonara.data.reverse();
viewContent(jsonara.data);
jsonara.data.reverse();

Зачем второй раз делаю реверс? Потому что после вывода есть вероятность, что будет добавлена новая запись. И как оказалось сделать дважды реверс быстрее, чем хранить 2 массива в обратном и прямом порядке или делать unshift (скорость последнего вообще на уровне *sarcasm*)

Обращаться по ID я могу без проблем до тех пор пока не появляется вопрос удаления записи. Если я делаю .splice, то у меня теряется порядок этих записей. В этом случае меня спасёт объект и тогда у меня будет "1":{...},"2":{...},"3":{...}, НО в этом случае я не могу доставать записи в обратном порядке, потому что мне придётся переводить это всё в массив, а затем обратно в объект, чтобы сохранить в json, что очень ресурсоёмко.

Что делать?

Comments

[Aetae]

Ты для микрокотролера пишешь? Просто иначе производительность unshift как и большинства иных операций - в пределах погрешности для миллионов записей перебираемых миллион раз в секунду.:)

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

[Александр Талалаев]

Недостаточно инфы.
Где id? Как они его получают, где хранится?

[accountnujen]

Aetae,

Ты для микрокотролера пишешь?

ну вот зачем такая позиция? Теперь минимум нужно 16гб озу иметь и 4 ядра. ГОСТ что ли вводить на ПО?)

Просто иначе производительность unshift как и большинства иных операций - в пределах погрешности для миллионов записей перебираемых миллион раз в секунду.:)

ну вот нихрена не так.

https://measurethat.net/Benchmarks/Show/12353/0/ar...

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

Ну может удобство какое-то появится, хотя вид классов не интуитивно понятный этому не способствует. Чем хуже просто функции - не ясно.

Александр Талалаев,

Где id? Как они его получают, где хранится?

порядковый номер массива data[x], где x - это id.

[Aetae]

accountnujen,

ну вот нихрена не так.

а ты руками замерь. Хз что у них там на самом деле значат ops/sec.
Ну и естественно наполнение всего массива через unshift - неоптимально. А вот добавить один элемент в уже имеющийся массив от push неотличимо.

хотя вид классов не интуитивно понятный этому не способствует

Что тут непонятного то?

class DB {
  constructor(json) {
    // начальная подготовка структуры
  }

  toJSON() {
    // экспорт структуры для сохранения
  }

  reversed() {}

  reversedIterator() {}

  byTag(tag) {}

  byTagIterator(tag) {}

  add(record) {}

  get(id) {}

  delete(id) {}
}

[accountnujen]

Aetae,

Что тут непонятного то?

и как потом пользоваться?

[Aetae]

В смысле как? Как обычно:

const articleDB = new DB(json);

console.log(articleDB.get(1));
articleDB.delete(1);

for(const article of articleDB.byTagIterator('oracle')) {
  console.log(article)
}

saveToFile(articleDB.toJSON());

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

[accountnujen]

Aetae,

В этом суть классов.

ну и где я выиграл?

function getArticle(id) { ... }
function deleteArticle(id) { ... }
console.log(getArticle(1));
deleteArticle(1);

Чем это хуже?

при этом никак не влияя на уже рабочий код

ну я точно также могу функции переписывать, не меняя структуру рабочего кода.

[Aetae]

accountnujen, можешь. А можешь и вообще лапшу писать, ктож те запрещеят. Вопрос распределения зон ответственности, компоновки кода, и прочих всяких заумных слов. Если интересно - почитаешь какой-нить учебник по ООП и нахрена козе баян, не интересно - не почитаешь. Нет смысла тут очевидные вещи объяснять, коли оные пока не очевидны.:)

[accountnujen]

Aetae,

Нет смысла тут очевидные вещи объяснять, коли оные пока не очевидны.:)

ну вот разницу между лапшой и функциями/классами я вижу, а вот разницу между классами и функциями - нет. Точно также в отдельном месте перечисляются, а в другом месте используются. Где профит?

С учётом того, что переменная доступна внутри функции (в отличии от php) - преимуществ никаких не видно. Возможно даже хуже по скорости (но это не точно)

Хз что у них там на самом деле значат ops/sec.

operations per second

Answer 1

[sanders rocket]

const reversedData = jsonData.data.reverse();
console.log(reversedData);
// добавление новой записи
const newEntry = {
   "id": 1,
  "title": "Новый заголовок",
  "content": "Новая запись",
  "tags": ["юр", "новый_тег"]
};

jsonData.data.push(newEntry);
console.log(jsonData.data);

// поиск по тегам
function getEntriesByTag(tag) {
  return jsonData.data.filter(entry => entry.tags.includes(tag));
}

const tag = "юр";
const entriesWithTag = getEntriesByTag(tag);
console.log(entriesWithTag);
// удаление по index, но учти, что это index записи, пример правильный записи выше, и правильно тебе сказали выше, что нужно хранить id в самой записи
function deleteEntryById(id) {
  const indexToDelete = jsonData.data.findIndex(entry => entry.id === id);
  if (indexToDelete !== -1) {
    jsonData.data.splice(indexToDelete, 1);
  }
}

const idToDelete = 1; 
deleteEntryById(idToDelete);
console.log(jsonData.data);

Comments

[accountnujen]

Я правильно понял, чтобы найти id=395 - нужно перебрать все записи в поисках id?

const indexToDelete = jsonData.data.findIndex(entry => entry.id === id);

[sanders rocket]

accountnujen, да

[Aetae]

accountnujen, очевидно - да. Иначе - хранить все записи в двух видах: в виде массива и в виде объекта, работая одновременно с двумя. Либо использовать Map у которой есть forEach, либо сделать итератор на основе объекта, либо каждый раз таки преобразовывать в массив.
Забавный(на самом деле отвратительный) факт: числовые ключи объекта в js всегда идут первыми и в отсортированом виде, все остальные - по мере добавления: Object.keys({2:0, 3:0, 1:0}) // ['1', '2', '3'], возможно этот факт тебе чем-то поможет.

[accountnujen]

Aetae,

очевидно - да

ну этоже плохо... Я возвращаюсь домой и чтобы попасть в свою 713 квартиру я начинаю засовывать ключ в замочную скважину каждой квартиры пока не доберусь до своей... Мой вариант, на котором я остановился (использовать массив и удалять через delete, получая запись null) - не такой уж и плохой вариант на фоне этого (без обид, sanders rocket)... По крайней мере он будет быстрее работать, чем каждый (карл!) раз ходить по объекту в поисках чуда.

[sanders rocket]

accountnujen, ты можешь использовать sqlite3, серверную базу данных, которая будет сразу давать нужный результат по ID.

[accountnujen]

sanders rocket,

ты можешь использовать sqlite3, серверную базу данных, которая будет сразу давать нужный результат по ID.

я хочу хранить информацию в сети в виде текста. То есть, условная запись в telegra.ph - моя БД