Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.08.08;
Скачать: [xml.tar.bz2];

Вниз

Простой запрос из MSSQL2000 не работает в FireBerd1.5   Найти похожие ветки 

 
VadimKV   (2004-07-08 15:13) [0]

Элементарный запрос MSSQL2000.
В этом запросе данные берутся из вложенного запроса (который фактически формирует таблицу)- этот запрос наверное называется вложенным.
select t.field_name from
(select field_name from list_fld) as t

В FireBerd1.5/IB6 приведенный ниже запрос тоже называется вложенным, но это разные запросы, т.к. данные берутся не из вложенного запроса в скобках.
select field_name from list_fld
where field_name in
(select field_name from list_fld)
Псевдоним присвоить тут нельзя т.к. запрос после Where.
А первый запрос из MSSQL2000 в своем первоначальном виде в FireBerd1.5 не работает.
Как реализовать конструкцию запроса MSSQL в FireBerd1.5?


 
Sandman25 ©   (2004-07-08 15:15) [1]

У разных СУБД разные синтаксисы. Что нужно получить?


 
Danilka ©   (2004-07-08 15:17) [2]

твой первый запрос легко записывается так:
select t.field_name from list_fld t

и одинокого выполнится как на мс-скуле, так и на ИБ.
Приведи полностью текст запроса на МС-скуле, который тебе надо выполнить на ИБ, а то гадание получается, а гадатель сломан. :((


 
Курдль ©   (2004-07-08 15:20) [3]


> select t.field_name from
> (select field_name from list_fld) as t

Но ведь это бред!


 
VadimKV   (2004-07-08 15:30) [4]

В FireBerd1.5 не работает конструкция:
select * from (<запрос>)
Как эту конструкцию реализовать в FireBerd1.5?
Потомучто Я не представляю как тогда там обрабатывать данные из множества таблиц.

select t.field_name, t1.Field_name from tab1 as t1
(select field_name from list_fld) as t


 
Sandman25 ©   (2004-07-08 15:33) [5]

select t.field_name, t1.Field_name from tab1 as t1
(select field_name from list_fld) as t

заменяется на

select t.field_name, t1.Field_name
from tab1 as t1,
list_fld as t


 
Курдль ©   (2004-07-08 15:34) [6]

select * from TABLE_1, TABLE_2, TABLE_3
where TABLE_1.TABLE_2_ID = TABLE_2.TABLE_2_ID
and TABLE_2.TABLE_3_ID = TABLE_3.TABLE_3_ID


 
Danilka ©   (2004-07-08 15:34) [7]

гы.
а, например, вот-так не пробовал?

select t.field_name, t1.Field_name
from tab1 t1, list_fld t
where ...

или через join?
и вообще, лучше-бы книжки всаякие почитать..


 
Sandman25 ©   (2004-07-08 15:37) [8]

[7] Danilka ©   (08.07.04 15:34)

select * from
 (select * from
   (select * from a) b
 )

вот чем плохи MS SQL и Oracle :)


 
Danilka ©   (2004-07-08 15:39) [9]

[8] Sandman25 ©   (08.07.04 15:37)
Кстати, я не думал что MSSQL так умеет. А вообще, это иногда спасает. А иногда наоборот позволяет делать такие тормозные вьюхи..


 
Курдль ©   (2004-07-08 15:43) [10]


> вот чем плохи MS SQL и Oracle :)

А причем здесь Оракл? Чего это он не умеет, что умеет IB???  8-()


 
Sandman25 ©   (2004-07-08 15:43) [11]

[9] Danilka ©   (08.07.04 15:39)

Я недавно занимался MSSQL, мне эта фича очень понравилась, позволяет страшные вещи делать. Наконец-то в версии 9.4 Informix"а появился аналог.

Чтобы делать тормозные вьюхи, запросы из запроса необязательны. :( или :)


 
Sandman25 ©   (2004-07-08 15:44) [12]

[10] Курдль ©   (08.07.04 15:43)

На IB невозможно построить плохие запросы вида [8]

PS. А вообще-то я пытался пошутить :)


 
Johnmen ©   (2004-07-08 15:45) [13]

