Цикл дважды по структуре данных из БД плохая идея, как еще? - PullRequest
0 голосов
/ 24 марта 2020

это, вероятно, более общий вопрос программирования, и он был у меня на уме.

У меня всего 1 год опыта, и недавно я начал читать книгу «Чистый код» и наткнулся на нотацию «Большой 0».

Эти две вещи в основном говорят, что вы никогда не должны проходить через l oop что-то дважды (L oop внутри l oop), потому что производительность ужасна (O (2n), если я правильно помню) .

Мой вопрос такой:

Если у меня есть эта структура, которая представляет собой массив всех заказов в моем приложении, и внутри этого массива есть объект, этот объект содержит другой массив, который является отдельным продуктом, который был в этом порядке.

[
  orderOne: {

    products: [
     {name: "Life advice", price: 399},
     {name: "Test", price: 429},
    ],

    userInformation: {
    name: "John",
    age: 21
    }
  }
]

Теперь, чтобы отобразить все ордера в моем представлении, мне нужно сначала l oop от общего количества ордеров, а затем внутри этого l oop, I l oop через массив продуктов внутри, который создает этот двойной l oop.

Как этого избежать? Кажется неизбежным, что внутри массива будет массив для хранения данных, который всегда будет означать двойной l oop.

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

Большое спасибо за потраченное время!

Берегите себя!

1 Ответ

0 голосов
/ 24 марта 2020

Это действительно зависит от того, чего вы пытаетесь достичь ...
Если вы просто отображаете заказы, то должен ли каждый заказ отображать все элементы одновременно?
Не будет ли это логичнее ли отображать элементы заказа после его выбора?
Лучше всего учитывать объем ваших данных, думая о том, как им манипулировать. Таким образом, вы обрабатываете данные только в том случае, если пользователю необходим доступ к ним, что должно уменьшить загрузку / обновление sh раз.

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

У вас также может быть отдельный массив продуктов, каждый с идентификатором, а затем у объекта заказа просто будет словарь идентификаторов продукта и количества. Затем это может быть решено в полный список для отображения довольно быстро.

...