Форум PHP

Всем привет, столкнулся с проблемой.

В БД в ячейке хранится информация в виде id, обрамленная по сторонам - тире.

Пример:
-5--90--7--18-, т.е. это id каких-то строк, которые я потом вывожу столбиком. Другими словами, есть рецепт, и в этом рецепте есть ингридиенты, которые находятся в другой таблице, и я храню только id этих ингридиентов, а названия их беру из другой таблицы.

Теперь мне понадобилось, менять местами ингридиенты. Т.е. рядом с каждым ингридиентом есть две стрелочки - вверх и вниз.
Допустим, мне нужно поменять местами второй(-90-) и третий(-7-) ингридиент местами, так чтобы третий встал на место второго, а второй на место третьего и получилось так: -5--7--90--18-
Т.е. в данный момент я жду на второй(-90-) ингридиент и на его стрелочку вниз, он опускается, а на его место забирается третий(-7-) ингридиент и становится вторым.

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

Не могу понять, как запрограммировать процесс, кто что посоветует?
Заранее спасибо!

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

Так я наверно запутал просто, у меня так и есть.
В одной таблице у какой-то строчки, в одной ячейке списком хранятся id-ингридиентов из другой таблицы.
А вопрос в том, как менять местами список. Тут и БД не причём, тут чисто решение на php нужно... сам алгоритм действий, до которого не могу никак дойти...

Если у Вас так и есть - у Вас никогда не будет в таблице ячейки с таким безобразием внутри.
Решение на php имеет смысл, когда исправлены ошибки в структуре хранения.

Могу ещё проще показать, что нужно:

Есть массив, нужно поменять первый и второй элементы массива:

Array (     [0] => 1     [1] => 2     [2] => 3     [3] => 4     [4] => 5 )

чтобы было так:

Array (     [0] => 1     [1] => 3     [2] => 2     [3] => 4     [4] => 5 )

Как так сделать?

p.s. Такую структуру я нацеленно делал, т.ч. лучше обсудить как решить мою проблему, а не мои "ошибки" в структуре :)

>p.s. Такую структуру я нацеленно делал, т.ч. лучше обсудить как решить мою проблему, а не мои "ошибки" в структуре :)

Вот и формулировали бы сразу проблему без чуши напоказ. Намеренной или нечаянной чуши - не столь важно.

$temp = $x[1], $x[1] = $x[2]; $x[2] = $temp;
Есть трюки без временной переменной, но они Вам скорее навредят.

Чуши напоказ не было, старался разъяснить как можно понятнее :) Сорри.

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

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

[поправлено модератором]

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

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

Ну у меня же они и связаны "раздельно". В одной хранится вся инфа. А в другой, есть какой-то элемент, в ячейке которого хранится список id нужный ему.

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

Спасибо за разъяснение. Но я люблю учиться на своих ошибках, только тогда, когда получу по "голове", иначе - для меня все убеждения не убедительны. Но в Ваших словах есть правда. Но просто проект почти дописан, сейчас идёт его "обрастание" функциями. Да, работать с кодом сложнее, чем если бы было всё через БД сделано. Но чисто, ради проверки - уж доделаю всё как планировал, а если будет видно, что действительно ресурсы кушаются и всё еле двигается, то переделаю :)

Если бы Вы еще и ошибки отрабатывали на кошках, а не на людях на учебных задачах, а не на реальных проектах...

Задача - есть задача, с помощью неё можно получить поверхностное восприятие. А когда всё работает в реальности, то можно после этого точно говорить, сколько посетителей проект выдерживает без напряга, когда начал затухать, и когда вообще "потух". Вместе с этим, можно что-то менять в скрипте или структуре БД, и смотреть, что будет. Именно так можно понять, что именно тормозит проект. А делать "просчитываемые логикой" догадки, что это будет тормозить и всё загнется - можно, но когда есть возможность по-экспериментировать, то хочется ей воспользоваться. Другое дело, что если бы начинал с нуля, то может не стал бы делать такие эксперименты, когда говорят, то что это плохо. Ну а когда дело почти сделано, то можно и рискнуть :) Спасибо за заботу :)