Уровнять количество полей...

avenger · Сообщение **avenger** » 20 янв 2007, 00:23

Привет Всем!

Есть запрос. На самом деле он не такой.

SELECT
    MN.CREATE_DATE, MN.TITLE, MN."MESSAGE"
FROM
    MODULE_NEWS MN

WHERE MN.IFACTIVE = 1
    AND MN.STATUS IN (0, 1)
    and mn.module_new_id in (7,8,9)

union all

SELECT
    '-1', '-1' as tt, MN."MESSAGE"
FROM
    MODULE_NEWS MN

WHERE MN.IFACTIVE = 1
    AND MN.STATUS IN (0, 1)
    and mn.module_new_id in (17,18,19)

order by 1

Как можно уровнять количество полей? Пытаюсь во второй запрос написать '-1', '-1'. А он мне в ответ, добрый такой: Data type unknown

.

С уважением, Иван.

Сообщение **kdv** » 20 янв 2007, 01:10

используй cast. собственно, я не знаю, как ты хочешь показать строку (!) -1 в столбце даты. Или не знаю, что там у тебя.

avenger · Сообщение **avenger** » 20 янв 2007, 01:39

kdv писал(а):используй cast. собственно, я не знаю, как ты хочешь показать строку (!) -1 в столбце даты. Или не знаю, что там у тебя.

С кастом работает. А другого способа нет, а то тип поля вытаскивать не хотелось бы?

Это просто в поиске используется. Могут быть любые типы столбцов, заранее неизвестных.

Attid · Сообщение **Attid** » 20 янв 2007, 10:42

С кастом работает. А другого способа нет, а то тип поля вытаскивать не хотелось бы?

Это просто в поиске используется. Могут быть любые типы столбцов, заранее неизвестных.

а ты приводи все кастом к varchar(20) тогда и тип вытаскивать не надо будет и сможешь в одном столбце отображать и дату и -1, только кроме как отображение это лучше потом не использывать

(имею ввиду сортировку на клиенте и прочее)

avenger · Сообщение **avenger** » 20 янв 2007, 11:05

Attid писал(а):а ты приводи все кастом к varchar(20) тогда и тип вытаскивать не надо будет и сможешь в одном столбце отображать и дату и -1

Спасибо, а блоб тоже к varchar(20) приводить?

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

Attid · Сообщение **Attid** » 20 янв 2007, 11:21

avenger писал(а): Спасибо, а блоб тоже к varchar(20) приводить?

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

а ты блоб показываешь в гриде ?

avenger · Сообщение **avenger** » 20 янв 2007, 11:48

Attid писал(а):а ты блоб показываешь в гриде ?

Я про грид ничего не говорил. Вывожу блоб на Web страницу.

avenger · Сообщение **avenger** » 20 янв 2007, 12:38

Есть у меня еще одна идея, как можно вытянуть все данные одним запросом:

Есть N-таблиц, у каждой из которых есть уникальное поле SEARCH_TABLE_FK. Это поле заполняется одним генератором. Т.е. можно сказать, что поле уникально для N-таблиц.

Тогда можно написать такой селект:

Код: Выделить всё

SELECT * FROM SEARCH_QUERY_RESULTS
LEFT JOIN MODULE_CONTENTS  ON MODULE_CONTENTS.SEARCH_TABLE_FK = SEARCH_QUERY_RESULTS.TABLE_ID
LEFT JOIN MODULE_NEWS ON MODULE_NEWS.SEARCH_TABLE_FK = SEARCH_QUERY_RESULTS.TABLE_ID
...
WHERE ...

В этом случае запрос вернет все нужные мне записи, но количество столбцов будет большим.
Например, объединим 10 таблиц по 25 столбцов => 250 столбцов в результате.

Можно ли использовать такой подход?

avenger · Сообщение **avenger** » 20 янв 2007, 12:48

Да и за счет чего в этом случае возникает ошибка
Invalid token.
invalid request BLR at offset 657.
Implementation limit exceeded.
block size exceeds implementation restriction.
?

Из-за большого количества join-ов или из-за большого количества возвращаемых полей?

CyberMax · Сообщение **CyberMax** » 20 янв 2007, 13:59

Да вы, батенька, понимаете толк в реляционных извращениях... Может, сначала почитать Дейта и Грабера?

Сообщение **kdv** » 20 янв 2007, 20:46

да и почитать www.ibase.ru/devinfo/joins.htm не мешало бы, а то какие-то left join подозрительные...

avenger · Сообщение **avenger** » 20 янв 2007, 23:07

kdv писал(а):да и почитать www.ibase.ru/devinfo/joins.htm не мешало бы, а то какие-то left join подозрительные...

Да нет в них ничего подозрительного. Только в некоторых столбцах будет много NULL, т.к. есть один генератор для нескольких таблиц на поле SEARCH_TABLE_FK в таблице.

CyberMax · Сообщение **CyberMax** » 21 янв 2007, 05:39

avenger писал(а):Да нет в них ничего подозрительного.

Конечно нет. Подумаешь, в наборе 250 столбцов и всё подряд из таблиц будет тянуться на клиента. Это вполне нормально для реляционных баз данных и даже более того, так и надо писать. Надо же чем-то сервер и сетку занять?

avenger · Сообщение **avenger** » 21 янв 2007, 11:24

CyberMax писал(а):Конечно нет. Подумаешь, в наборе 250 столбцов и всё подряд из таблиц будет тянуться на клиента. Это вполне нормально для реляционных баз данных и даже более того, так и надо писать. Надо же чем-то сервер и сетку занять?

. Это круто конечно. В реальной задачи, будет максимум по 5 столбцов (ID, ID1, ПоискПоле1, ПоискПоле2, ПоискПоле3).
Т.е., если было скажем 10 таблиц, в которых найдена информация, то всего 50 полей + 6 еще информация по поиску (ID, релевантность, количество найденных слов,...).

А информация будет представлять так:
ID,..., Weight, ПоляТаблицы1, ПоляТаблицы2,... , ПоляТаблицы10
1 10 NULL Информация NULL
2 15 NULL NULL Информация
3 20 Информация NULL NULL

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

Но как я понял лучше будет 10 запросов. Но в этом случае, я не смогу отсортировать результаты по релевантности. Придется делать это на клиенте. Дополнительные затраты ресурсов.

Делема получается....