>Рыдает, бьется лбом об пол, идет сносить oracle и ставить sqllite

странные это звери - ораклоиды.

насколько я понимаю тот анонимус прокомментировал встраиваемость фиребирда.

если вас такие мелочи сподвигают на повторение подвига томми, это повод задуматься

>малолетнее

тебе уже больше 30 и ты до сих пор делфибыдлопрограммер?

>падонкоподобное существо не научившееся уважать

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

>я ж говорю - падонак

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

Отличная новость, но!... Всем хорош этот бёрд, кроме одного - назначения прав доступа! Почему-то права доступа к объектам БД не являются сборными правами групп (или ролей, если угодно), а назначаются для группы, указанной при поключении. А указать можно лишь группу, к которой принадлежить юзер. Короче, вся система с назначением прав с помощью ролей извращена, к нормальному использованию не пригодна и ко второй версии не исправлена! Так что, не смотря на всю "хорошесть" этого сервера, его удел - встраиваемые БД и не далее... Обидно, чесслово - ведь в остальном нормальный сервер!

Так что, господа, PostgreSQL - наш выбор!

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

И много, уважаемый, вы накрапали междумордий к БД на лиспе? Кстати, назовите нормальный инструмент для создания подобного класса программ под линукс? Молчим-с? ну-ну

=))))
>>малолетнее

>тебе уже больше 30 и ты до сих пор делфибыдлопрограммер?
мальчик, я уже давно зам. генерального директора =)))
а ты до сих пор даже имени своего не имеешь... ананист... тьфу, ананим


>>падонкоподобное существо не научившееся уважать

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


>>я ж говорю - падонак

>дельфисты народ обидчивый. как обидят их священную корову - сразу
>начинаются сопли на форуме
где это я обижался? =))) сопельки то твои как раз форум измарали...
только вопрос остался - а зачем обижал то, тебе то чего они плохого сделали? заработали более тебя? а тебя великого гуру (sic) недооценили работодатели в результате?

> Firebird действителько качественная база, быстрая, НАДЕЖНАЯ

после того, как у меня несколько раз лег IB5.5 (на производстве), я к нему и близко не подхожу

добавление - это началось, когда база превысила 40МВ

>после того, как у меня несколько раз лег IB5.5 (на производстве), я к нему и близко не подхожу

Вы бы, уважаемый, еще про DOS 3.30 вспомнили! Сравнили, извините, сардельку с пальцем!

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

а по-вашему, программирование - это знание синтаксиса какого-либо языка, а языки, в вашем понимании, четко разделены по "крутизне"? :о)))

Родители! Не пускайте несовершеннолетних детей в интернет без присмотра! :о)))))))))))))))))))))

>У нас на работе склад и вебсайт крутится на firebirdе 1.5 работает быстро (5000 позиций товара 3-4 паралельных клиента

Да на 5000 позиций и grep+bash чудно работать будут

склад на баше.... ну ты и затейник =))

>странные это звери - ораклоиды.

>насколько я понимаю тот анонимус прокомментировал встраиваемость иребирда.

> если вас такие мелочи сподвигают на повторение подвига томми, это повод задуматься

Чуваки, расскажите, что за Томми такой, а то везде говорят, а я не понимаю, в чём прикол...

