Привет, _MarlboroMan_!
Вы пишешь 19 марта 2004:

AC>> Опять съехал...
AC>> Я про актуализацию статистики, а ты опять "...заунывную песню свою"...

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

Ты лично на ней пытался что-либо "сурьёзное" сделать?
Нет? Ну и нефик тут пальцы веером крутить. Фи.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Привет, Merle!
AC>Вы пишешь 19 марта 2004:

AC>>> Я про актуализацию статистики, а ты опять "...заунывную песню свою"...
M>> Да при чем тут статистика? Ей никто пользоваться не собирается.

AC>Это потому что один человек в этой конференции заявил, что он всё планирует руками,
AC>и сразу оба модератора решили, что для IB это есть нормально и все IB-шники так поступают?

неа. не так. один человек заявил что в IB что делается так-то. после чего модераторы и уважаемые участники форума сказали: ну это косяк. и даже не косяк а КОСЯК и так низзя — бо может стать мучительно больно "за бесцельно прожитые годы"".
на что было сказано: "дык если так, то можно [вот так]", на что последовал ответ: так тоже плохо бо [вот есть такая ситуация]" и вывод: Re[35]: Особенности Interbase

Автор: Merle
Дата: 19.03.04

Привет, Merle!
Вы пишешь 19 марта 2004:

AC>> Это потому что один человек в этой конференции заявил, что он всё планирует руками,
AC>> и сразу оба модератора решили, что для IB это есть нормально и все IB-шники так поступают?
M> Эээээ... спокуха на лице Мы обсуждали конкретную ситуацию, почему все IB'шники решили, что мы с ними не дружим..

А ты коллегу своего почитай

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Ты лично на ней пытался что-либо "сурьёзное" сделать?
AC>Нет? Ну и нефик тут пальцы веером крутить. Фи.

да вы батенька демагог приотменнейший. конструктив будет или всё?

Привет, _MarlboroMan_!
Вы пишешь 19 марта 2004:

[Sorry, skipped]
AC>> Это потому что один человек в этой конференции заявил, что он всё планирует руками,
AC>> и сразу оба модератора решили, что для IB это есть нормально и все IB-шники так поступают?

M> неа. не так. один человек заявил что в IB что делается так-то. после чего модераторы и уважаемые участники форума сказали: ну
M> это косяк. и даже не косяк а КОСЯК и так низзя — бо может стать мучительно больно "за бесцельно прожитые годы"".

О том, что косяк, подтвердил и один из ведущих девелоперов FireBird. Никто и не спорит.
А вот то что можно закладываться на это как на фичу — на совести того, кто это сказал.
И никто из специалистов это не рекомендует к использованию в данном конкретном случае.
Например: http://www.ibase.ru/devinfo/deldupes.htm

--
With best regards, Alex Cherednichenko.

Привет, _MarlboroMan_!
Вы пишешь 19 марта 2004:

AC>> Ты лично на ней пытался что-либо "сурьёзное" сделать?
AC>> Нет? Ну и нефик тут пальцы веером крутить. Фи.

M> да вы батенька демагог приотменнейший. конструктив будет или всё?

И я же ещё и крайний?!
Вспоминается: «Я Пастернака не читал, но осуждаю!».

--
With best regards, Alex Cherednichenko.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alex.Che, Вы писали:

AC>>Я про актуализацию статистики, а ты опять "...заунывную песню свою"...
M>Да при чем тут статистика? Ей никто пользоваться не собирается.
M>Давай по шагам:
M>1. У оптимизатора проблемы.
M>2. Пердлагается жестко задвинуть оптимизатор и подумать за него.
M>3. Обсуждаются недостатки этого подхода.
M>4. Тут ты, сосвоей статистикой... Зачем? Если мы пользуемся статистикой, мы скатываемся к случаю (1) — у оптимизатора проблемы. (чтобы понять что такое рекурсия, надо сначала понять, что такое рекурсия)

M>Нас сейчас не интересует ни статистика, ни способы ее сбора и обработки.

Тц! Я предложил всего лишь способ выполнить запрос так, чтобы получить требуемые результаты. Отнюдь не секрет, что оптимизатор IB не так хорош, как у больших серверов.
Но я не предлагал писать только такие запросы! Или так, или так — не подходит. И так, и иначе — гораздо лучше.
Вы думаете, я не смотрю на план и статистику? Вы ошибаетесь. Смотрю. И выбираю тот способ, который быстрее и удобнее. Но вместе с тем я также уверен, что вынос подзапроса, параметры которого не зависят от внешнего — самый быстрый способ получить требуемый результат. Хотя бы потому, что подзапрос выполнится один раз. Что и было приведено.
В других случаях — по ситуации. Обычно пробуется 2-3 варианта запроса, и выбирается наиболее быстрый. И не надо говорить, что ситуация может резко изменится — выбор идет на тестовой базе, с реальными данными. Дело в том, что я обычно сталкиваюсь, можно сказать, с тремя типами таблиц БД: Первый тип — таблица с небольшим количеством строк, причем их количество практически не меняется, оно фиксировано и примерно известно. Второй тип — таблица со средним количеством строк, которая растет средним темпом. Третий тип — массивная таблица, с приростом в разы большим, чем во втором случае.
В случае соединений разных типов таблиц я вполне могу прикинуть, как лучше написать запрос. А вот при работе с одинаковыми мощностями таблиц — надо смотреть и на план, и на статистику.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Romkin, Вы писали:

