Форум MySQL

Такая проблема.
Есть например запись клиента, и я хочу в одном поле записать ряд ID категорий товаров которыми он торгует, скажем -10-57-49-86-32- и выбирать $id LIKE %-$id-% по каждой конкретной группе
или 10,57,49,86,32 и выбирать $id LIKE %$id,%

как можно выбрать скажем 10 и 49 если послать $id=5, 25, 10, 49, 22 ???

то есть как сделать чтобы база данных вопспринимала переданную строку $id=5, 25, 10, 49, 22
как WHERE Category LIKE '%5,%' OR LIKE '%25,%' OR LIKE '%10,%' ... и т.д.

я хочу в одном поле записать ряд ID
Это что дело принципа?
не делайте этого, не создавайте себе проблем, лучше потратьте силы и время на грамотное проектирование таблиц базы данных.

а как вы посоветуете?
если сделать поле с названием скажем магазина, и по его ID связать с записями в другой таблице, где просто будут лежать ID всех категорий
1 - 25
1 - 98
это будет как то накладно для БД мне кажется ...

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

как тут быть?

ауууууууууууу
дайте плиз совет а то горю ((((

Я бы лично дал вам какой-нибуть совет, но непонятно что советовать.
Но влюбом случае, если вы засунете в одно поле несколько значений... проблематично будет работать с ними средствами СУБД. Где-нить ваш LIKE ошибётся и клиет получит вантуз вместо зубной щётки)
Есть id товара и сам товар это понятно
напишите какие остальные таблицы есть, какие поля они содержат и что из чего вы собираетесь выбирать (и вообще какая задача перед вами стоит)

дело вот в чем, есть таблица двухуровневых категорий
типа

М. обувь - сапоги
а1-б1
М. обувь - туфли
а1-б2
...
...

то есть а1 - Мужска обувь, а б1, б2, б3 .... это все ее разновидности

а2 - женская обувь, а3 мужская одежда и так далее

и я это все могу группировать как хочу в виртуальную группу, например мужская мода а1, а3

или просто обувь - а1, а2

так вот, когда я формирую виртуальные группы, выборку делаю по товарам $ID=1,2,3,4,5, ...
в поле товаров стоит только один идентификатор, и можно выгребать какие угодня комбинации используя IN (1,2,3,4,5 ....)

НО !!! у каждого товара есть продавец, и продавец тоже имеет классификатор по айдишникам первого уровня типа а1, но не один классификатор, так как он может либо продавать только мужскую обувь, либо и мужскую и женскую еще и одежду, то есть ему кудато нужно добавить четыре айдишника этих рубрик...

и если клиенты будут выбирать только женскую обувь а2, я сделаю запрос Like, а если клиенты будут выбирать по всей обуви, $ID=1,2 то мне нужно выбрать у какого продавца есть 1 и 2 айдишник

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

а создавать гдето по двадцать полей для каждого клиента и перекапывать всю базу наверное накладнее будет ....

вот и думаю что делать ...

Ну если у вас перечесление значений в переменной id через запятую, то
SELECT * FROM table WHERE Category IN('$id')

Этот запрос сделает выборку всех строк содержащих данные айдй... а автор хочет засунуть их в одно поле и юзать LIKE

проблема в том, что LIKE '%5,%' выберет и 5 и 25 если не ошибаюсь.... а это вантуз)))
может так прокатит LIKE '%,5,%', а в поле хранить ,5,19,43,

идеально бы было
SELECT * FROM table WHERE Category IN (1,2,3,4,5,6,7,8,9,10)
где поле Category содержало скажем 14,1,2,25,3,5,
и выбиралось наличие этих значений, но так же не работает

если я выбираю из 10000 записей, юзается только одна таблица ...
если к каждой записи будет еще по 20-30 записей в другой таблице категорий?
на сколько быстро это все будет работать?

Вы пробовали?

Сегодня прочитал про тип данных SET но так и не понял что такое максимальный размер 64 элемента. Но мне кажется он тоже не подойдёт, так как там могут присутствовать только значения из заранее заданного множества, а товар - вещь непостоянная.

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

Это означает, что список SET может состоять максимум из 64 элементов - больше не получится (в этом случае придется отдельную таблицу реализовывать).

спасибо, сейчас буду пробывать

А один элемент сколько может занимать символов?

в смысле?
категорий?
скажем один магазин в каталоге может быть сразу в 40-60 категориях
то есть для него в таблице категорий нужно будет создавать 40-60 полей
и выборка будет по 1, по 2, по 10, по 30 категория присутствующим в этих всех 60

Магазин, у магазина перечислены только категории. Так зачем 40-60 полей под каждую категорию? Достаточно одного поля, в котором и храните записи категорий. Или еще и товары у категорий?

товары разбиты на категории, а их много категорий то ...
и к каждому магазину нужно прикручивать минимум по 20 категорий
чтобы если пользователь, например интересующийся Мужской обувью, ID 40, мог сделать запрос на магазины которые продают мужскую обувь
если заводить категорию обобщенную Обувь или Одежда , это не прокатывает в нашем случае
так что приходится иметь дело с очень подробными категориями

вот сделал пример

в таблице brand бренды
в таблице brand_cat - связь ID бренда с таблицы brand и категории

задаем запрос по поиску в трех категориях 2, 26, 5

Показывает записи 0 - 19 (20 всего, Запрос занял 0.0034 сек)
SQL-запрос:
SELECT * FROM brand WHERE Brand_ID IN ( SELECT DISTINCT BC_BrandID FROM brand_cat WHERE BC_BrandCatID IN ( 2, 26, 5 ) )

в таблице brand 448 записей, в таблице brand_cat записей 93 для 30 записей с таблицы brand
запрос занял 0.0034 сек
это не много?
что будет если так юзать по полной программе?

может как то блин это упростить можно? а?

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

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