Как запросить базу данных MYSQL для извлечения уникального идентификатора

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

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

  • Категория продукта - может быть выбрана только один раз и не является обязательной.
  • Бренд продукта - можно выбрать только один раз и не является обязательным.
  • Цвет - можно выбрать только один раз и не является обязательным.
  • Тире (-) - их можно использовать несколько раз, это необязательно.
  • Точка (.) - их можно использовать несколько раз, это необязательно.
  • Подчеркивание (_) - их можно использовать несколько раз, это необязательно.
  • Уникальный идентификатор - его можно выбрать только один раз, и он является обязательным.

Примеры форматов могут быть

Формат: [категория продукта] [-] [марка продукта] [-] [цвет] [-] [unqiue id] Результат: PHONES-APPLE-GOLD-001

Формат: [уникальный идентификатор] [.] [Бренд продукта] Результат: 001.APPLE

Формат: [марка продукта] [уникальный идентификатор] [цвет] Результат: APPLE001GOLD

Пользователь-администратор также определит код, присвоенный каждому типу детали, например:

Категории

Телефоны = ТЕЛЕФОНЫ Компьютеры = COMP

Бренды

Яблоко = ЯБЛОКО Hewlett-Packard = HP

Цвета

Золото = ЗОЛОТО Желтый = ЖЕЛТЫЙ

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

Использование примера формата [категория продукта] [-] [марка продукта] [-] [цвет] [-] [unqiue id] означало бы, что пользователь увидит 3 раскрывающихся списка:

В раскрывающемся списке категорий они могут выбрать COMP. Из выпадающего списка брендов они могут выбрать HP В раскрывающемся списке цветов они могут выбрать ЗОЛОТО.

Затем они отправят форму и получат код SKU: COMP-HP-GOLD-002.

Вопрос

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

Из-за гибкости, предоставляемой пользователю-администратору при определении формата, это немного затрудняет это.

В приведенном выше примере я, вероятно, использовал бы что-то вроде:

$contructed = $product."-".$brand."-".$color);

$query = $db->query("SELECT (MAX(replace(replace(replace(sku,'".$product."-',''),'".$brand."-',''),'".$color."-',''))+1) as SKU FROM `product` WHERE `sku` LIKE '%".$contructed."%'");

Однако я обманул, предполагая, что все будут использовать этот формат и эти части, а они не будут. Я не учел, что люди будут:

  1. Используйте разные форматы
  2. Используйте разные / не все типы деталей

Единственная гарантия, что у меня есть, это то, что пользователь-администратор всегда будет использовать тип части unqiue ID.

Есть ли у кого-нибудь идеи, как лучше всего справиться с такой гибкостью?

Трудно сделать. Количество администраторов должно быть ограничено и они должны быть очень дисциплинированными, иначе данные очень быстро превратятся в беспорядок. Можно ли определить «главного администратора» для создания новых кодов и утверждения новых значений, чтобы контролировать это?

Nic3500 21.04.2018 19:41

Можно ли определить «главного администратора» для создания новых кодов и утверждения новых значений, чтобы контролировать это? В данный момент нет. Поскольку это не входит в спецификацию. Убивает его гибкость кодов. Если пользователь определяет код бренда 001, то UID также будет заменен в примере, который я привел выше. Я предлагаю ввести в действие правило, согласно которому мы заставляем «главного администратора» использовать значение разделителя до и или после позиции UID в зависимости от того, где они определили позицию UID в последовательности.

BG911 22.04.2018 13:43

Насколько гибкий клиент? Чем гибче спецификации, тем сложнее реализация, а значит, больше долларов на создание и обслуживание. Характеристики продукта не обязательно должны быть встроены в артикул, это просто уникальный номер для идентификации продукта. Если они хранятся в виде столбцов, становится проще искать и строить отчеты. Если SKU, который они хотят, не подлежит поиску, вы можете просто сохранить его, но не запрашивать его. Можно было бы обсудить дальнейший дизайн, но SO ограничен для такого рода углубленных проектных работ.

Nic3500 22.04.2018 16:20
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
1
3
45
0

Другие вопросы по теме