1. Общий дизайн
Причины принятия архитектуры промежуточной платформы объяснялись в предыдущих статьях, здесь мы представим функции базового уровня и уровня платформы.
1. базовый слой
Публикация, редактирование, полки, полки Эти функции должны быть более знакомы.
Обзор: нужно ли его проверять, прежде чем его можно будет включить в список?
Маркировка: маркировка товаров, например, участие в мероприятии
Управление артикулами: товары и отношения артикулов
Взаимоотношения: внешние и внутренние отношения продукта, комбинированные отношения продукта и т. д.
Внешние и внутренние товары: внешние товары ориентированы на пользователей, а внутренние товары ориентированы на склады.
Категория: товарная категория, внешние и внутренние категории
Атрибуты: атрибуты продукта, атрибуты категории и т. д.
2. уровень платформы
Товарный менеджмент: основные операции с товарами
Коллекция продуктов: управление любимыми продуктами пользователя
Снимки элементов: сохраняйте каждую версию снимка редактирования элемента.
Маркировка деятельности: сопоставление с различными маркировками атрибутов продукта в соответствии с различными видами деятельности.
Управление продажами: статистика продаж продукции и операции по сортировке
История просмотров: История просмотров пользователей.
Поиск: поиск товаров в разных размерах
2. Определение понятия
1. Item-sku
Item означает продукт, sku означает продукт
Пример: элемент соответствует мобильному телефону iPhone 7. Но iPhone 7 будет черно-белым. Артикул соответствует черному iPhone 7.
Соответствующее соотношение выглядит следующим образом:
2. Front-end и back-end продукты
Предварительные товары: ориентированные на пользователя, демонстрируемые и продаваемые в торговом центре, это виртуальная концепция.
Внутренние товары: например, для физических товаров на складе компьютер создаст внутренний товар. Он имеет тесную связь со складом, и такие операции, как синхронизация запасов, складирование и складирование, должны быть синхронизированы с информацией о продукте.
Между внешними продуктами и внутренними продуктами существует взаимосвязь. Например, если внешним продуктом является компьютер, внутренний продукт будет соответствовать компьютеру.
Конечные комбинированные товары: некоторые товары могут продаваться по отдельности или в пакетах, например скидка на компьютерный пакет.Этот пакет представляет собой комбинированный товар A, который состоит из компьютера B, мыши C и клавиатуры D.
Таким образом, существует отношение отображения A->(1B, 1C, 1D). В настоящее время, если вам нужно продавать в торговом центре, вы можете создать интерфейсный продукт, который будет связан с A.
3. отношение связи
Ассоциативное отношение здесь включает в себя: отношение сопоставления между интерфейсным продуктом и внутренним продуктом, а также отношение между внутренним комбинированным продуктом и отдельным продуктом. По этой зависимости можно определить, на каких складах товар находится в наличии, сколько нужно отгрузить и так далее.
4. Снимок продукта
Каждый раз, когда продукт редактируется, будет сохранен снимок, который может записывать журнал операций и отслеживаемость.Например, заказ будет сохранять версию снимка продукта, а информацию о продукте во время размещения заказа можно найти в соответствии с эта версия.
5. Маркировка продукта
Маркировка на самом деле является маркой.Например, продукт участвует в более чем дюжине действий, поэтому, как сохранить его на продукте, мы можем использовать флаг поля long для сохранения, long составляет 64 бита, и каждый бит представляет тип активность, 0 означает нет, 1 означает да, и обновление информации об активности может быть выполнено путем выполнения бинарных операций над флагом.
6. Категория
Категории также делятся на внешние и внутренние категории.Внешние категории ориентированы на пользователя, имеют функции навигации и являются изменчивыми.
Категория back-end напрямую связана с продуктом и очень стабильна. Существует взаимосвязь между категориями внешнего и внутреннего интерфейса.
7. Атрибуты
Атрибут, связанный с продуктом, например: черный мобильный телефон iPhone 7, он имеет цвет атрибута и значение атрибута — черный.
3. Технический проект
1. диаграмма отношений
2. Введение поля ключа продукта
Товарная таблица основана на дизайне подбиблиотеки и подтаблицы.
category_id: Между товаром и категорией существует отношение один к одному.При создании товара нужно сначала получить категорию, к которой относится товар. Решается, нуждается ли выпуск продукта в этой категории в пересмотре, и продукт должен быть заполнен атрибутами, связанными с этой категорией, и сохранен в продукте.
item_pattern: Товарная форма: в том числе физические товары, виртуальные товары, товары-услуги, почему это поле, потому что физические товары должны быть связаны с физическими товарами на складе; виртуальные товары не должны быть связаны, например, электронные книги, видео, и т. д.; сервисные товары — это еще один особый вид методов обработки, таких как трехлетняя гарантия, доставка на дом и т. д., которые используются как услуга. , Преимущество этого в том, что его легко расширить.
item_type: Тип товара: в том числе сырьевые и конечные товары, комбинированные товары или расширенные типы товаров.
shop_id: Собственный магазин
selle_id+item_code: Идентификатор продавца и код продавца. Если это продукт, импортированный собственной системой планирования ресурсов предприятия продавца, эти два поля уникальны и могут однозначно определять продукт системы продавца.
flag: Пометить бит, выполнить операцию двоичной маркировки.
biz_type: бизнес-платформа, к которой он принадлежит, и изоляция данных между различными бизнесами выполняется в соответствии с этим полем.
feature: Расширенное поле, в нем хранить атрибуты товара, а также хранить новую информацию в дальнейшем без изменения структуры таблицы.
3. Таблица истории товаров Item_history дизайн
Таблица истории — это таблица данных о продуктах, которые были удалены, так зачем же сохранять удаленные данные?Это принцип построения системы электронной коммерции.Данные в любой таблице удаляются только логически, а не физически. Так много таблиц добавят поле is_delete, чтобы отметить, было ли оно удалено.
Но зачем создавать новую таблицу для таблицы товаров?Здесь два момента: 1) В таблице товаров есть ограничение уникального ключа, (seller_id, item_code), если его удалить и поместить в исходную таблицу , когда продавец снова синхронизирует товар, из-за этих двух полей То же самое, это повлияет на ограничение уникального ключа, но его действительно нельзя удалить, поэтому данные перемещаются в таблицу истории. 2) Данные в таблице товаров со временем будут становиться все больше и больше. Перемещение удаленных данных поможет улучшить производительность исходной таблицы.
4. Дизайн моментального снимка продукта
Товары — это объекты в транзакциях электронной коммерции, и любые изменения в них имеют решающее значение, поэтому, с одной стороны, хранение моментальных снимков — это запись каждого изменения. С другой стороны, существует сценарий, аналогичный заказу на транзакцию, который требует информации о товаре в то время, чтобы обрабатывать жалобы и защищать права.
Тогда данные снимка еще больше, потому что каждое изменение будет генерировать часть данных, поэтому может быть не база данных, а внешнее хранилище. При запросе вам потребуется itemId+snapshotVersion, идентификатор элемента и версия моментального снимка для запроса.
5. Дизайн маркировки продукции
Сначала определите класс перечисления типов действий, указав, какое действие представляет каждый бит. В любом случае, другие типы хороши, просто чтобы пометить элемент как имеющий какой-то атрибут.
Если флаг=0, теперь продукт участвует в действии, и третья цифра флага представляет действие, процесс маркировки;
flag=flag | (1 << 2)
Демаркировать по той же логике.
6. Дизайн поля расширения продукта
Не только таблица продуктов, с ней мы будем часто сталкиваться в своей работе, в процессе непрерывной итерации требований обязательно возникнет потребность в добавлении полей, но если добавляемые поля не являются ключевыми (не используются для выборки) , такие как товары. Если внутренним продуктам теперь необходимо хранить такую информацию, как длина, ширина, высота, качество и некоторое происхождение, мы можем решить эту проблему, расширив поля, а также избегая операции добавления столбцов в онлайн-таблицу. . Функция поля расширения на самом деле представляет собой строку в формате Json, зарезервированную для определенной длины, и к ней будет добавлена пара ключ-значение, когда позже возникнет необходимость.
Например, он хранится так перед добавлением:
{“length”:10,“width”:12,”height”:20}После добавления источника становится
{“length”:10,“width”:12,”height”:20,”region”:”HZ”}
Однако при обновлении обязательно приносите обновления версий, иначе покрытие данных будет происходить параллельно. Это еще один принцип проектирования, причина, по которой все таблицы в базе данных должны добавлять поле версии: оптимистическое управление блокировкой обновлений данных.
7. Статистика продаж и сортировка товаров
Объем продаж на самом деле не является атрибутом самого продукта, поскольку объем продаж рассчитывается динамически в соответствии с объемом транзакций заказа на транзакцию, но на обычном веб-сайте электронной коммерции будет требоваться сортировка по объему продаж, поэтому как этого добиться? Это должна делать поисковая система, потому что слишком много условий поиска, слишком много условий сортировки, а индекс БД не может поддерживать различные комбинированные запросы и сортировку. Поэтому, в соответствии с потребностями бизнеса, мы обычно подсчитываем продажи один раз в день, чтобы удовлетворить потребности. Добавьте поле продаж в товарный указатель, и выполняйте ежедневные плановые задачи по подсчету продаж из заказа, а затем отправляйте его в поисковую систему в виде сообщения.Поисковая система может помочь нам реализовать эту функцию при поиске сортировки.
8. дизайн категории товаров
Дизайн категорий будет подробно представлен в следующих статьях. Включая внешние категории, внутренние категории, построение дерева категорий, дизайн кэша категорий, атрибуты категорий и т. д.
9. дизайн поиска продукта
Подробно схема поиска будет описана в следующей статье. Дизайн поиска включает в себя выбор поисковой системы, дизайн структуры хранения, построение индекса, поиск и общую структуру поиска.
4. Резюме
В этой статье представлен многоуровневый дизайн товарной системы, а также соответствующая функция и функциональный дизайн каждого слоя. В последующем будут подробно представлены точки дизайна и детали в товарной системе, такие как категории и поиск. Кроме того, реализация также включает инкапсуляцию и использование многих промежуточных программ, поэтому общие компоненты (общая структура поиска, структура сообщений) будут представлены позже.
Для получения дополнительных статей, пожалуйста, посетите http://www.apexyun.com/
Общедоступный номер: Galaxy № 1
Контактный адрес электронной почты: public@space-explore.com
(Пожалуйста, не перепечатывайте без разрешения)