Squeak.ru - шаблоны программирования

Laravel, Продукты с атрибутами в таблице "многие ко многим"

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

Поставщик может создавать продукты, и он может добавлять к ним всевозможные атрибуты, такие как размер, цвета.

Когда Магазин хочет использовать один из продуктов Поставщика, он может выбрать, какие атрибуты он хочет предложить. Например, если у поставщика есть в продаже футболка трех размеров. Магазин может продать эту футболку только двух размеров.

Итак, у меня есть таблица Товары, которая выглядит так. Поставщик добавляет сюда товары.

+----+-------------+-------+
| id | description | price |
+----+-------------+-------+
|  1 | T-Shirt     |    10 |
|  2 | Car         |   100 |
+----+-------------+-------+

У меня есть таблица атрибутов продукта, которую также заполняет поставщик.

+------------+-------------+------------------------------+
| product_id | description |           options            |
+------------+-------------+------------------------------+
|          1 | size        | ["small", "medium", "large"] |
|          1 | color       | ["white", "black"]           |
+------------+-------------+------------------------------+

Сторона магазина

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

+---------+------------+-----------+
| shop_id | product_id |   image   |
+---------+------------+-----------+
|       1 |          2 | image.jpg |
|       1 |          3 | image.jpg |
+---------+------------+-----------+

Остается только один вопрос: как убедиться, что Магазин может выбирать, какие атрибуты он хочет получить.

  • Должен ли я создать таблицу shop_product_attributes .. Но я не могу установить связь для "многие-ко-многим", потому что у нее нет идентификатора?

  • Вы хотите, чтобы магазин мог ограничить, какие продукты они принимают с атрибутом твердых частиц? так сказать футболка маленькая черная? 01.06.2017
  • Да! Магазин действительно может выбрать, какие атрибуты он хочет скопировать. благодарю вас! 01.06.2017

Ответы:


1

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

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

+----+-------------+-------+-----------+-------------+
| id | name        | price | image     | description |
+----+-------------+-------+-----------+-------------+
|  1 | Super-T     |    10 | image.jpg | some text   |
|  2 | Focus       |   100 | image.jpg | some text   |
+----+-------------+-------+-----------+-------------+

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

+----+-------------+------------+--------------+
| id | sku         | product_id |  category    |
+----+-------------+------------+--------------+
|  1 | p1-cb-m     |    1       | t-shirt      |
|  2 | p2-cb-s     |    2       | t shirt      |
+----+-------------+------------+--------------+

Затем создайте таблицу attributes_sku, это свяжет артикул с атрибутом

+---------------+--------------+
| sku_id        | attribute_id |
+---------------+--------------+
| 1             |    1         |
| 1             |    2         |
+---------------+--------------+

Атрибуты для нормализации

+----+-------------+------------+
| id | type        | name       |
+----+-------------+------------+
|  1 | color       |    black   |
|  1 | size        |    medium  |
+----+-------------+------------+

Таблица артикулов магазина

+---------+------------+
| shop_id | sku_id     | 
+---------+------------+
|       1 |          1 |
|       1 |          2 |
+---------+------------+

Преимущества этого в том, что вы можете foreach $shop->skus where category = t-shirt показать все свои футболки

тогда вы можете сделать $ skus-> product-> name $skus->product->attribute->name или, еще лучше, установить связь в модели sku, например, цвет $this->attribute->where('type', color);

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