R>>Скорее всего вгонит. Что написали — то и получите
M>Это нормально? Нет это не нормально...
M>Хотя, говорят, в FireBird'е это пофиксили...

R>>IB удовлетворяет стандарту SQL92.
M>В каком месте?

Можно сделать select from ... order by id desc
тогда не вгонит

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>На каком сервере ты это пробовал или так просто чисто интуитивно написал в Interbase удаляет все кроме одной это связано с тем, что Вложенный селект выполняеться заново после каждого делита — соответственно одна запись останеться
S>Охренеть! Специально поставил Interbase 6.5 для проверки. Я и раньше знал, что Interbase — редчайший отстой, но чтоб настолько жидко...
S>тест 1:
S>

S>create table test(id int, val char(5));
S>insert into test values(1, 'red');
S>insert into test values(2, 'green');
S>insert into test values(3, 'blue');
S>insert into test values(2, 'green');*/
S>delete from test
S>  where test.ID in (select id from test GROUP BY id HAVING count(id)>1);
S>select * from test;
S>

S>Результат:
S>

S>id value
S>-- -----
S>01 red
S>02 green
S>03 blue
S>

S>Давайте убедимся, что это — страшный косяк. Попробуем вычислить предикат в условии Delete вручную и скормить уже его:
S>

S>create table test(id int, val char(5));
S>insert into test values(1, 'red');
S>insert into test values(2, 'green');
S>insert into test values(3, 'blue');
S>insert into test values(2, 'green');*/
S>/* А вот так можно убедиться в том, что в in стоит именно эта коллекция:*/
S>select id from test GROUP BY id HAVING count(id)>1; 
S>delete from test
S>  where test.ID in (2);
S>select * from test;
S>

S>Результат:
S>

S>id value
S>-- -----
S>01 red
S>03 blue
S>

S>Здорово, да? То есть у нас результат запроса зависит от порядка вычисления аргументов. Мы вроде как сделали эквивалентную замену (а ведь SQL — это функциональный язык), а результат изменился. Другая особенность в том, что если бы у нас записи с ID = 2 различались в поле val, то результат запроса вообще получается неопределенным.
S>В общем, ребята, Interbase — не RDBMS. Нельзя ее применять. Самые простые и очевидные вещи сделаны там через ухо.

1. Попробуйте сделать то-же на Yaffil ... упс — ошибка (ИМХО, более честное поведение);
2. SQL его расширения не есть одно и то-же.
3. Ну и пусть не RDBMS — покажите мне тогда хоть одну и я раскопаю на нее не-RDBMS-овское поведение. А IB, особенно доделанный — это гениальная весч — не каждый движок БД может поместиться ... на 1 дискету и при этом заамечательно обрабатывать OLTP и OLAP запросы (конечно заранее оттюненые) в организации с 200 постояно работающих пользователей, сам работая на целерончике. Настраивая в той-же организации ORACLE на 200 килаграмовом риске ... ну в общем вспоминаешь про IB/Yaffil, не замечая особой разницы в производительности. Ручки и опыт никакая супер-пупер РСУБД не заменит;
4. Да, оракла, к примеру — тоже не RDBMS, если по класике походить :-D.

Здравствуйте, <Аноним>, Вы писали:

