Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: как интерпретировать результат запроса как имя таблицы для выборка mysql
Форумы портала PHP.SU » PHP » SQL и Архитектура БД » как интерпретировать результат запроса как имя таблицы для выборка mysql

Страниц (2): [1] 2 »
 

1. Артком - 20 Октября, 2013 - 11:54:03 - перейти к сообщению
Доброго времени суток.

есть 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 должно служить именем таблицы для выборки результатов
2. MAXUS - 20 Октября, 2013 - 13:00:43 - перейти к сообщению
Цитата:
т.е. значение поля t_name должно служить именем таблицы для выборки результатов


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

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

PHP:
скопировать код в буфер обмена
  1. $query="SELECT * FROM {$table_name}";


И запускаешь этот запрос из php.
(Добавление)
А если у тебя структура t1 и t2, вдруг, совпадает, то тогда проще это все держать в одной таблице и ввести дополнительное поле, по которому будешь различать информацию t1 от t2. Хотя, скорее всего, у тебя структура не совпадает, поэтому это я на всякий случай...
3. LIME - 20 Октября, 2013 - 13:22:08 - перейти к сообщению
явно беда с архитектурой бд
как вариант
CODE (SQL):
скопировать код в буфер обмена
  1. SELECT * FROM t1
  2. JOIN t_index ON t1.id = t_index.ID AND t_index.t_name='t1'
  3. UNION
  4. SELECT * FROM t2
  5. JOIN t_index ON t2.id = t_index.ID AND t_index.t_name='t2'

(Добавление)
только надо привести поля к одному виду и именам
4. Артком - 20 Октября, 2013 - 13:37:50 - перейти к сообщению
[quote=MAXUS][quote]Зато на php это все можно реализовать в три секунды.
[/quote]
на пхп да, но нужно mysql
[quote=MAXUS]
Цитата:

(Добавление)
Хотя, скорее всего, у тебя структура не совпадает, поэтому это я на всякий случай...


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

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

нормально все с этим, там масса других нюансов почему надо так а не иначе
Увы, Ваш вариант не подходит т.к. таблиц на самом деле N и добавляются они динамически, а имена заранее неизвестны. поэтому инфа о том какой товар лежит в какой таблице хранится в "индексной" таблице
5. LIME - 20 Октября, 2013 - 13:46:36 - перейти к сообщению
Артком пишет:
каждой категории товаров соответствует своя таблица

http://forum.php.su/topic.php?fo...8&topic=5211
6. caballero - 20 Октября, 2013 - 14:08:27 - перейти к сообщению
Цитата:
нормально все с этим,

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

Цитата:
таблиц на самом деле N и добавляются они динамически

Цитата:
каждой категории товаров соответствует своя таблица


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

меняйте Mysql на какой нибудь промышленный сервер Бд если уж хочется такие
заморочки делать
7. Артком - 20 Октября, 2013 - 14:12:50 - перейти к сообщению
caballero пишет:
Цитата:
нормально все с этим,

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

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


это печально.. когда на первый взгляд простая задача называется извратом.
Уверен в мускуле есть возможность решить по простому данную задачу
8. LIME - 20 Октября, 2013 - 14:43:24 - перейти к сообщению
Артком пишет:
Уверен в мускуле есть возможность решить по простому данную задачу
какие есть основания для такой уверенности?
твой способ это именно изврат
классический причем
посмотри все же ссылку выше
там как-раз люди предлагают более "нормальные" решения
9. Артком - 20 Октября, 2013 - 14:52:03 - перейти к сообщению
LIME пишет:
Артком пишет:
Уверен в мускуле есть возможность решить по простому данную задачу
какие есть основания для такой уверенности?
твой способ это именно изврат
классический причем
посмотри все же ссылку выше
там как-раз люди предлагают более "нормальные" решения


Ребята, вопрос не в том, зачем и почему мне это нужно, а как это сделать. Ничего сверх естественного в том, что имена таблиц, где хранятся данные, находятся в другой таблице не вижу. Никто не будет менять структуру приложения, имеющего большой объем данных и активно используемого только потому, что кто то называет какие то способы извратом и предлагает свое Улыбка как обойти задачу и решить через пхп - подсказывать не надо, все элементарно. Тут скорее ради своего развития интересно, можно ли решить средствами БД
10. LIME - 20 Октября, 2013 - 14:59:45 - перейти к сообщению
Артком пишет:
Никто не будет менять структуру приложения, имеющего большой объем данных и активно используемого только потому, что кто то называет какие то способы извратом и предлагает свое
только по приведенной тобой причине конечно не стоит
а вот поняв недостатки своей структуры изменить ее стоит(не обязательно переписывать все и сразу)
иначе такие проблемы будут возникать при каждом изменении/добавлении функционала
Артком пишет:
и предлагает свое
а никто свое и не предложил
была предложена ссылка для ознакомления с более "нормальными" вариантами
таблица для каждой категории это определенно тупик
11. MAXUS - 20 Октября, 2013 - 15:19:55 - перейти к сообщению
Цитата:
явно беда с архитектурой бд

Цитата:
нормально все с этим


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

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

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

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

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

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


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


Судя по всему нет. Поэтому говорят о том, что структура не правильная. А задача - изврат, потому что есть масса способов решить первоначальную задачу (создание каталога товаров) более простыми способами, не упираясь в одно единственное решение, которое реализовать без изврата не получится (а скорее всего совсем не получится).
12. caballero - 20 Октября, 2013 - 15:34:01 - перейти к сообщению
Цитата:
когда на первый взгляд простая задача называется извратом

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

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

Цитата:
Уверен в мускуле есть возможность решить по простому данную задачу

сомневаюсь что даже по сложному ее можно решить. В мускуле весьма слабо развит SQL. Преимущество mysql - это простота и большая скорость выборки на простых запросах.
13. Артком - 20 Октября, 2013 - 15:35:04 - перейти к сообщению
Спасибо конечно всем за советы, но мы отходим от темы....


п.с. нагрузка на БД в несколько терабайт трафика/мес. и поверте, если мы имеем тысячи категорий и у каждой по несколько сотен свойств- решение хранить в отдельных таблицах никак не тупик. Но тема не об этом
14. caballero - 20 Октября, 2013 - 15:59:26 - перейти к сообщению
Цитата:
если мы имеем тысячи категорий

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

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

Цитата:
решение хранить в отдельных таблицах никак не тупик

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

Цитата:
нагрузка на БД в несколько терабайт трафика/мес

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

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

тема нереализуема - кроме как отходить ничего не остается
(Добавление)
подставляй таблицу в PHP как написали выше
все равно VIEW не имеет смысла при такой архитектуре
15. LIME - 20 Октября, 2013 - 16:04:23 - перейти к сообщению
действительно а какой смысл в VIEW
если категорий тысачы то вьюх будет мириады))
(Добавление)
и еще
если категорий тысячи то товаров в каждой пара десятков или что-то около того
иначе это какой-то АШАН или типа того
или даже того гораздо более
зависит от товаров
тогда имеет смысл эти таблицы-категории вообще хранить в пых-массивах

 

Powered by ExBB FM 1.0 RC1