Такая проблема, в структуре БД у меня есть 30 полей с названиями mater1, mater2, ..., mater30.
Я делаю выборку 1 строчки по primary key - `id`. В этих полях по умолчанию содержатся нули, но могут быть и положительные цифры. Как бы пробежаться по всем этим 30 полям, чтобы это было как можно более эффективно и не грузило сервер и страницу соответственно.
Гробо говоря:


Возможно стоить перестроить структуру БД, потому как выборка производится по этим 30 полям, а они не являются индексами (их 30, а индексов можно сделать 16)

Это сообщение отредактировал(а) Aliance - 10.1.2007, 16:21

Надо LIMIT поставить, чтобы 30 записей вытаскивал.


Это сообщение отредактировал(а) GZep - 10.1.2007, 16:22

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

Это как? Боюсь если я тебя правильно понял, то тогда моя БД не будет удоволетворять 1НФ.

1 НФ тут не при чем.
Скажи для чего эти поля, какие у них значения и как могут изменяться

У меня есть грубо говоря каталог предметов для игры, некоторые предметы характеризируются не только ценой, но и опр. количеством опр. предметов mater1-mater30. Например, предмет нож характеризируется только ценой, а предмет меч характеризируется еще наличием 2 mater10 и 8 mater21. Описание этих mater1-30 содержится в другой таблице. Вот.

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

Aliance, грубо говоря тебе надо отразить как бы для I'той записи принадлежность к ней цифры (предмета) 1, 2 ... 30.
Делаешь поле множеством, впихиваешь туда значения от 1 до 30. И все. Запрос упрощается и работа в сто раз.
http://dev.mysql.com/doc/refman/4.1/en/set.html

При такой постановке задачи, мне кажется, что косяк в структуре БД. ИМХО, надо бы так:

predmet
-id
-opisanie_i_drugie_polya

mater
-id
-opisanie_i_drugie_polya

predmet_mater
-id_predmet
-id_mater
-kolichestvo

Тогда и запросы упростятся и структура прозрачней и понятней будет

Если я все правильно понял, то такая структура базы не очень хороша. Получается, что у тебя большое количество полей в каждой отдельно взятой записи просто не нужны (например, в записи, соответствующей предмету "нож" все 30 полей пустуют). 
В этом случае мне видится два пути:

Вариант 1. Разбить одну таблицу на несколько по сущностям (т.е. отдельно ножи, характеризующиеся только ценой, отдельно мечи, характеризующиеся чем-то еще и т.д.). Это довольно утомительное занятие, если у тебя достаточно большое количество таких сущностей (предметов), т.к. потребует ручной переделки. Данное решение совершенно не годится, если ты хочешь добавлять эти сущности динамически (через админку).

Вариант 2. Сделать две таблицы: "предметы", в которой предметы просто перечисляются (без характеризующих их параметров), и "параметры", в которой хранится список параметров. После чего сделать третью таблицу, которая содержит значение параметра с заданным id для предмета с заданным (но другим, конечно же) id. Плюс данного решения: возможность написания скриптика, который автоматически перельет значения в новую структуру. Минусы: оно более медленное по сравнению с предыдущим...

В качестве примера приведу кусок из одного своего проекта:



Добавлено @ 16:57 
Dremlin, опередил, а я столько писал :-)

Это сообщение отредактировал(а) Bikutoru - 10.1.2007, 17:05

Я не понимаю, чем множество не устраивает? :_

Dremlin, над этим думал, но сомневался. Спасибо. Вопрос такой: в третьей таблице predmet_mater что сделать индексом?

Mal Hack, может быть я туплю, но не вижу вообще как оно тут может пригодится. У каждого предмета либо вообще нет mater, либо их больше 1. Поэтому полей все равно 30 должно быть, а уж какие они будут сильно не влияет на общую логику. В общем решил сделать так, как предложил дремлин.

очень просто...
Смотри есть таблица соответствий
mater1 - 1
mater2 - 2
...
mater3 - 3
Есть таблица с предметами (нож, копье). Есть поле maters в нем, для ножа - пустое множество, для копья множество {1,2}, для другого предмета - свое, т.е. указывается только то, что есть.

Mal Hack, в твоец таблице соответсвий второй столбец - это id?
Проблема в том, что каждого mater может быть по несколько штук. Например в копье 3 - mater1, 2 - mater5, 1 - mater16 и 15 - mater24.

Кстати, сделал как предложил Dremlin, но не понятно, как выброрку сделать. Поясняю:
у меня 4 таблицы: encyclopedia, items, member_items и encyclopedia_items.
Первая - список всех вещей, структура такова: ид вещи, название, характеристики.
Вторая - список всех ингридиентов, структура такова: ид ингридиента, характеристики.
Третья - список вещей у каждого пользователя, структура такова: ид пользователя, ид вещи (связано со второй таблицей), количество.
Четвертая - список вещей требующихся для предмета, структура такова: ид предмета (связано с первой таблицей), ид вещи (связано со второй таблицей), количество.

Как мне узнать, какой пользователь сможет купить вещь определенную? Я знаю ид вещи и хочу проверить, у кого есть необходимые для нее ингридиенты.
Тоесть мне нужно в третьей таблице найти всех пользователей, у который есть нужные мне ингридиенты в нужной кол-ве. Но тут загвоздка, делаю так: выбираю из 3 таблицы всех пользователей, у которых есть нужное количество первого ингридиента UNION тоже самое со вторым UNION и так далее. Но сдесь есть пользователи, у которых есть первый ингридиент, но нет второго, скажем. Если обойтись без объединения запросов, то как?

Работает, но это при условии, что для вещи с ид "известное ид" требуется только 1 ингридиент.

В общем, тупик.

Надеюсь более менее понятно написал, если нет - придется выкладывать дамп БД упрощенный. Буду признателен за помощь.

Первый - индекс предмета.
Второй - множество mater'ов.


Тебе это информация нужна для показа инфы, так? А не для поиска.
Тогда организуй свое множество через строку.
1-5|2-4|30-1
первое число - meter, второе - кол-во.