>поделие не надежно, не устойчиво и мало того под оффтопик :(

Уж повеселил, так повеселил!!! :D "Подофотпиком" - особенно.

>после того, как у меня несколько раз лег IB5.5 (на производстве), я к нему и близко не подхожу

... и Первая Мировая война тоже уже давным-давно закончилась :D

> SQLite все равно лучше всех! Самая нормальная база - легкая, быстрая, без дураццких транзакций, реально никому не нужных курсоров, авто - бэкапов и прочей муйни. ТОЧКА

Действительно идиоты! Напридумывали какие-то транзакции, курсоры, репликации и прочую муйню. Кому это только надо? Я вот написал свою крутую прогу аля Hello world! и мне все это совсем не понадобилось. И вообще я не понял зачем эти базы данных нужны?

странно на старой работе я работал с IB 5.5 без глюков и размером более гига глюков не было! а сейчас онга поднялась до 2Г и тоже работает! ошибки с данных возникают но там человеческий фактор да еще какой! так сильно заебывал нас со всякой ерундой млин!

Не буду доказывать, что Firebird круче других баз, но то, что с ним невозможно работать, как пишут некоторые - неправда. Тысячи (а может и десятки тысяч) программистов пользуются им при разработке приложений. У сервера нет недостатков, которые бы делали его испоьзование невозможным. Я разработал несколько проектов, которые успешно работают. Самый старый в работе уже 5 лет. Кроме того знаю не одну организацию, в которой успешно используется FB в качестве сервера БД. У FB есть свои особенности и баги. Но никто не заставляет разработчика наступать на известные грабли... Конечно у FB своя ниша. Это бесплатный сервер, позволяющий нормально работать на нем одновременно нескольким десяткам пользователей и вполне нормально переживающий объемы базы в несколько десятков Гб. Если требования к информационной системе выше - видимо стоит смотреть в сторону более мощных серверов.

Как Вы решали проблему с назначением прав доступа? Придумывали свое? Ужас...

Имеем БД 4,8 Gb на classic под линухом, весьма изрядно нагруженную математикой, работает успешно. Единственная существенная проблема - уже упоминавшиеся неподнимающиеся бэкапы - происходит от криворуких программеров, правящих БД как попало и еще и норовящих делать это на рабочей базе. Повбивав би! Написали скрипт для проверки бэкапов.

У нас в Краснодаре есть организация, которая решилась переводить склад с нее на Оракл, только после того,как объем БД перевалил за 60Гб.

С правами доступа особых проблем нет. Использовал то, что предоставляет сервер. В информационной системе есть несколько категорий Администратор, Директор, Менеджер, Продавец... Им соответствуют роли в FB. Нельзя, конечно, создать пользователя с правами продавца и директора одновременно, приходится создавать под такие случаи новую роль... На самом деле (в моей практике) крайне редко это создает неудобства. Пользователи далеко не каждый день новые появляются. А уж менять набор прав приходится преимущественно только в процессе опытной эксплуатации. Так что ничего ужасного в этом нет.

я могу сказать где FB очень даже мешает - у нас в организация работает с 5 банками (соотв 5 клиент-банковских программ), и 2 из них используют subj. Как их прикажете разруливать. Внести все вместе не проходит - это БАНКОВСКИЕ программы

зы сейчас у бухгалтера стоит 2 системы ззы насчет компетентности установщиков - я к обоим базам поключился как sysdba/masterkey

я могу сказать где FB очень даже мешает - у нас в организация работает с 5 банками (соотв 5 клиент-банковских программ), и 2 из них используют subj. Как их прикажете разруливать. Внести все вместе не проходит - это БАНКОВСКИЕ программы

зы сейчас у бухгалтера стоит 2 системы ззы насчет компетентности установщиков - я к обоим базам поключился как sysdba/masterkey

Спрашивал уже в другоп топике, но никто не ответил однозначно.
Есть талица и есть view:
create table t1(whendate datetime,vv int);
create view v1 as select * from t1 union select now(),10;

Также создан индекс для t1 по полю whendate.
Запрос select * from t1 where whendate > '2005-11-01';
использует этот индекс.

ВОПРОС: на каких СУБД запрос из view будет использовать индекс?!
select * from v1 where whendate > '2005-11-01';

Постгрес 7.2.x индекс не использует точно, как не крути.
Какие СУБД используют (или не используют) индекс?
Интересуют oracle,mssql,informix,sybase,firebird.

Просто у нас софт часто делает такие выборки из view (пока заточен на постгрес),
и все уже ощутимо тормозит, а таблицы растут и растут..

Спасибо за ответ заранее!

Программы используют разные версии серверов? Если да то какие? Если нет - в чем проблема?

Попробовал только что на FB. Индекс используется.

>ВОПРОС: на каких СУБД запрос из view будет использовать индекс?!

в оракле будет:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> create table t1(whendate date, vv int);

Table created.

SQL> create view v1 as (select * from t1 union select sysdate, 10 from dual);

View created.

SQL> insert into t1 values (to_date('2005-11-01', 'YYYY-MM-DD'), 1) ;

1 row created.

SQL> commit ;

Commit complete.

SQL> create index t1_idx on t1(whendate) ;

Index created.

SQL> select * from v1 where whendate > sysdate-20;

WHENDATE VV
------------------ ----------
22-NOV-05 10


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=4 Card=2 Bytes=44)
1 0 VIEW OF 'V1' (VIEW) (Cost=4 Card=2 Bytes=44)
2 1 SORT (UNIQUE) (Cost=4 Card=2 Bytes=22)
3 2 UNION-ALL
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE)
5 4 INDEX (RANGE SCAN) OF 'T1_IDX' (INDEX)
6 3 FILTER
7 6 FAST DUAL (Cost=2 Card=1)

