Форум PHP

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

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

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

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

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

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

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

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

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

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

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

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