Перебор и замена данных в многомерном массиве?

Сергей Семенко: Сергей, отличный вариант! А подскажите как быть если мы не можем callback прописывать в array_walk_recursive. Предположим это это функция некого класса, как тогда быть при таком подходе?

Перебор и замена данных в многомерном массиве?

Евгений Вольф: Извините, но немного не понял о чем вы. Про "извлечение" или уже про "замену"?

Перебор и замена данных в многомерном массиве?

Сергей Семенко:

$logos = [
		"logo_3_1" => "L31",
		"logo_4_1" => "L41",
	];

Перебор и замена данных в многомерном массиве?

function arrayIterator(&$element, $key)
{
global $logos;

if ($logos[$element]) {
$element = $logos[$element];
};
}

Где "arrayIterator" callback для array_walk_recursive решает проблему с подменой. Но соответствует ли он варианту хорошего решения, для меня вопрос)

Перебор и замена данных в многомерном массиве?

Благодарю за вариант.

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

К примеру logo_3_1 у нас будет /upload/section/random_id.png
Вот как используя ваш подход в array_walk_recursive передать массив содержащий те самые /upload/section/random_id.png.

Перебор и замена данных в многомерном массиве?

Вы рекомендуете использовать ее и для выборки и для последующей замены? Рекурсивно вызывая ее же для "углубления"?

MySQL выборка, что быстрее?

Слава Витренко: Ориентировочно назвать тяжело, но размер со временем должен быть приличный.

MySQL выборка, что быстрее?

Илья Зенин: В принципе на этой почве и появились разногласия. Вносить ли флаг привязки в основную таблицу с пользователями или выносить всю связь в отдельную таблицу. По сути не хотелось бы "засорять" таблицу пользователя, скажем так "свойствами", которые не присущи самому пользователю как сущности. Лучше вынести это в отдельную таблицу и там сохранять все эти связи, что я полагаю и имел ввиду пользователь Alex. Но данный вариант будет более рационален если будет реализовываться функционал описанный пользователем Rsa97 , т.е. при множественном варианте различных способов рассылки. По сути тогда нам надо будет всего лишь отфильтровать эту таблицу по необходимому типу рассылки, получить массив ID пользователь и потом уже на основании него сделать выборку из таблицы пользователей. А так в принципе есть это поле будет одно то наверное нет смысле выносить все в отдельную таблицу.

MySQL выборка, что быстрее?

Благодарю! Примерно к такому рассуждению самостоятельно и пришли, что второй вариант будет лучше если будет N - количество способов рассылки и чтобы не "замусоривать" таблицу с пользователями то разумнее все вынести в другую таблицу. Тут мы скорее получаем "архитектурный" выигрыш от того что у нас все будет более логично структурировано, а так же мы будет придерживать правил нормализации.
Но проигрываем в производительности выборки. Правильно ли я рассудил?

MySQL выборка, что быстрее?

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

MySQL выборка, что быстрее?

Благодарю за ответ. Получается лучше "расширять" таблицу с пользователя, вводя новые поля для расширения сущности пользователя?

MySQL выборка, что быстрее?

Благодарю за ответ. Ну к примеру потом надо будет добавить еще признак привязки подписки на email или еще как-нибудь расширить сущность пользователя. Для этого нам придется менять структуру таблицы. А так мы не меняя основную таблицу через связь можем расширять сущность пользователя. Как быть в данной ситуации?