Member 13902250 Ответов: 3

Lnked списки: как минимизировать временную и пространственную сложность в конкретном случае


Я постараюсь кратко описать проект, над которым работаю, а затем задам свой вопрос.

Проект:

Предположим, вы управляете интернет-магазином, который соединяет покупателей с продавцами. Итак, есть список товаров и список покупателей. Когда покупатель удовлетворен товаром, он кладет его в корзину, и товар удаляется из доступных товаров, показанных другим пользователям.

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

Вопрос: у меня есть список действий, которые происходят, например "BUYER1 входит в систему", "ITEM11 продается" или "BUYER13 кладет ITEM1 в корзину" (мы пренебрегаем оформлением заказа), и мне было интересно, какая структура данных более подходит для обработки этого конкретного случая, в частности, какое решение является лучшим с точки зрения временной и пространственной сложности. Я должен реализовать свой проект В С.

Что я уже пробовал:

I came up with two possible solutions: I could store items data in a linked list of structures (with fields like Id, price etc.) named "available items" and store buyers data in a linked list of structures that contains a field named let's say "basket" which is a linked list of items and when a buyers puts a product in the basket the item is removed from the "available items" and appended to the "basket". The issue could be that when a sell is called off I don't know who put the item in the basket so I should go through the list of buyers and for each of them through their basket to delete the product. Or I could add a field to the items struct named let's say "buyerID" where I could change the value from 0 (the item is available) to the ID of the buyer that put the item in the basket but when I have to print a report for each buyer I have to go through the list of items to know what he is buying.

Не знаю, эффективны ли решения, которые я придумал, как с точки зрения временной, так и пространственной сложности. Не могли бы вы предложить мне лучшее решение? Заранее всем большое спасибо! Любая помощь будет оценена по достоинству.

nv3

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

3 Ответов

Рейтинг:
1

gggustafson

Я не думаю, что буду использовать список, а скорее использовать два массива (C позволяет легко расширить массив) и указатель.

Один массив содержит записи элементов (int index; int available; int inventory; ...). Индекс - это индекс элемента в массиве. Это также может быть идентификатор записи SQL-подобной записи. Доступный содержит количество товаров, которые находятся в наличии и доступны для продажи. Запасы-это количество товаров, находящихся в наличии. Доступный всегда меньше или равен запасу. (Обратите внимание, что "..." означает других участников записи.)

Второй массив содержит записи покупателя (int index; string name; Cart *cart; ...). Индекс-это то же самое, что и индекс элемента. Имя - это имя покупателя. Корзина-это указатель на запись корзины.

Запись корзины содержит три поля (int index; int count; Cart *next; ...). Индекс-это индекс записи товара, который будет приобретен. Count-это количество предметов, которые необходимо приобрести. Next-это указатель на следующий элемент в корзине или null, если в корзине больше нет записей.

Преимуществом использования массивов является скорость доступа и меньшая потребность в пространстве. Единственная существенная стоимость-это добавление нового элемента в массив элементов. Но это происходит только один раз и может быть достигнуто путем добавления нового элемента в конец массива. Обратите внимание, что в одно и то же время должен существовать только один покупатель.

Я бы очень хотел нарисовать это решение, но я не знаю, как предоставить чертеж в разделе решений.


Member 13902250

Привет gggustafson, я хотел бы предоставить вам больше информации об этой проблеме! Первое, что нужно отметить, это то, что для каждого товара у вас есть только одна единица для продажи (например, eBay), и я читаю "поток" товаров для продажи, онлайн-покупателей и т. д., читая эту информацию из файла (например, текстовый файл типа: item1 теперь продается, intem23 теперь продается, buyer1 онлайн и т. д.). Я думал о связанных списках записей, потому что заранее не знаю, сколько товаров продается, поэтому я не могу угадать размерность вектора, и я должен перераспределять векторы при каждом взаимодействии! большое спасибо за ваш ответ!

Рейтинг:
0

KarstenK

В реальном сценарии каждый будет запускать это в режиме реального времени. транзакция на основе база данных. Но проблема остается прежней: если вы меняете свое хранилище больших данных при каждом изменении, которое вы теряете.

Лучше всего это сделать НЕ манипулируйте хранилищем данных, но устанавливайте некоторые поля и флаги в структуре данных или базе данных. Like находится в корзине (id и, возможно, тайм-аут). И вы также должны иметь некоторый кэш или дополнительное хранилище о товарах в корзине для более быстрого завершения продажи или удаления.


Рейтинг:
0

Patrice T

Цитата:
Lnked списки: как минимизировать временную и пространственную сложность в конкретном случае

Как вам уже было сказано, linked list-это неправильный инструмент для этого проекта.
Вам нужно узнать о базах данных и дизайне баз данных.

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

сложность поиска 1 элемента в списке
Number items        1000   1000000
Linked list
load/save list      1000   1000000
find an item mean    500    500000
find an item max    1000   1000000

indexed database
load/save list        no need
find an item mean     10        20
find an item max      10        20