Нужно провернуть следующую фичу:
у меня есть 4 одинаковых таблицы. Почти одинаковых, потому что одно поле в них имеет разный тип (но одно и то же имя).
И есть ещё одна таблица, в одном из столбцов которой есть циферка, соответствующая номеру таблицы, которую мне надо использовать :)
Надо построить запрос, который бы сам выбирал нужную таблицу в зависимости от значения поля и производил манипуляции с данными в этой выбранной таблице)
select itype from `tab` left join <typetable_NNN> ttn on tab.id = ttn.t_id where ttn.data = "данные"
вот это typetable_NNN должно выбираться в зависимости от значения itype.
Круто ? Несколькими запросами я бы сделал. Надо одним.
P.S. Таблицы называются например так typetable_int, typetable_text, typetable_float. Первой соответствует itype=0, второй 1, третьей 2.
Примечание:
Я тут в качестве примера привёл 3 таблицы, а не 4. Но это не суть.
Примечание:
Что имеется ввиду под "объектной базой" ? На самом деле тут всё просто - что-то вроде нового слоя поверх плоских таблиц. Будем хранить в каждой таблице данные разного типа.
Да, для того, чтобы не создавать на каждый тип структурных данных свою новую таблицу в MySQL. Если ты имел ввиду данные в виде полей некоего класса, то очень похоже, да.
На самом деле всё уже работает, но меня смущают размеры запросов при поиске данных. Если искать по четырём условиям, то получается 16 юнионов, в каждом из которых есть ещё и join. Как-то не фонтан. Хотя работает вроде быстро. ПОКА быстро))
FUNCTION не хочется. Если уж на то пошло, то функцию я и в PHP сделаю. С кэшем, блекжеком и шлюхами всё получится не так уж и плохо. Просто хочется изящности.
Примечание:
>> В общем, объединишь одинаковые поля в одну таблицу - еще избавишься от юнионов лишних.
Ты хочешь сказать, собрать столбцы разных типов в одну таблицу и заполнять только тот столбец, который соответствует типу хранимых данных ? Не слишком ли расточительно ?
>> У меня сейчас такая база в работе, включая наследование.
Ну нет, мне такого не нужно. У меня пока одноуровневые структуры и другого в общем не предвидится.
Примечание:
>> Кстати, не пойму, откуда у тебя юнионы... При нормальной реализации их не должно быть.
Делаю выборку по таблице каждого типа данных, затем полученные из каждой таблицы id-шники объединяю union'ами.
Примечание:
2 Enyby
Да, у меня в этом варианте примерно так и получилось. Итог - гигантские медленные запросы для получения банальных вещей типа выборки по нескольким полям. Почитав теорию по EAV-структуре я понял, что всё сделал не так как надо. В итоге переделал структуру (переделал под 3NF) и переписал почти с нуля ORM-либу. Сейчас всё физически работает (выборка, сортировка по любому количеству полей, лимитинг) и не тормозит, поскольку запросы получаются в 10 раз проще.
Всем спасибо.
RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.
Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.
Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.