Меню
Что нового?

SELECT из таблицы, имя которой хранится в ячейке другой таблицы...

  • Автор темы Автор темы Pietrovich
  • Дата начала Дата начала

Pietrovich

Guest
SELECT из таблицы, имя которой хранится в ячейке другой таблицы...

возможен ли сабж одним запросом, или никак?

собсно для чего нужно:
есть 3 части:
1 таблица в которой хранятся общие для всех типов событий поля (номер, тип, дата и т.д.),
2 таблица в которой хранится названия событий для первой таблицы (varchar который редко юзается)
3 десятка таблиц со специфическими для разных типов событий данными (количество колонок, типы колонок)

хотелось бы 1ю и одну из 3их джойнить одним запросом, но никак не могу его скрутить....
 
а в чем проблема встала ?
select * from t1 , t2 where t1.id = t2.t1_id
 
>select * from t1 , t2 where t1.id = t2.t1_id

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

не могу же я попросить муСКЛ "а выберика мне из той таблички из этого списка, в которой есть строчки, подходящие для этого 'родителя' "

вопрос как раз в том, можно ли каким то образом использовать к качестве имени таблицы данные из другой таблицы... или никак?
 
нука по подробнее расскажи про свою структуру, сдается мне, что дизайн базы сильно поколеченый.
 
сдается мне, что дизайн базы сильно поколеченый. [/B]
Нажмите для раскрытия...
спорить не стану, вполне возможно... я пока все еще в раздумиях...

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

виды ставок зависят от типа события. т.е. на футбольный матч принимаются одни виды ставок а на бокс другие... т.е. на футбол нужно 20 колонок а на бокс всего 3...

можно пойти двумя путями:
побить события на подобные группы и загонять кэфы в таблицу соответствующей группы, либо сделать одну универсалюную таблицу в которой перечислены все варианты а ненужные колонки просто забиваются NULLями...

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

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

З.Ы.: в часы пик кол-во юзеров на сайте одновременно будет около 100 человек... машина конечно мощная и все стерпит, но хотца чтобы машина напрягалась по минимуму...
 
А сколько всего этих видов ставок и будут ли их количество увеличиваться ?
 
>А сколько всего этих видов ставок

групп около 10, я еще точно и сам не разобрался, жду когда буки ответят...

для описания всех видов ставок и кэфов к ним нужно около 30 колонок

>будут ли их количество увеличиваться?
будут. нужно будет еще несколько видов сорта со временем добавить....
+ очень скоро нужно будет
вкручивать еще и ставки на "неспрортивные" события... курсы валют и еще какая-то херня...

т.е. это орднозначно увеличит колво колонок если использовать общую таблицу...

-----------------------------------------------------
количество одновременно обрабатываемых событий думаю не будет превышать 400-500, иногда меньше, но вряд-ли больше ...
после истечения срока я их в другую БД сливать буду, а новые обчно появляются не раньше чем за 3-5 дней...
 
Что то я не понимаю всех этих терминов, и тем более что и как к чему относится, так что помоч наверно не смогу, сорри.
 
Исключительно интересная тема.
Что касается "возможен ли сабж одним запросом, или никак?"
нет не получится.

Что касается "можно пойти двумя путями:"
есть и третий вариант - таблица ключ-значение (три поля).
Плюс - отвязываемся от количества видов ставок.
Минус -сложные запросы, когда необходимо выбрать несколько ставок одинакового вида, куча джоинов, точно не помню, но когда эксперементировал получалось один джоин на поле.
Хотя, с другой стороны, задачка по составлению таких запросов несложно(?) формализируется, можно написать функцию расширения для типовый классов работы с бд.

ПС: А вообще тема много раз поднималась на форуме, но собрать всё воедино, как-то не получилось до сих пор. Думаю, прекрасная тема, для тех кто хочет отвлечься от кодинга и написать пару статей.
 
>нет не получится.
да я и сам дошел... теперь меня больше интересует как лучше БД спректировать...

>Что то я не понимаю всех этих терминов, и тем более что и как к чему относится
придумал!
линия - склад
событие - быстопортящийся товар.
товары бывают нескольких категорий.
каждая категория описывается опреденным количеством характеристик.

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

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

ого как я завернул... сам на это дело взглянул по новому :)
 
Нифига в этой области не понимаю, но из того, что прочитал, могу посоветовать не городить таблицы, а использовать отдельную таблицу для хранения различных параметров и промежуточную для отношений "многие ко многим" между таблицей, хранящей основные данные, и таблицей со значениями дополнительных параметров.
 
к сказанному fixxxer-ом , думаю он это имел ввиду:
Код: 
.-------.   .---------.   .-------------.
|События|--<|Категории|--<|Набор свойств|
'-------'   '---------'   '-------------'
    |   .-----------------.      |
    '--<|Значения свойства|>-----' 
        '-----------------'
 
вообщето это все называется двоичными базами. Может просто про них где нить почитать ?
 
Войдите или зарегистрируйтесь для ответа.
Сверху