Спасибо за выяснение, будет ли использоваться индекс или нет!!! А не в курсе, в самом последнем postgresql-8.1 он все так же не будет использоваться? Ну и еще DB2 и SAPDB конечно интересно проверить..

Если честно, не думал что в этом постгре будет такая дикая кривизна с оптимизатором.. Была б моя воля, все бы под оракел переписали..

>INDEX (RANGE SCAN) OF 'T1_IDX' (INDEX)

Даа мля! Круто! При выборке из таблицы с 1 записью используется индех!!!

>Ну и еще DB2 и SAPDB конечно интересно проверить..

Небудет ни в DB2 ни в SAP-е.

>Даа мля! Круто! При выборке из таблицы с 1 записью используется индех!!!

У мля, гуру пришел. Гура, а гура, а пачиму ты решил что там одна запись?

> в самом последнем postgresql-8.1 он все так же не будет использоваться?

Subquery Scan v1  (cost=1.05..1.09 rows=1 width=12)
  Filter: (whendate > '2005-11-01 00:00:00+03'::timestamp with time zone)
  ->  Unique  (cost=1.05..1.07 rows=2 width=8)
        ->  Sort  (cost=1.05..1.06 rows=2 width=8)
              Sort Key: whendate, vv
              ->  Append  (cost=0.00..1.04 rows=2 width=8)
                    ->  Subquery Scan "*SELECT* 1"  (cost=0.00..1.02 rows=1 width=8)
                          ->  Seq Scan on t1  (cost=0.00..1.01 rows=1 width=8)
                    ->  Subquery Scan "*SELECT* 2"  (cost=0.00..0.02 rows=1 width=0)
                           ->  Result  (cost=0.00..0.01 rows=1 width=0)


на pgsql 8.1

> Спрашивал уже в другоп топике, но никто не ответил однозначно.
> Есть талица и есть view:
> create table t1(whendate datetime,vv int);
> create view v1 as select * from t1 union select now(),10;

отвечали уже в другом топике: создай вьюху с union all вместо union

>>Чуваки, расскажите, что за Томми такой, а то везде говорят, а я не понимаю, в чём прикол...

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

http://www.linux.org.ru/profile/Keiko/view-message.jsp?msgid=1109623

> отвечали уже в другом топике: создай вьюху с union all вместо union

Спасибо! Хм, не заметил значит ответ (наверно ответили когда новость уже с первой страницы ушла). Пробовал сейчас на pg-7.2.x с union all и таблицей с 3k записей - индекс не пользует.

> в самом последнем postgresql-8.1 он все так же не будет использоваться?

> Subquery Scan v1 (cost=1.05..1.09 rows=1 width=12) Filter: (whendate > '2005-11-01 00:00:00+03'::timestamp with time zone) -> Unique (cost=1.05..1.07 rows=2 width=8) -> Sort (cost=1.05..1.06 rows=2 width=8) Sort Key: whendate, vv -> Append (cost=0.00..1.04 rows=2 width=8) -> Subquery Scan "*SELECT* 1" (cost=0.00..1.02 rows=1 wid th=8) -> Seq Scan on t1 (cost=0.00..1.01 rows=1 width=8) -> Subquery Scan "*SELECT* 2" (cost=0.00..0.02 rows=1 wid th=0) -> Result (cost=0.00..0.01 rows=1 width=0)

Хм, индекс не используется. А есть ли возможность создать еще view union all вместо union?

#!/usr/bin/perl

foreach my $m (1..12) { foreach my $d (1..28) { foreach my $v (1..10) { print "insert into t1 values('2005-$m-$d',$v);\n"; } } }

А вверху код чтобы его в psql name-of-database через пайп загнать - и получить 3k записей. Чтобы оптимизатор не забил на индексы из-за малости таблицы. И для чистоты эксперимента надо еще выполнить

