как интерпретировать результат запроса как имя таблицы для выборка mysql

Доброго времени суток.

есть 3 таблицы: t_index, t1, t2
структура t1 и t2 не существенна
t_index имеет 2 поля - ID и t_name
в t_name содержится имя таблицы в которой находится информация о ID
(например id=1, t_name=t1; id=2, t_name=t1; id=3, t_name=t2)
задача - создать представление (VIEW) которое будет отображать следующее: (синтаксис не верен, но суть думаю будет ясна)
SELECT * FROM t_index.t_name WHERE t_index.t_name=t_index.ID
или
SELECT * FROM (SELECT t_name FROM t_index) WHERE t_index.ID=ИМЯ ТАБЛИЦЫ ДЛЯ ВЫБОРКИ(t1 или t2).ID

т.е. значение поля t_name должно служить именем таблицы для выборки результатов

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

Зато на php это все можно реализовать в три секунды. Делаешь запрос в t_index, выясняешь имя таблицы и записываешь его, например, в переменную $table_name. А потом делаешь как-нибудь так:

явно беда с архитектурой бд
как вариант

[quote=MAXUS][quote]Зато на php это все можно реализовать в три секунды.
[/quote]
на пхп да, но нужно mysql
[quote=MAXUS]

структура не совпадает, каждой категории товаров соответствует своя таблица


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

http://forum.php.su/topic.php?fo...8&topic=5211

когда нормально такие извраты не требуются




за такую нормальность руки разрабам надо выдергивать

меняйте Mysql на какой нибудь промышленный сервер Бд если уж хочется такие
заморочки делать

(Отредактировано автором: 20 Октября, 2013 - 14:20:24)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

это печально.. когда на первый взгляд простая задача называется извратом.
Уверен в мускуле есть возможность решить по простому данную задачу

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

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

только по приведенной тобой причине конечно не стоит
а вот поняв недостатки своей структуры изменить ее стоит(не обязательно переписывать все и сразу)
иначе такие проблемы будут возникать при каждом изменении/добавлении функционала
а никто свое и не предложил
была предложена ссылка для ознакомления с более "нормальными" вариантами
таблица для каждой категории это определенно тупик

Не. Реально что-то не правильно. Таблица свойств товаров должна быть универсальной и храниться, например, в таком виде:

id_товара, имя_свойства, значение_свойства.

Просто делаешь выборку по этой таблице и все в соответствии с id. И все остальное по этому принципу. Если надо, заводишь еще таблицу

класс_товара, имя_свойства

В нее заносишь шаблоны и если товару назначен какой-то класс, то пользователю предлагается только свойства, которые присутствуют в классе.
(Добавление)


Если php вообще не используется, то не подходит. А если используется, то никаких веских причин, чтобы этот вариант не подходил, я не вижу.
(Добавление)


Судя по всему нет. Поэтому говорят о том, что структура не правильная. А задача - изврат, потому что есть масса способов решить первоначальную задачу (создание каталога товаров) более простыми способами, не упираясь в одно единственное решение, которое реализовать без изврата не получится (а скорее всего совсем не получится).

изврат не задача а ее решение

а на товары у тебя тоже генерится таблица на каждый товар?


сомневаюсь что даже по сложному ее можно решить. В мускуле весьма слабо развит SQL. Преимущество mysql - это простота и большая скорость выборки на простых запросах.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Спасибо конечно всем за советы, но мы отходим от темы....


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

не бывает столько категорий

не бывает столько свойств


это тупик независимо от количества категорий


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

и кстати большая нагрузка как раз говорит в пользу одной таблицы категорий
а не нескольких.
(Добавление)

тема нереализуема - кроме как отходить ничего не остается
(Добавление)
подставляй таблицу в PHP как написали выше
все равно VIEW не имеет смысла при такой архитектуре

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

действительно а какой смысл в VIEW
если категорий тысачы то вьюх будет мириады))
(Добавление)
и еще
если категорий тысячи то товаров в каждой пара десятков или что-то около того
иначе это какой-то АШАН или типа того
или даже того гораздо более
зависит от товаров
тогда имеет смысл эти таблицы-категории вообще хранить в пых-массивах