А>1. Попробуйте сделать то-же на Yaffil ... упс — ошибка (ИМХО, более честное поведение);
С какого это перепугу ошибка при выполнении совершенно невинного запроса называется честным поведением? Это баг! Поведение интербейза можно списать как фичу
А>2. SQL его расширения не есть одно и то-же.
Прошу прощения, что именно здесь расширение?
А>3. Ну и пусть не RDBMS — покажите мне тогда хоть одну и я раскопаю на нее не-RDBMS-овское поведение.
См. tpc.org. Там
А>А IB, особенно доделанный
Вручную?
А>- это гениальная весч — не каждый движок БД может поместиться ... на 1 дискету и при этом заамечательно обрабатывать OLTP и OLAP запросы (конечно заранее оттюненые) в организации с 200 постояно работающих пользователей, сам работая на целерончике.
Видишь ли, с моей точки зрения от РСУБД в первую очередь требуется корректность, во вторую устойчивость, а уже в третью — малое ресурсопотребление. Для несчастных 200 сотрудников, работающих с MSSQL, не потребуется двухсот килограммов риска. Пара гигов памяти и рейд. Про размер инсталляции и говорить нечего — один гиг места на винте вообше ничего не стоит. Если, конечно, эту СУБД не надо дважды в неделю переставлять для стабильной работы
Потери от неверной работы SQL запросов могут стоить на порядок больше такой железяки. Даже затраты на оплату программерских усилий по обходу граблей стоят больше. Нет, я верю в то, что бывают такие организации, в которых и программер работает за 2 МРОТ, и железяку дали шефы после списания, и убыток от простоя исчисляется копейками... Но надо четко понимать границы, за пределами которых эти преимущества теряются.
А> Настраивая в той-же организации ORACLE на 200 килаграмовом риске ... ну в общем вспоминаешь про IB/Yaffil, не замечая особой разницы в производительности. Ручки и опыт никакая супер-пупер РСУБД не заменит;
С этим никто не спорит. Но раскладывать грабли посреди ровна поля совершенно незачем.

З.Ы. У нас тут целое поколение народу воспитано в духе блокадного ленинграда. Ну там типа "о-о, этот компонент стоит 200 баксов — давайте лучше напишем свой!" (при зарплате программера в 600 баксов и примерно полугоде времени на разработку). Или там "о-о, пусть этот мэйл сервер глючит и админ каждый раз его настраивает по три ночи, но он жужжит на 486DX266". Надо отучаться от этой позиции. Самое дорогое — это время админа (потому что оно тратится все время эксплуатации). Второе по стоимости — разработчика. Третье — лицензии на софт. А ценой железа можно пренебречь в большинстве случаев.

Привет, Sinclair!
Вы пишешь 29 сентября 2005:

А>> 1. Попробуйте сделать то-же на Yaffil ... упс — ошибка (ИМХО, более честное поведение);
S> С какого это перепугу ошибка при выполнении совершенно невинного запроса называется честным поведением?

Шо, опять?! 8-o
Какой чмудила опять поднял топик годичной давности?

--
With best regards, Alex Cherednichenko.

А>>1. Попробуйте сделать то-же на Yaffil ... упс — ошибка (ИМХО, более честное поведение);
S>С какого это перепугу ошибка при выполнении совершенно невинного запроса называется честным поведением? Это баг!

вы не правы, баг это когда в документации одно а работает по другому. а тут все задокументировано, так что тут все честно — фича.

Здравствуйте, Аноним, Вы писали:

А>Ну вообще то можно и без временной таблицы.
А>В интербайсе прокатывает вот такой запрос, который удалит все записи кроме одной с повторяющимся id.


А>

А>delete from Table1
А>where Table1.ID in (select id from Table1 GROUP BY id HAVING count(id)>1)
А>

Вот ещё прикол из той же серии

CREATE TABLE T1 (
    A INTEGER,
    B INTEGER)

insert into t1 (a,b) values (0,0)

update t1 set a=1, b=a

и в поле b записывается 1 !

Здравствуйте, Sinclair, Вы писали:


S>В общем, ребята, Interbase — не RDBMS. Нельзя ее применять. Самые простые и очевидные вещи сделаны там через ухо.

Есть отличие между "in" и "=". Запрос

delete from test
  where test.ID = (select id from test GROUP BY id HAVING count(id)>1);

Приведет к удалению всех id=2

Здравствуйте, Dzmitry-sh, Вы писали:
DS>

DS>delete from test
DS>  where test.ID = (select id from test GROUP BY id HAVING count(id)>1);
DS>

DS>Приведет к удалению всех id=2
А вот этот запрос вообще должен выдать ошибку. Т.к. идет сравнение значения поля с множеством, а не единичным значением.

Здравствуйте, Romkin, Вы писали:


R>А так? Вызов примитивен: Select * from LIST_DOC(:FNUM), но при наличии многих джойнов (а не одного, как здесь) план будет гораздо эффективнее во втором случае. Соответственно, выигрыш в скорости — в разы.
Вообще-то не должно быть. Очень давно видел IB, но законы оптимизации и в Африке законы оптимизации. В данном случае ты получил nested запросы в стиле SystemR. То есть при 1000 строк ты получишь 1000 запросов. Это не совсем гуд, и не сильно оптимально. Если оптимизатор не настолько умный сделать запрос как ему надо(теоретически на таком запросе это возможно) а не как вы написали, вы получите большую неоптимальность. Наиболее оптимальным для такого запроса(если это больше 10 строк) будет именно join.

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