vacuum analyze t1;

чтобы статистика по распределению таблицы пересчиталась (чтобы не было отмазок что оптимизатор не имея инфы о распределении записей индексы не стал использовать).

Спасибо огромное заранее!

>Subquery Scan v1 (cost=1.05..1.09 rows=1 width=12)

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

test=> \set
VERSION = 'PostgreSQL 7.4.8 on i386-portbld-freebsd4.11, compiled by GCC 2.95.4'
AUTOCOMMIT = 'on'
VERBOSITY = 'default'
DBNAME = 'test'
USER = 'test'
PORT = '5432'
ENCODING = 'UNICODE'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
HISTSIZE = '500'
LASTOID = '0'
test=> \i test.sql;
CREATE TABLE
CREATE INDEX
INSERT
...
INSERT
sn=> VACUUM verbose t1;
INFO:  vacuuming "public.t1"
INFO:  index "t1_idx" now contains 20224 row versions in 63 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "t1": found 0 removable, 20224 nonremovable row versions in 100 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
test=> explain analyze select * from v1 where whendate > date '2005-11-01';
                                                               QUERY PLAN       
--------------------------------------------------------------------------------
---------------------------------------------------------
 Subquery Scan v1  (cost=3.12..3.19 rows=4 width=8) (actual time=0.182..0.182 rows=0 loops=1)
   ->  Unique  (cost=3.12..3.15 rows=4 width=8) (actual time=0.170..0.170 rows=0 loops=1)
         ->  Sort  (cost=3.12..3.13 rows=4 width=8) (actual time=0.159..0.159 rows=0 loops=1)
               Sort Key: whendate, vv
               ->  Append  (cost=0.00..3.08 rows=4 width=8) (actual time=0.129..0.129 rows=0 loops=1)
                     ->  Subquery Scan "*SELECT* 1"  (cost=0.00..3.06 rows=3 width=8) (actual time=0.049..0.049 rows=0 loops=1)
                           ->  Index Scan using t1_idx on t1  (cost=0.00..3.03 rows=3 width=8) (actual time=0.037..0.037 rows=0 loops=1)
                                 Index Cond: (whendate > '2005-11-01'::date)
                     ->  Subquery Scan "*SELECT* 2"  (cost=0.01..0.03 rows=1 width=0) (actual time=0.063..0.063 rows=0 loops=1)
                           ->  Result  (cost=0.01..0.02 rows=1 width=0) (actual time=0.038..0.038 rows=0 loops=1)
                                 One-Time Filter: (('now'::text)::date > '2005-11-01'::date)
 Total runtime: 0.359 ms
(записей: 12)

test=>

> Если бы он на 2 строках стал использовать индекс, можно было бы послать его в жопу. Правильно что не использует.

Имено. Более того, я практически уверен, что в его случае индекс будет _дороже_. Проверить легко -- отключить seqscan ;)

=> set enable_seqscan to 0;

ЗЫ. Рекомендую автору вопроса внимательно прочитать http://www.postgresql.org/docs/8.1/interactive/indexes-examine.html

Дорогой ты мой, и где такие шустрые как ты, водятся?

Видно, что ты реально ни IB, ни FB не видел даже (не говоря о том, чтобы с ними работать).

А скажи мне, родимый, какое серверное приложение масштаба хотя бы отдела обойдется без хранимых процедур, триггеров, транзакций и прочей полноценной SQL-функциональности (1С - отдельная тема, системой масштаба предприятия сие поделие назвать нельзя - оно идеально только для бухгалтерии)?

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

Ну и, конечно же, удобнее как в мускуле пользовать клиентские SQL-строки вместо хранимых на сервере процедур (готовых, откомпилированных и оптимизированных, с составленным планом выполнения, которым нужно только передать параметры)?

Конечно, для написания курсовых серьезная база не нужна - нафик? Так что, думай, прежде чем посты вставлять, студент.

ЗЫ: Единственный серьезный недостаток IB/FB, ИМХО, это то, что его никто не хостит в инете. А жаль.

поскольку перл не нужен :-D, накропал аналогичную конструкцыю на пхп.

результат с union:

Subquery Scan v1  (cost=286.09..353.31 rows=1120 width=12) (actual time=81.152..84.693 rows=551 loops=1)
  Filter: (whendate > '2005-11-01 00:00:00+03'::timestamp with time zone)
  ->  Unique  (cost=286.09..311.30 rows=3361 width=12) (actual time=64.301..78.091 rows=3361 loops=1)
        ->  Sort  (cost=286.09..294.49 rows=3361 width=12) (actual time=64.291..68.140 rows=3361 loops=1)
              Sort Key: whendate, vv
              ->  Append  (cost=0.00..89.22 rows=3361 width=12) (actual time=14.323..47.320 rows=3361 loops=1)
                    ->  Subquery Scan "*SELECT* 1"  (cost=0.00..89.20 rows=3360 width=12) (actual time=14.318..39.574 rows=3360 loops=1)
                          ->  Seq Scan on t1  (cost=0.00..55.60 rows=3360 width=12) (actual time=0.010..8.953 rows=3360 loops=1)
                    ->  Subquery Scan "*SELECT* 2"  (cost=0.00..0.02 rows=1 width=0) (actual time=0.056..0.060 rows=1 loops=1)
                          ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.049..0.050 rows=1 loops=1)
Total runtime: 86.279 ms 



и как выше советовали с union all:

Subquery Scan v1  (cost=0.00..131.23 rows=1120 width=12) (actual time=31.374..38.214 rows=551 loops=1)
  Filter: (whendate > '2005-11-01 00:00:00+03'::timestamp with time zone)
  ->  Append  (cost=0.00..89.22 rows=3361 width=12) (actual time=0.066..32.227 rows=3361 loops=1)
        ->  Subquery Scan "*SELECT* 1"  (cost=0.00..89.20 rows=3360 width=12) (actual time=0.063..22.656 rows=3360 loops=1)
              ->  Seq Scan on t1  (cost=0.00..55.60 rows=3360 width=12) (actual time=0.011..6.939 rows=3360 loops=1)
        ->  Subquery Scan "*SELECT* 2"  (cost=0.00..0.02 rows=1 width=0) (actual time=0.047..0.051 rows=1 loops=1)
              ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.041..0.042 rows=1 loops=1)
 
Total runtime: 39.075 ms 

mysql 5 тоже не пользует индексы, кстати.

Пасибо за контрпример.. Я пробовал отключать seq_scan, добавлять в таблицу 30k записей - индекс все равно не используется на postgresql-7.2.1 для линукс.. А у вас на 3х записях он аж используется.. А почему у Sergio тогда тоже он не используется? Может постгрес так настроено и скомпилен странно? У меня собранный для RH73..

Спасибо огромное за эти тесты!! А Вы откуда postgres брали - сами собирали? Если да - у configure никаких экзотических ключей не использовали? У меня стандартный 7.2.1 от RH73 :-)

triggers

> типа тригиров, процерур, представлений... Firebird... база...НАДЕЖНАЯ
ага - особенно умиляют generatots - "мы пойдём другим путём". абзац полный.
а по поводу надёжности - не единожды приходилось видеть зависшую базу (ну не умеет он под большой нагрузкой хорошо работать - проблемы с lock на gdb файлы были неоднократно) - это относится к виндовой версии.

у меня под оффтопиком. брал готовый с оф. сайта.

> Я пробовал отключать seq_scan

И как менялось время выполнения?

> А у вас на 3х записях он аж используется..

У меня '20224 nonremovable row versions in 100 pages'. И данные там "от балды".

> А почему у Sergio тогда тоже он не используется?

Значит дешевле так, проверь explain analyze сначала с enable_seqscan=1, потом 0.

> > Я пробовал отключать seq_scan

> И как менялось время выполнения?

На время не смотрел, смотрел на explain - index он не пользваол даже при 30k записях (и после vacuum analyze t1;, и после enable_seqs-scan=0, и после enable_seqs-scan=1).

Так у вас psql самосборный из портов? С какими опциями configure вызывался?

> Программы используют разные версии серверов? Если да то какие? Если нет - в чем проблема?

в том, что ни один банк в свою базу ни кого не пустит, а нормальных табличных пространств в FB нет

Попробовал еще на FC4 с ее стандартным psql 7.4.6, 30k записей, vacuum analyze делал, set enable_seqscan=0; делал, пробовал union all и union - пофигу..