>VadimKV

В ИБ нет конструкции "запрос из запроса".
Его можно сымитировать с пом. VIEW.
Но очень сложно представить (по большому счету), когда без "запрос из запроса" не обойтись. Обычно необходятся те, про кот.намекнул Danilka ©   (08.07.04 15:34) [7]
:)))


 
Danilka ©   (2004-07-08 15:49) [14]

[10] Курдль ©   (08.07.04 15:43)
Наоборот, этой фишки нет в ИБ.
Можно сделать селект из таблицы, либо из вьюхи, а МС-Скуль и Орокол селект из селекта позволяет делать.

[11] Sandman25 ©   (08.07.04 15:43)
> позволяет страшные вещи делать

Вот именно. Из-за этго потом и появляются запросы на полтора десятка килобайт, которые разгребать умучаешься - почему тормоза. Особенно, когда селект из селекта в котором используются другие вьюхи. :))


> Чтобы делать тормозные вьюхи, запросы из запроса необязательны.
> :( или :)

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


 
Курдль ©   (2004-07-08 15:50) [15]


> Sandman25 ©   (08.07.04 15:44) [12]
> На IB невозможно построить плохие запросы вида [8]

Насколько я помню, в IB можно делать "запрос внутри запроса" типа
select T1.*, (select sum(T2.SUMMA) from TABLE_2 T2 where T2.T1_ID = T1.T1_ID) as T1_SUMMA from TABLE_1 T1
а в Оракле до 9-ки такое не акнало (только через танцы с группировкой).


 
Danilka ©   (2004-07-08 15:51) [16]

[13] Johnmen ©   (08.07.04 15:45)
> Но очень сложно представить (по большому счету), когда без
> "запрос из запроса" не обойтись.

Всегда можно как-то выкрутиться, но так и тянет к халяве. :))


 
Danilka ©   (2004-07-08 15:53) [17]

[15] Курдль ©   (08.07.04 15:50)
> а в Оракле до 9-ки такое не акнало

в восьмерке канает. :))


 
Sandman25 ©   (2004-07-08 15:55) [18]

[14] Danilka ©   (08.07.04 15:49)

Мой "рекорд" - 29 kb :)


 
VadimKV   (2004-07-08 15:58) [19]

Sandman25 так что, в FireBerd1.5 такую конструкцию совсем не льзя реализовать - select * from (<запрос>)
Незнаю как вы считаетя, а Я думаю такая конструкция жизненно необходимо. Вот пример где без этого кажется не обойтись.

(select name_table, size_field from  /*Здесь данные берутся как из таблицы*/
  (select name_table,
sum(       /*Сумма*/
case
when field_type = "long" then 4
when field_type = "alpha" then field_size
when field_type = "number" then 8
when field_type = "date" then 4
end
) as size_field
  from list_fld
  where field_key = "*"
  group by name_table) as max_key
where size_field > 195) as Tb_mk  /*Это условие накладывается на данные вычесленные в предыдущем запросе*/

Если действительно, кто то знает как решить эту проблему подскажите.


 
Sandman25 ©   (2004-07-08 16:03) [20]

select name_table,
sum(      
case
when field_type = "long" then 4
when field_type = "alpha" then field_size
when field_type = "number" then 8
when field_type = "date" then 4
end
) as size_field
from list_fld
where field_key = "*"
group by name_table) as max_key
having sum(      
case
when field_type = "long" then 4
when field_type = "alpha" then field_size
when field_type = "number" then 8
when field_type = "date" then 4
end
) > 195


 
Sandman25 ©   (2004-07-08 16:04) [21]

") as max_key" забыл удалить


 
Fay ©   (2004-07-08 19:30) [22]

Курдль ©   (08.07.04 15:43) [10]

> Чего это он не умеет, что умеет IB???  8-()

Нравиться просто так без причин. 8)


 
Danilka ©   (2004-07-09 11:27) [23]

[18] Sandman25 ©   (08.07.04 15:55)
> Мой "рекорд" - 29 kb :)

