HTML+CSS+JavaScript

>А на стороне сервера принимать это массив, удалить повторяющиеся элементы массива и подставить данные в запрос

Оригинально, имеем список значений: 1, 78, 20, 189 и при этом на сервере нужно удалить повторяющиеся элементы! Это какие и из чего они у вас появились?

>Тут придется писать реруксию, либо вложенный SELECT, что Вы думаете об этом?

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

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

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

Возникла вот такая идея:
В таблице cars у меня есть поля:

Transmission Control Petrol Marka Model
В каждом поле храниться уникальное число, определяющее TITLE из другой таблице по связи

cars.Petrol = table2.id, где Table2.id

уникальный идентификатор.

ID         TITLE 1           Легковые 78         Бензин 20         Toyota 189       E-678

Идея в том, чтобы на стороне клиента сформировать список Select из всех накликанных ссылок, т-е SELECT примет вид:

<option value="1"></option> <option value="78"></option> <option value="20"></option> <option value="189"></option>

А на стороне сервера принимать это массив, удалить повторяющиеся элементы массива и подставить данные в запрос, для определенных полей Transmission Control Petrol Marka Model

SELECT * from Cars WHERE Transmission Control Petrol Marka Model IN(1,78,20,189)

_______________________________________________________________________
Как вариант искать и снизить нагрузку на базу такая:

1) Отсортировать полученный массив в порядке возрастания
2) Взять первый элемент массива и выполнить запрос:

SELECT * from Cars WHERE Control = 189 OR Pertol = 189 OR Marka = 189 OR Model = 189.

3) Если запрос выполнится, то для

следующего запроса

с числом 78, мы отсекам одно поле, результат которого от первого запроса, т-е если 189 было найдено в Marka, то следующий запрос примет вид:

SELECT * from Cars WHERE Control = 189 OR Pertol = 189  OR Model = 189.

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

Тут придется писать реруксию, либо вложенный SELECT, что Вы думаете об этом?

Вариант, когда Тоейета, Мазда, Хонда, Камаз..., это один набор, а седан, кабриолет, джип, грузовик, это другой связанный с первым набор, и при этом в каждом наборе можно выбрать по одному варианту, многократно описан выше. И это описание базировалось на ваших словах и ссылке вами представленной. И если именно к такой задаче вы желаете "прикрутить" список со множественным выбором, то этот элемент в данном случае совсем не походит.

Что вам на самом деле надо мне не известно, поэтому о каких вариантах и для чего может идти речь? Можно и мультисписок, можно и иное решение, можно много решений применить, но зная исходное.

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

Немного истории. В далекие времена, когда зарождались железяки именующиеся компьютерами, их разработчики уже понимали, что это необычные железки, а программные. Такая железяка могла служить для выполнения любого каприза хозяина, и поэтому снабдили ее портами, к которым хозяин мог подключать свои капризы. А чтобы понимать эти капризы хозяина, разработчики придумали прерывания.

По меркам того времени железяка получилась вполне не плохая, но без мозгов она бы так и осталась железякой. Но бог послал чародеев и кудесников, которые с этой задачей справились, как то чародея Стива Возняка и кудесника Билла, и родили они дочек, назвав их операционными системами. Хотя первая дочка Билла была скорее падчерицей ему, тем не менее он вложил в нее свои семена. Родители ОС прекрасно понимали выгоду портов и прерываний в железяке, и снабдили свои ОС еще и программными прерываниями. "Зашибись!" - воскликнул Билл в конце работы, потирая руки, и понимая аппаратные и материальные выгоды такого решения. Именно с тех пор и храниться в Национальном музее США документ известный как "Билл о правах", на котором русский турист (любитель писать на заборах) дописал мелом - "на PS-DOS 1.0", но это уже новейшая история.

Выгоды

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

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

Кроме такой "вольности" существуют и соглашения, например, в клавиатуре есть набор стандартных клавиш, которые ОС будет понимать с драйвером по умолчанию, а все что свыше этого набора, можно только со специальным драйвером. Существуют соглашения и по прерываниям, когда некие из них, по умолчанию, отданы (не значит что на вечно, просто так сложилось исторически) за некими стандартными устройствами.

И при всем при этом разнообразии разработчику ПО совсем не обязательно знать адреса векторов, ему достаточно знать их номера, как-то INT 20, INT 21... А уж, если писать ПО на языках "человеческого понимания", то он может вообще даже и не подозревать об этих номерах, как и векторах прерываний вообще.

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

И к чему тут прерывания, если мне нужна Тойета грузовик?

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

Сопоставим вашу задачу с компьютером ничего не знающем о прерываниях:
а) форма - это внешнее устройство;
б) программа принимающая форму - это центральный процессор;
в) база данных - это конечное устройство, к которому обращается внешнее устройство.

Не мудрствуя лукаво, вы зашили во внешнее устройство команду "Тойета" для центрального процессора, который снабдили макро-операциями для этой команды, а оконечное устройство научили выдавать результат этой команды. Все бы ничего, но завтра вам потребовалась команда "Хонда". Пришлось зашивать во внешнее устройство новую команду, процессору определять макро-операции для нее, а оконечное устройство выдавать новые данные.

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

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

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

