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
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: как интерпретировать результат запроса как имя таблицы для выборка mysql
Покинул форум
Сообщений всего: 35
Дата рег-ции: Июль 2010
Помог: 1 раз(а)
[+]
Доброго времени суток.
есть 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 должно служить именем таблицы для выборки результатов
MAXUS
Отправлено: 20 Октября, 2013 - 13:00:43
Посетитель
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
Цитата:
т.е. значение поля t_name должно служить именем таблицы для выборки результатов
Если не ошибаюсь, в MYSQL подставить переменное значение вместо имени таблицы или колонки можно только используя пользовательские переменные или подготовленные выражения, но они живут только пока живет сессия, что исключает их использование во VIEW.
Зато на php это все можно реализовать в три секунды. Делаешь запрос в t_index, выясняешь имя таблицы и записываешь его, например, в переменную $table_name. А потом делаешь как-нибудь так:
И запускаешь этот запрос из php. (Добавление)
А если у тебя структура t1 и t2, вдруг, совпадает, то тогда проще это все держать в одной таблице и ввести дополнительное поле, по которому будешь различать информацию t1 от t2. Хотя, скорее всего, у тебя структура не совпадает, поэтому это я на всякий случай...
Покинул форум
Сообщений всего: 35
Дата рег-ции: Июль 2010
Помог: 1 раз(а)
[+]
[quote=MAXUS][quote]Зато на php это все можно реализовать в три секунды.
[/quote]
на пхп да, но нужно mysql
[quote=MAXUS]
Цитата:
(Добавление)
Хотя, скорее всего, у тебя структура не совпадает, поэтому это я на всякий случай...
структура не совпадает, каждой категории товаров соответствует своя таблица
Цитата:
явно беда с архитектурой бд
нормально все с этим, там масса других нюансов почему надо так а не иначе
Увы, Ваш вариант не подходит т.к. таблиц на самом деле N и добавляются они динамически, а имена заранее неизвестны. поэтому инфа о том какой товар лежит в какой таблице хранится в "индексной" таблице
LIME
Отправлено: 20 Октября, 2013 - 13:46:36
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Артком пишет:
каждой категории товаров соответствует своя таблица
Покинул форум
Сообщений всего: 35
Дата рег-ции: Июль 2010
Помог: 1 раз(а)
[+]
caballero пишет:
Цитата:
нормально все с этим,
когда нормально такие извраты не требуются
меняйте Mysql на какой нибудь промышленный сервер Бд если уж хочется такие
заморочки делать
это печально.. когда на первый взгляд простая задача называется извратом.
Уверен в мускуле есть возможность решить по простому данную задачу
LIME
Отправлено: 20 Октября, 2013 - 14:43:24
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Артком пишет:
Уверен в мускуле есть возможность решить по простому данную задачу
какие есть основания для такой уверенности?
твой способ это именно изврат
классический причем
посмотри все же ссылку выше
там как-раз люди предлагают более "нормальные" решения
Артком
Отправлено: 20 Октября, 2013 - 14:52:03
Новичок
Покинул форум
Сообщений всего: 35
Дата рег-ции: Июль 2010
Помог: 1 раз(а)
[+]
LIME пишет:
Артком пишет:
Уверен в мускуле есть возможность решить по простому данную задачу
какие есть основания для такой уверенности?
твой способ это именно изврат
классический причем
посмотри все же ссылку выше
там как-раз люди предлагают более "нормальные" решения
Ребята, вопрос не в том, зачем и почему мне это нужно, а как это сделать. Ничего сверх естественного в том, что имена таблиц, где хранятся данные, находятся в другой таблице не вижу. Никто не будет менять структуру приложения, имеющего большой объем данных и активно используемого только потому, что кто то называет какие то способы извратом и предлагает свое как обойти задачу и решить через пхп - подсказывать не надо, все элементарно. Тут скорее ради своего развития интересно, можно ли решить средствами БД
LIME
Отправлено: 20 Октября, 2013 - 14:59:45
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
Артком пишет:
Никто не будет менять структуру приложения, имеющего большой объем данных и активно используемого только потому, что кто то называет какие то способы извратом и предлагает свое
только по приведенной тобой причине конечно не стоит
а вот поняв недостатки своей структуры изменить ее стоит(не обязательно переписывать все и сразу)
иначе такие проблемы будут возникать при каждом изменении/добавлении функционала
Артком пишет:
и предлагает свое
а никто свое и не предложил
была предложена ссылка для ознакомления с более "нормальными" вариантами
таблица для каждой категории это определенно тупик
MAXUS
Отправлено: 20 Октября, 2013 - 15:19:55
Посетитель
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
Цитата:
явно беда с архитектурой бд
Цитата:
нормально все с этим
Не. Реально что-то не правильно. Таблица свойств товаров должна быть универсальной и храниться, например, в таком виде:
id_товара, имя_свойства, значение_свойства.
Просто делаешь выборку по этой таблице и все в соответствии с id. И все остальное по этому принципу. Если надо, заводишь еще таблицу
класс_товара, имя_свойства
В нее заносишь шаблоны и если товару назначен какой-то класс, то пользователю предлагается только свойства, которые присутствуют в классе. (Добавление)
Цитата:
Увы, Ваш вариант не подходит т.к. таблиц на самом деле N и добавляются они динамически, а имена заранее неизвестны. поэтому инфа о том какой товар лежит в какой таблице хранится в "индексной" таблице
Если php вообще не используется, то не подходит. А если используется, то никаких веских причин, чтобы этот вариант не подходил, я не вижу. (Добавление)
Артком пишет:
Тут скорее ради своего развития интересно, можно ли решить средствами БД
Судя по всему нет. Поэтому говорят о том, что структура не правильная. А задача - изврат, потому что есть масса способов решить первоначальную задачу (создание каталога товаров) более простыми способами, не упираясь в одно единственное решение, которое реализовать без изврата не получится (а скорее всего совсем не получится).
caballero
Отправлено: 20 Октября, 2013 - 15:34:01
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
когда на первый взгляд простая задача называется извратом
изврат не задача а ее решение
а на товары у тебя тоже генерится таблица на каждый товар?
Цитата:
Уверен в мускуле есть возможность решить по простому данную задачу
сомневаюсь что даже по сложному ее можно решить. В мускуле весьма слабо развит SQL. Преимущество mysql - это простота и большая скорость выборки на простых запросах.
Покинул форум
Сообщений всего: 35
Дата рег-ции: Июль 2010
Помог: 1 раз(а)
[+]
Спасибо конечно всем за советы, но мы отходим от темы....
п.с. нагрузка на БД в несколько терабайт трафика/мес. и поверте, если мы имеем тысячи категорий и у каждой по несколько сотен свойств- решение хранить в отдельных таблицах никак не тупик. Но тема не об этом
caballero
Отправлено: 20 Октября, 2013 - 15:59:26
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
если мы имеем тысячи категорий
не бывает столько категорий
Цитата:
несколько сотен свойств
не бывает столько свойств
Цитата:
решение хранить в отдельных таблицах никак не тупик
это тупик независимо от количества категорий
Цитата:
нагрузка на БД в несколько терабайт трафика/мес
я так понимаю это ожидаемая (типа в мечтах) нагрузка - криворукие разрабтчики не могут сделать реальный проект с таким трафиком.
и кстати большая нагрузка как раз говорит в пользу одной таблицы категорий
а не нескольких. (Добавление)
Цитата:
мы отходим от темы.
тема нереализуема - кроме как отходить ничего не остается (Добавление)
подставляй таблицу в PHP как написали выше
все равно VIEW не имеет смысла при такой архитектуре
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
действительно а какой смысл в VIEW
если категорий тысачы то вьюх будет мириады)) (Добавление)
и еще
если категорий тысячи то товаров в каждой пара десятков или что-то около того
иначе это какой-то АШАН или типа того
или даже того гораздо более
зависит от товаров
тогда имеет смысл эти таблицы-категории вообще хранить в пых-массивах
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.