Ужас! :))
Я с больше чем 15к не работал, а сам не писал.
Точнее, писал когда-то что-то сравнимое, но из-за особенностей генератора отчетов.


 
Desdechado ©   (2004-07-09 13:46) [24]

Курдль ©   (08.07.04 15:43) [10]
А причем здесь Оракл? Чего это он не умеет, что умеет IB?

попробуй сделать
SELECT DISTINCT int_field, BLOB_field from tbl
В FB проходит, причем правильно, а Оракл гневно ругается :)


 
Desdechado ©   (2004-07-09 13:49) [25]

2 Курдль ©   (08.07.04 15:43) [10]
Я уж не говорю про понятие домена, который может содержать всякие ограничения на содержимое и проверки, а в Оракле я аналога не знаю. Мож кто подскажет? Или я так и останусь с мыслью, что здесь недоработочка...


 
Курдль   (2004-07-09 23:20) [26]


> Desdechado ©   (09.07.04 13:46) [24]
> SELECT DISTINCT int_field, BLOB_field from tbl
> В FB проходит, причем правильно, а Оракл гневно ругается

Точно! В Оракле-8: "Inconsistent Datatypes". Однако, не могу себе представить надобность такой фитчи. Пока не надобилась :)


> Desdechado ©   (09.07.04 13:49) [25]
> Я уж не говорю про понятие домена, который может содержать
> всякие ограничения на содержимое и проверки.

А зачем? Зачем это держать на уровне базы? Это все прописывается на уровне концептуальной модели - домены, бизнес-правила и т.п.
Какая разница. как это все "ложится" в БД?


 
Fay ©   (2004-07-10 02:44) [27]

Desdechado ©   (09.07.04 13:49) [25]
Не пробовали использовать домены в ХП? Попробуйте - очень бодрит! 8)


 
Desdechado ©   (2004-07-10 14:53) [28]

DISTINCT с блобом мне тоже как-то не нужно было, а вот с CLOB вполне может и понадобиться :) Хотя еще не было такого случая.
Просто в голову пришло попробовать, как сервера соблюдают правила  :)

2 Fay
Пробовал, ничего не вышло (по крайней мере, в FB1), но это не умаляет их достоинств. На уровне таблиц можно сделать много вещей, чтоб не лепить в триггеры. Да и один домен в 10 разных местах использовав, можно одним махом поменять его - и все поля пойдут одной дорогой.

По поводу концептуальной модели - очень правильно, вот только БД должна некоей мерой быть защищена от дурака, чтобы помимо тех правил, что придумал разработчик, кто-нибудь по своим правилам не записал туда что-то, что программа потом не опознает за корректные данные.


 
Fay   (2004-07-10 15:51) [29]

2Desdechado ©   (10.07.04 14:53) [28]
>> можно одним махом поменять его - и все поля пойдут одной дорогой.

Давно не проверял, под рукой нет. Но память говорит, что так не получится.


 
Курдль   (2004-07-11 20:46) [30]


> Desdechado ©   (10.07.04 14:53) [28]
> По поводу концептуальной модели - очень правильно, вот только
> БД должна некоей мерой быть защищена от дурака.

А я разве сказал про отсутствие защиты? Вам удобно что-то компоновать в домены (если я правильно понял). Я же это делаю на уровне концептуальной модели. При автоматической генерации CASE-средствами физической модели БД, а потом и скрипта самой базы, эти правила реализуются на основании идеологии СУБД. Причем, не важно, какой СУБД. С некоторых пор я даже не проверяю скрипты - мои инструменты ни разу еще не подводили.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.08.08;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.52 MB
Время: 0.033 c
3-1089900139
Delpher
2004-07-15 18:02
2004.08.08
Таблица в таблице.


8-1085311364
ттт
2004-05-23 15:22
2004.08.08
Как в Дельфи работать с изображениями серой градации


1-1090216972
Michael
2004-07-19 10:02
2004.08.08
Отследить вращение колесика мыши в мышки вне приложения


14-1090244953
PokSer
2004-07-19 17:49
2004.08.08
:))


3-1089784494
MVA
2004-07-14 09:54
2004.08.08
Запрос





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский