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

Question

Сейчас я работаю над веб-приложением, которое будет отображать список элементов.Список является динамическим и может меняться между пользователями.Хорошая аналогия - думать об объектах как о книгах, а БД поддерживает их как библиотеку.

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

В настоящее время моя таблица невероятно проста: Book(id, name).Я могу получить доступ к большому количеству информации об этих книгах через вызов API, такой как обложка, количество страниц и т. Д. И т. Д. Я хотел бы сохранить подмножество этой информации, особенно URL-адрес изображения.

Я думаю, что разумным подходом было бы изменить мою таблицу Book так, чтобы она выглядела так: Book(id, name, imageUrl, otherValue, idOfThisBookInApiCallTable) значение idOfThisBookInApiCallTable позволит мне получить другие атрибуты по мере необходимости, однако у меня есть две проблемы с этим, которые я 'Я не уверен, что делать дальше.

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

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

Могу ли я спросить, может ли кто-нибудь увидеть какие-либо проблемы с этимподходить и / или предложить лучше, пожалуйста?У меня ограниченный опыт работы с db / web / app design, поэтому я немного не в себе.

Если сохранение изображения локально - это правильный подход, есть ли лучший способ сделать это?Заранее благодарим за любую помощь / предложения / советы.

Answer 1

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

1. Сначала о вашей таблице Book. Почему бы не таблица Library, где вы поддерживаете текущее состояние вашей библиотеки со всеми книгами, которые есть у библиотеки на данный момент.
2. Каждый пользователь может хранить коллекцию (таблицу и т. Д. С отношением один-ко-многим, например, user_id, список book_ids или что-то в этом роде), а затем каждому пользователю присваивается подмножество bookID.
3. При добавлении новой книги через пользователя или через библиотеку (библиотека может также добавлять больше книг, даже если ни один конкретный пользователь не внес ее), всегда добавляйте ее в библиотеку, и если user_id известен как «владелец» этой книги добавьте отношение для этого пользователя также в таблицу сбора
4. Более подробную информацию о книге можно сохранить отдельно в таблице BookDetails.
5. Хранение изображений на вашей стороне - это всегда хороший вариант, и вы не хотите, чтобы API блокировался за чрезмерное использование при запросе снова и снова. Вы можете использовать некоторое облачное хранилище, такое как s3, где вы можете хранить изображения, а затем не беспокоиться о внешних API. S3 поддерживает сжатие и кэширование, поэтому вы можете сэкономить много времени и избежать проблем со скоростью.

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