Hettin_array - затратная операция на больших объемах данных, но никто не мешает обращаться по индексу, в качестве которого можно использовать id сущности.
Конкретно по вашему примеру, - будет проще сделать JOINы

Возможно автору и проще будет собрать JOINы, но лично я вижу задачу очень нетривиальной. А самая изюминка в том, что MySQL не поддерживает FULL JOIN

Можно было бы имитировать его через UNION, но их же там до 14 в одном запросе возможно. Даже не представляю, как это с UNION собрать.

Мне видится что-то такое:



Давно на чистом SQL запросы не писал, возможно по синтаксису ошибки посыпятся ) Но все остальные "сборки" запроса меня жутко пугают сложностью и массивностью (хотя признаюсь, такой вариант при 15-ти таблицах тоже громоздкий очень)

Как по мне на пхп проще...
foreach для каждой из 15 выборок. Так собираем массив $res[$range]['val'.$tableNum] = $value;

потом ksort,

а при обращение к значениям делаем так isset($res[$range][$valName]) ? $res[$range][$valName] : NULL;

Алексей ДаниловПрограмёрА самая изюминка в том, что MySQL не поддерживает FULL JOIN


Вот на этом я и встал. Но зато Вы предложили value as NULL - спасибо! сам не додумался :(
Учитывая, что сегодня приняли решение, что количество выборок всегда будет кратно трём, так что, скорее всего, я скомбинирую оба подхода, т.е. буду делать тройки через UNION, а затем через isset их объединять. Пока непонятно, насколько громоздко будет выглядеть.

Имеет право на жизнь. Но оценим плюсы и минусы "гибридного" подхода.
Плюсы:
1. Это сократит количество итераций foreach втрое (в найлучшем случае)
2. Это сократит количество запросов втрое

Минусы:
1. Громоздкость запросов и их сложная читабельность
2. EXPLAIN по такой выборке даже для двух таблиц выглядит пугающе (для меня). То есть отладка и оптимизация усложняется в разы
3. При использовании подхода на ПХП мы можем каждому запросу присвоить номер и использовать его при нумерации value. В "гибридном" подходе потребуются дополнительные операции
4. Не смотря на уменьшение количество итераций, количество присвоений не изменится. То есть кода больше, а пользы 0.
5. Когда заказчик скажет "Ну да, тогда было кратно трём, но сейчас у нас 4 устройства в системе, а потому и выборки кратны четырём", не придётся писать ни буковки кода в отличие от "гибридного" варианта.



В моём понимании минусы более значимые получились чем плюсы (иначе при такой сильной погоне за скоростью, выбор бы не пал на пхп). Моё мнение, лучше перенести всю логику по слиянию таблиц на пхп. :)