И как это работает?

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

Если уже на данном этапе имеется несколько страниц, с которых предполагается отправка формы, а тем более, если страницы с подобными формами будут добавляться в будущем, то иметь обработчики по векторам как массив описывающий их, это означает, что при каждом добавлении страницы придется править код - перепрошивать процессор. Следовательно, вектора обработчиков (id страниц) лучше хранить в базе, под которыми и будут описываться параметры обработчиков. Тогда, добавляя новую страницу, достаточно в такой таблице описать параметры драйвера обработчика ее формы, учитывая соглашения по адресации.

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

Финита

Не гоните лошадь, вы не на скачках, на вас ставку никто не делал, и прийти первым не значит еще выиграть. Лучше остановиться и подумать как прийти к финишу с наименьшими затратами сена, по кратчайшему пути. А когда свяжите воедино все, определитесь с тем, что необходимо для этого, что будет более оптимальным, родите хотя бы "эскизы" своих устройств логически связанных с оконечными, с драйверами обработки их, тогда, и только тогда, можно будет говорить предметно - о внешних устройствах ваших (формах) в этом разделе, и о драйверах для них в соответствующем разделе. А данная тема, это только как предложение подумать "как...", и как показывает ее русло, совсем не базируется на требуемом.

В этом и проблема. Какие варианты?

И каким образом будут определятся в нем значения, если Тойета и грузовик?

А как же быть для

multiple="multiple"

?

Индексы равны 0 потому, что скопировал, а не подправил. Я вам уже тут целую повесть написал и все об одном и том же, и выше есть пример, где все правильно, можно было бы и догадаться, что я просто ошибся, от усталости. Отправьте эту форму и смотрите.

<? if($_GET) {    print_r($_GET); //соответствуют индексы массива вашим 38 и 90?    $ids = array_map('intval', $_GET['ids']);    if(!array_intersect($ids, array(0))) { //не дурят, работаем       $sql = 'SELECT * FROM table WHERE ';       //это так только в примере, а вообще массив этих параметров       //можно описать загодя, как настройки, и подключать его здесь        $link = array('fields'=>array('mark='.$ids[0], 'type='.$ids[1]));       $sql .= implode(' AND ', $link['fields']);       echo $sql; //смотрим результат       //ну как, соответствуют в итоге ваши цифры вашим именам?     } } ?> <form> <!--  Если для вас это такая трудность, то будем ссылаться на список,  который определяет марку как mid, по первому символу от слова mark и он у нас в форме первый, а значит его индекс в GET массиве будет равен 0 -->  <select id="mid" name="ids[]">  <option value="38" selected>38</option>  <option value="19">19</option> </select> <!--  а на список, который определяет тип tid, соответственно первому символу от слова type и он у нас в форме второй, а значит его индекс в GET массиве будет равен 1 --> <select id="tid" name="ids[]">  <option value="90" selected>90</option>  <option value="34">34</option>  </select> <input type="submit" value="Send" /> </form>

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

Давайте так..

Есть 2 скрытых списка (поиск по 2-м критериям):

1) По марке авто

<select id=mid name=ids[]> <option value="38"></option> <option value="19"></option> ....

</select>

2) По модели авто

<select id=pid name=ids[]> <option value="90"></option> <option value="34"></option> </select>

У обоих элементов name=ids[], т-е на сервер полетит массив ids (сформированный из selected элементов списка), массив будет одномерный.

_________
На странице есть ссылки выбора (критерии выбора), по клику на которые, как мы уже установили выше - делается select по индексам. Т-е по клику в двух списках происходит выборка тех элементов option, которые полетят на сервер как элементы массива ids.

_________________
Как теперь на сервере обработать этот массив и установить взаимосвязь, т-е что 38 и 19 это относится к марке авто, а 90 и 34 - к модели авто..
Т-е как формируется массив

fields=>array('mark='.$ids[0], 'type='.$ids[0])

мне не ясно..и почему индексы 0?

А пример на сервер я для чего вам писал?
Если вы знаете, что первый список определяет марку, а второй тип, и при этом марке соответствует имя поля mark в таблице, а тип это имя поля auto, и с данной страницы при этом вы запрашиваете только марку и тип, то велика ли трудность это прописать для примера выше:
fields=>array('mark='.$ids[0], 'type='.$ids[0]) ?
А 10 и 12, это id значения соответственно, которые позволят выбрать именно Тойету и грузовик. Вы что-то путаете котлеты с мухами.
Назовите хоть "чертом", но описать соответствия одного другому, какая может быть трудность в этом?

<select id=mid name=ids[]> и <select id=pid name=ids[]>

И вот тут я тоже задавал вопрос - получается что 2 select c одинаковым именем - это и есть один select с таким именем, и как потом его на стороне сервера обработать?
Как определить из массива что array(cat=1, ids=array(10,12))

10 это марка автомобиля Toyota а 12 это уже тип авто (грузовик)