Я создаю функцию, позволяющую пользователю с правами администратора создавать собственный формат кода 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."%'");
Однако я обманул, предполагая, что все будут использовать этот формат и эти части, а они не будут. Я не учел, что люди будут:
Единственная гарантия, что у меня есть, это то, что пользователь-администратор всегда будет использовать тип части unqiue ID.
Есть ли у кого-нибудь идеи, как лучше всего справиться с такой гибкостью?
Можно ли определить «главного администратора» для создания новых кодов и утверждения новых значений, чтобы контролировать это? В данный момент нет. Поскольку это не входит в спецификацию. Убивает его гибкость кодов. Если пользователь определяет код бренда 001, то UID также будет заменен в примере, который я привел выше. Я предлагаю ввести в действие правило, согласно которому мы заставляем «главного администратора» использовать значение разделителя до и или после позиции UID в зависимости от того, где они определили позицию UID в последовательности.
Насколько гибкий клиент? Чем гибче спецификации, тем сложнее реализация, а значит, больше долларов на создание и обслуживание. Характеристики продукта не обязательно должны быть встроены в артикул, это просто уникальный номер для идентификации продукта. Если они хранятся в виде столбцов, становится проще искать и строить отчеты. Если SKU, который они хотят, не подлежит поиску, вы можете просто сохранить его, но не запрашивать его. Можно было бы обсудить дальнейший дизайн, но SO ограничен для такого рода углубленных проектных работ.






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