01.06.2017
  • Это очень хорошо продумано! Похоже, модель получше. как сделать такую ​​хорошую модель? Кажется, я всегда теряюсь в своих столах. Я собираюсь реализовать эту модель (после того, как полностью ее пойму! Большое вам спасибо. 01.06.2017
  • Спасибо за редактирование! Это действительно хорошая идея. Есть ли способ для людей с небольшими знаниями БД перейти от моего проекта БД к вашей версии? Или это просто опыт, который заставил вас придумать этот идеальный дизайн? 01.06.2017
  • Это просто нормализация опыта и понимания, ключ в том, чтобы разбить вещи на части и увидеть, где вы повторяете себя, а затем нормализовать их. 01.06.2017
  • Еще раз спасибо за ваше время, есть еще одна проблема. Итак, теперь я правильно использую артикул как товар, которым владеет магазин. Но как поставщик, поэтому тот, кто создает продукты, также должен иметь возможность выбирать возможные атрибуты для этих продуктов. Должен ли я тогда добавить список product_attributes? что делает то же самое, что и sku_attributes, но для поставщика? 01.06.2017
  • Или мне следует использовать полиморфизм и изменить sku_attributes на productable_attributes, чтобы и поставщик, и магазин могли использовать одну и ту же таблицу для хранения атрибутов? 01.06.2017
  • если я понимаю ваших поставщиков, создающих продукты? а магазины выбирают какие на склад? Если это так, поставщики также будут создавать артикулы, вам больше не понадобятся таблицы. при создании продукта попросите их назначить товарный знак продукту, и они добавят атрибуты к этому наименованию товара. 01.06.2017
  • Нет, извините, поставщики могут, например, выбрать цвета: черный, белый, золотой, но Магазин может выбрать только черный и белый. Таким образом, у них есть разные наборы атрибутов (большое спасибо за ваше время!) 01.06.2017
  • Хорошо, я немного запутался, лол, кто создает продукты? 01.06.2017
  • Позвольте нам продолжить это обсуждение в чате. 01.06.2017
  • у тебя есть еще время поболтать? 20.06.2017

  • 2

    Фактически, вы можете создать отношение «многие ко многим» в таблице shop_product_attributes.

    Поскольку ваша таблица атрибутов продукта имеет составной ключ из двух полей: [product_id,description], ваше отношение «многие ко многим» будет иметь тройной ключ - [shop_id,product_id,description], где [product_id,description] также используется как ссылочный внешний ключ.

    01.06.2017
  • Спасибо за Ваш ответ! Мне очень трудно понять, извините! Должен ли я тогда остаться с двумя таблицами типа "многие ко многим"? 01.06.2017
  • Да, один для shop_product, а другой - для shop_product_attributes. Хотя первая кажется немного бесполезной, это правильная нормализованная форма. 01.06.2017
  • Новые материалы

    Угловая структура архитектуры
    Обратите внимание, что эта статья устарела, я решил создать новую с лучшей структурой и с учетом автономных компонентов: https://medium.com/@marekpanti/angular-standalone-architecture-b645edd0d54a..

    «Данные, которые большинство людей используют для обучения своих моделей искусственного интеллекта, поставляются со встроенным…
    Первоначально опубликовано HalkTalks: https://hacktown.com.br/blog/blog/os-dados-que-a-maioria-das-pessoas-usa-para-treinar-seus-modelos-de-inteligencia-artificial- ja-vem-com-um-vies-embutido/..

    Сильный ИИ против слабого ИИ: различия парадигм искусственного интеллекта
    В последние годы изучению и развитию искусственного интеллекта (ИИ) уделяется большое внимание и прогресс. Сильный ИИ и Слабый ИИ — две основные парадигмы в области искусственного интеллекта...

    Правильный способ добавить Firebase в ваш проект React с помощью React Hooks
    React + Firebase - это мощная комбинация для быстрого и безопасного создания приложений, от проверки концепции до массового производства. Раньше (знаете, несколько месяцев назад) добавление..

    Создайте API с помощью Python FastAPI
    Создание API с помощью Python становится очень простым при использовании пакета FastAPI. После установки и импорта вы можете создать приложение FastAPI и указать несколько конечных точек. Каждой..

    Веселье с прокси-сервером JavaScript
    Прокси-серверы JavaScript — это чистый сахар, если вы хотите создать некоторую общую логику в своих приложениях, чтобы облегчить себе жизнь. Вот один пример: Связь клиент-сервер Мы..

    Получить бесплатный хостинг для разработчиков | Разместите свой сайт за несколько шагов 🔥
    Статические веб-сайты — это веб-страницы с фиксированным содержанием и его постоянным содержанием. Но теперь статические сайты также обрабатывают динамические данные с помощью API и запросов...