> У нас вон в одном филиале сервер с FB 1.0.3 в качестве СУБД просто сперли. Высадили окно и фюить ;-) Не было бы в сейфе диска со позавчерашним бэкапом (вчерашний остался на компе, отложили на утро списать на болванку), забивали бы ручками c момента основания ;-)

Гы ! Ну молодец! Я вот 80Gb оракловую базу еженочным логическим бэкапом выгружаю сразу на 2 машины (это кроме standby), а вам в лом было ? Ну так и расхлебывайте сами. И две ФБ-шные базы также логически экспортируются и тиражируются. +критически важная информация раз в час переносится в другую БД и способная восстановить информацию ежели придется возвращаться к вчерашнему бэкапу ...

>Я вот 80Gb оракловую базу еженочным логическим бэкапом выгружаю сразу на 2 машины

Пипиську спрячь, ага? Нету у меня задач, где бы потребовался оракл. И база до 80 гиг не дойдет никогда.

Из четырех компов еще один стэндбай, и еще один в резерв? Тем более, что это не помогло бы - сперли _ВСЕ_ :-)

Grue

>> Ути пуси - вон Access или FoxPro пользуется в сотни (в то и в тысячи) раз больше компаний - и что, оне от жтого стали _хорошими_ СУБД???? :)

Ваше имя Катя Лель? Цифры тоже она приведёт? (а то стотыщьмильёнов - это к Карлсону).

>> анных может быть 10 мегабайт, но за их исчезновение или недоступность в течении двух минут dba прилюдно проведут процедуру кастрации

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

10гигов fb - это совсем не 10 гигов оракла. у fb это индексы+данные+версии данных+немного пустого места (на вырост, но действительно немного).

>> зеркала пишется мусор, а при востановлении хотя бы на вчера выясняется что gbak

а ещё прилетают марсиане.... грязь - у вас в постах

Пиписька мерщики можете подсказать как вы размер баз меряете ? да ещё с разных БД ? :D :D Переносили базу она занимала больше 30 гиг. Оракл. Когда его через imp без индексов и статистика сымпортили ( правда его потом ещё и сжали в bz2), размер стал 25 _метров_. Можете дальше продолжать чудо сравнение размеров. :D :D

>> вообще я считаю это еще и единственым средством в ФБ :) очень часто после сбоев питания в базах fb вообще ничего делать не надо - оно продолжает работать. В отличии от MySQL. С Постгре я такого не проводил - на той машине дох БП, но к базе тогда никто не обращался (сдох он ночью, в паузе между cron-скриптами, а человеки в это время вообще спали). Оракл тоже не подвергался насилию - тут ничего сказать не могу. Вот MSSQL 7(?) выдержал отвал питания и смерть raid-контроллера, но не факт что в этот момент были обращения к базе (скорее всего нет).

>> невостановимый бэкап (в ужасе) где? за много лет использования (ib 5.0 -> Yaffil 892) ни разу не видел. Только слышал, но там какая-то экзотика была.

>> отсутсвие лога не надо

>> глючащий SQL эротические фантазии.

>> БД с недостками круче я заню только фокспро перестаём путать БД и СУБД

я дурак что в своё время начал проэкт на fb ... к чему притензии: 1. ограниченность SQL (включая возможности языка ХП) 2. планы запросов меняються от версии к версии 3. непонятные глюки (помогает рестарт сервера) 4. smp некудышное 5. 1.5.x не компилиться c gcc 4.х.х 6. слабая поддержка fb в php 7. исходники в таком виде, что чёрт ногу сломит

может что и поменялось в fb2 ... но тестить не буду ... надаело .. нах этот fb

В обшем у меня всё готово для перехода на пострегрес, после нового года перееду окончательно ...

Господа, возникла задача слабать кривую поделку на PostgreSQL, посему два вопроса: 1) где есть нормальные доки по тюнингу параметров самой БД? Нормальные доки это примерно то, что лежит на оракловом металинке.

2) В чем базу девелопить по PostgreSQL? Не в pgadmin3 же

> к чему притензии: 1. ограниченность SQL (включая возможности языка ХП)

А теперь подробнее - что именно не удалось сделать с его помощью.

> 2. планы запросов меняються от версии к версии

Дык епт! Оптимизатор-то улучшают. И какой-то особой проблемы тут не вижу - постгрес вон вообще без изменения версии может план поменять, причем в ранних версиях зачастую менял на такой, что пятиминутный запрос начинал крутиться часами.

> 3. непонятные глюки

Барабашка, не иначе. :)

> 4. smp некудышное

Зато хороший суперсервер.

> 5. 1.5.x не компилиться c gcc 4.х.х > 7. исходники в таком виде, что чёрт ногу сломит

Не надо лезть работать с сорцами, если лень в них разбираться.

> 6. слабая поддержка fb в php

А, ну да - это FB виноват конечно. :)

> В обшем у меня всё готово для перехода на пострегрес

В общем как обычно - попробовал одно, поковырялся немного, не понравилось, попробовал другое, поковырялся немного, не понравилось, попробовал третье... Удачи тебе в этом творческом процессе! :)

> можете подсказать как вы размер баз меряете

Единственно возможным способом - размер файла (файлов) базы. Это тот объем данных, который физически лопатится СУБД.

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

Grue

размер базы

Паковать ее зипом с известными параиметрами и сравнивать результат :). Главное, чтобы блобов с картинками не было в базе.

Тогда уж паковать файл бэкапа

> 2) В чем базу девелопить по PostgreSQL? Не в pgadmin3 же

А что с ним не так?

Он элементарно связи между таблицами наглядно отобразить сможет? А PL/Python синтакс подсветит/отформатирует? Мне б хотя бы это.

> А что с ним не так?

1. Виснет при параллельном выполнении >1 запроса 2. Не поддерживает gpm 3. Вылетает при копи-пасте

>А теперь подробнее - что именно не удалось сделать с его помощью.

Навскидку вспомнил на что сам напоролся:

1. невозможность динамического формирования эксепшинов для возврата клиенту

2. невозможность тихого прерывания выполнения триггерра INSERT\UPDATE без костылей типа new.value = old.value

3. невозможность выполнить динамически формируемое sql предложение в функции

4. перекодировка на лету для разных клиентских кодировок

5. ... забыл ...

> Барабашка, не иначе. :)

Барабашка обеспечил 2-х часовой простой нескольких отделов. Кто завёл барабашку в FB ?

> Зато хороший суперсервер.

Ну да самое простое раскидывать по процессорам процессы средствами OC, а сами мы это делать не умеем.

> Не надо лезть работать с сорцами, если лень в них разбираться.

Если ты в них не разобрался это твои сексуальные проблемы.

> А, ну да - это FB виноват конечно. :)

Я виноват раз правлю сам код PHP для корректной работы с FB.

>В общем как обычно - попробовал одно, поковырялся немного, не понравилось, попробовал другое, поковырялся немного, не понравилось, попробовал третье... Удачи тебе в этом творческом процессе! :)

Спасибо. Тебе же пожелаю оставаться на FB. Удач.

>Господа, возникла задача слабать кривую поделку на PostgreSQL, посему два вопроса: 1) где есть нормальные доки по тюнингу параметров самой БД? Нормальные доки это примерно то, что лежит на оракловом металинке. 2) В чем базу девелопить по PostgreSQL? Не в pgadmin3 же

1. Тюнинг параметров при разработке кривой поделки необязателен ... а так если уж поделка превратится в пердерку ентерпрайз уровня то инфу по тюнингу легко можно найти в сетке ... )))

2. Как не странно Pg доки на сайте и дистре вполне приличные.

3. Нах тебе pgadmin ? ты чё psql не осилил ?

И вообще чем тебе FB не устраивает ? ... Для кривых поделок он вполне подходит.

> Пиписька мерщики можете подсказать как вы размер баз меряете ? да ещё с разных БД ? :D :D Переносили базу она занимала больше 30 гиг. Оракл. Когда его через imp без индексов и статистика сымпортили ( правда его потом ещё и сжали в bz2), размер стал 25 _метров_. Можете дальше продолжать чудо сравнение размеров. :D :D

А если этот тарболл ещё и удалить, то база вообще ничего занимать не будет!

> А если этот тарболл ещё и удалить, то база вообще ничего занимать не будет!

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

:) > 1. невозможность динамического формирования эксепшинов для возврата клиенту

Вранье. Я это успешно делал еще в IB6.0 - когда это делалось неофициально. > 2. невозможность тихого прерывания выполнения триггерра INSERT\UPDATE без костылей типа new.value = old.value

Наконец-то автор чудного пожелания стал известен! Про эксцепшны внутри триггеров и про обработку тебе уже твердили, но без толку. Повторяться не стану.

> 3. невозможность выполнить динамически формируемое sql предложение в функции

а. Это с фига ли невозможно??? А EXECUTE STATEMENT что, использовать нельзя? б. Что для Вас есть функция в FB? :)

> 4. перекодировка на лету для разных клиентских кодировок

Это да, что в FB положишь, то и возьмешь :) :) :)

> 5. ... забыл ...

Слив по 4,5 пунктам. Остальное - следствие предыдущего.

Постгре Вам поможет, угум. Я могу влет несколько багофич постгре назвать, от которых вам плохо станет. Тем не менее я его использую с удовольствием. Как и FB. Попробуйте меньше на LRU торчать, книжек читать побольше, лесных орехов для мозга, прогулки по свежему воздуху, то да се...

>Слив по 4,5 пунктам. Остальное - следствие предыдущего.

>Постгре Вам поможет, угум. Я могу влет несколько багофич постгре назвать, от которых вам плохо станет. Тем не менее я его использую с удовольствием. Как и FB. Попробуйте меньше на LRU торчать, книжек читать побольше, лесных орехов для мозга, прогулки по свежему воздуху, то да се...

Все неправильно. Нужно говорить "на LORе", а не на "LRU".

>3. Нах тебе pgadmin ? ты чё psql не осилил ?

разрабатывать в psql? Как такое возможно вообще :)

2 I_one

Почитал Ваши эссе на sql.ru

http://www.sql.ru/forum/memberinfo.aspx?mid=24047

Вы на постгре не переходите. Сразу на Оракл.

Бугага.

> 1. невозможность динамического формирования эксепшинов для возврата клиенту

EXCEPTION E_MYEXCEPTION 'Динамически сформированный эксепшин'

> 2. невозможность тихого прерывания выполнения триггерра INSERT\UPDATE без костылей типа new.value = old.value

IF(RDB$GET_CONTEXT('USER_SESSION', 'DISABLE TRIGGER') IS NULL) THEN ...

> 3. невозможность выполнить динамически формируемое sql предложение в функции

EXECUTE STATEMENT

> 4. перекодировка на лету для разных клиентских кодировок

Еще этим идиотизмом нагружать сервер... Но если идиотизм неизбежен - пишется UDF или что-то такое есть в rfunc

> 5. ... забыл ...

И это тоже. Итого из пяти пунктов видно только неумение пользоваться выбранным инструментом. То же самое будет и при пережоде на любую другую СУБД, так что даже и пробовать не стоит...

>IF(RDB$GET_CONTEXT('USER_SESSION', 'DISABLE TRIGGER') IS NULL) THEN ...

По-моему, не в тему. Афтару "I_One" нужно было в триггере "before" прервать операцию. Шоб эксцепшн на клиента не вываливался.

Короче - эротические фантазии I_One по поводу реализации бизнес-логики не нашли отражения в ФБ как инструменте.

Вспомнился 1986 год, июль, Юрмала. Кафешка под открытым небом. Рядом очередь в пункт приема стеклотары. Я наблюдаю картину: мужик принес банки из-под растворимого кофе и устроил скандал, что их не хотят принимать. Клянусь, я видел это сам.

...а вы говорите: "постгре", "файрбёрд"... :)

> 1. невозможность динамического формирования эксепшинов для возврата клиенту

На хрена?

> 2. невозможность тихого прерывания выполнения триггерра INSERT\UPDATE без костылей типа new.value = old.value

Это не костыли, а стандартная возможность вернуть все на круги своя. Вторая не менее стандартная возможность - выбросить эксепшн, после чего молча прожевать его клиентом. Уговор же был говорить про то, что следать невозможно в принципе, а не про "не нравится". Так что низачот.

> 3. невозможность выполнить динамически формируемое sql предложение в функции

Для одиночного выражения в полуторке был execute statement, для множества операторов недавно появился execute block. Так что брехня.

> 4. перекодировка на лету для разных клиентских кодировок

Не есть задача сервера. Никто кроме клиентского приложения лучше не знает, что и в какой кодировке он хочет получить. В любом случае FB тут не уникален, так что с тем же успехом можно было вспомнить, что его SQL не играет в шашки и не варит кофе.

>> Не надо лезть работать с сорцами, если лень в них разбираться.

> Если ты в них не разобрался это твои сексуальные проблемы.

Я на них не жаловался, жаловался ты.

> Я виноват раз правлю сам код PHP для корректной работы с FB.

Молодец, сообразил. Еще немного постараешься - и сообразишь выслать багфикс разработчикам... нет, не FB, а того пхпшного кода, в котором ковырялся.

> Барабашка обеспечил 2-х часовой простой нескольких отделов. Кто завёл барабашку в FB ?

Как пить дать ты же и завел.

> http://rsdn.ru/Forum/Message.aspx?mid=573511

Читаю этот тред, чтобы понять для себя нужно ли вообще мне смотреть в
сторону FB. После этого линка я в шоке!


> Некоторые программы на фортране работают уже с пол века (я одну с 35
> летним стажем знаю - ее до сих пор пользуют). Но это вовсе не повод
> сейчас писать на f77.

+1


> Я, например, делал проекты на DBase, Paradox, Acces, FoxPro,
> PostgreSQL, FB, IB, Oracle, MySQL, SYBASE, MS_SQL и др.

Не верю что это были значимые проекты. Чтоб профессионально освоить эти все технологии нужно учиться лет 20. Либо второй вариант -- совсем не разбираться в них и верить, что всё знаешь.

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

>Единственно возможным способом - размер файла (файлов) базы. Это тот объем данных, который физически лопатится СУБД.

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

То, что получилось после утилиты типа pg_dump с архивированием? Интересен ведь именно объём данных, а не то, что там база лопатит.

Хотя это тоже не корректно, так как блобы портят всю картину :(

> разрабатывать в psql? Как такое возможно вообще :)

Таблицу там создать можно, explain есть, help встроенный - что ещё для счастья надо :)

Естественно зависит от сложности проекта.

> После этого линка я в шоке!

Сюда еще посмотри

http://rsdn.ru/poll/Vote.aspx?pid=1665

> Интересен ведь именно объём данных, а не то, что там база лопатит.

А если еще добавить ограничение "объем _полезных_ данных"? Особенно "полезных для меня"? ;-) Мы же в данном контексте сравниваем движки СУБД, а собственно чистую информацию в базе. Даже если во всех таблицах NULLы, одни нуллы, триллионы нуллов, и никакой информации - серверу все равно надо каким-то образом по ним пробежаться, хотя бы чтобы сказать: "Дурак! У тебя пустая база!".

Так что продолжаю считать, что наиболее корректная из возможных некорректных оценок - размер файла базы ;-)

Grue

> > http://rsdn.ru/Forum/Message.aspx?mid=573511 > Читаю этот тред, чтобы понять для себя нужно ли вообще мне смотреть в сторону FB. После этого линка я в шоке!

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

Вот тебя не шокирует, что условие if(2.0*2.0==4.0){} запросто может оказаться ложным? И есть ли это повод отказываться от плавающей арифметики? ;-)

Grue

>Вот тебя не шокирует, что условие if(2.0*2.0==4.0){} запросто может оказаться ложным? И есть ли это повод отказываться от плавающей арифметики? ;-)

в данном случае if(2.0*2.0==5.0){} и это повод облить грязью и отказатся от FB, SQL это декларативный язык, там от порядка ничего зависеть не может по определению. ниодна из бд (надеюсь в курсе что фоспро не субд ) подерживающих entry level sql92 такой порнографии не допускает.

Minotauros.

>Не верю что это были значимые проекты. Чтоб профессионально освоить эти все технологии нужно учиться лет 20. Либо второй вариант -- совсем не разбираться в них и верить, что всё знаешь.

Я занимаюсь разработками в области БД уже как 16 лет.

> ниодна из бд (надеюсь в курсе что фоспро не субд ) подерживающих entry level sql92 такой порнографии не допускает.

Такой не допускат зато другую допускает. Один только NULL=='' в оракле чего стоит...

>постгрес вон вообще без изменения версии может план поменять

дай дураку в руки Genetic Query Optimizer, он и его сломает и руки порежет (с)

>дай дураку в руки Genetic Query Optimizer, он и его сломает и руки порежет (с)

будешь смеятся, но это истиная правда, был у FB когда-то cost based optimizer, работал уева и они забацали туда пару костылей (правил), потом еще пару, а потом ... оптимайзер поломался и сидят они теперь на какой-то помеси rule based и cost based, а поченить уже невозможно :)

Minotauros.

> Один только NULL=='' в оракле чего стоит...

Можно поподробнее?

> был у FB когда-то cost based optimizer

Вранье. У __FB__ - никогда не было.

>> Один только NULL=='' в оракле чего стоит...

> Можно поподробнее?

Куда уж подробнее - проверка пустых строк на is Null дает true, забивая при этом большой болт на ожидания пользователей и соответствие стандарту.

>Вранье. У __FB__ - никогда не было.
какая разница как FB в тот момент назывался (а назывался interbase4), главное что опимизатор гавно, как с точки зрения архитектуры так и по результату.

> Один только NULL=='' в оракле чего стоит...
да это конечно БАГ :)

к стате у меня вопрос к фанам ибейза, по ФБ вообще существует документация ? или пара гвайдов от интербейз это все что есть ?

Minotauros.

> какая разница как FB в тот момент назывался

Разница большая - никто тут не вспоминает постгрес версии этак третьей, хотя вспомнить там наверняка можно много чего. В том числе и в оптимизаторе, который, при всей его интелектуальности например только недавно научился понимать, что связь int8 <--> int4 может строиться с участием индекса. Надо сравнивать сравнимое. Сегодняшний файр и без cost based оптимизатора работает довольно шустро, а что там вытворял борланд с его предшественником - это давно поросло темным лесом.

>> Один только NULL=='' в оракле чего стоит... > да это конечно БАГ :)

Это расхождение со стандартом, так же как и описанное по ссылке поведение FB на вложенных запросах. Багом это было бы если б результат запроса был непредсказуемым или невоспроизводимым, а это не так. Причем если пути обхода проблемы в файре давно известны, то заставить оракл считать пустую строку чем-то отличным от нулла - задача, скажем так, довольно нетривиальная.

> к стате у меня вопрос к фанам ибейза, по ФБ вообще существует документация ? или пара гвайдов от интербейз это все что есть ?

Чего конкретно тебе не хватает?

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

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

Вообще в Оракле есть на что гнать, но только вот не на это. А вот то описание по линку, как себя ведёт ФБ с вложенными запросами, -- это не только в стандарт не вписывается, но и вообще в нормальную логику.

И людей, которые при наличии в наше время стольких достойных БД собираются использовать ФБ для чего-то отличного кроме как поддержка уже существуюжейго софта, заточеного под ИБ, я вообще понять не могу.

> А как строка может быть пустой? Она либо есть, либо -- NULL.

Стандарт считает иначе. И это правильно, т.к. null - это вообще-то не "пустое значение", а "неизвестное значение", не идентичное ни одному из возможных значений домена. Как кто-то в свое время ехидно заметил на sql.ru - <<верный русский перевод слова "null" - не "нуль", а "ХЗ">>. А ХЗ - это не пустая строка, это вообще ни одна из строк. Так, например, все операции с ним, кроме is null и булевых должны давать null, в том числе и конкатенация, тогда как результат конкатенации с пустой строкой должен давать исходную строку. Аналогично со сравнением на равенство/неравенство: (null=null)=>false тогда как (''='')=>true. И это не мелочи - если в одиночном запросе подобные косяки еще более-менее легко замечаются, то в процедурах, особенно иерархических с ними можно протрахаться довольно долго.

> А вот то описание по линку, как себя ведёт ФБ с вложенными запросами, -- это не только в стандарт не вписывается, но и вообще в нормальную логику.

Зависит от привычки. Те, кто в курсе про подобное поведение файра в эту ловушку уже практически не попадаются. Точно так же, как и в оракловую с nullами. Но опять же повторю: обходится эта ситуация очень просто и никого из FB-разработчиков особо не волнует. Вообще говоря этому "отклонению от стандарта" уже тысяча лет - возникло оно когда еще никакими стандартами на SQL даже и не пахло. И за все это время не было ни массового ухода пользователей, ни демонстраций протеста. Истерики же по этому поводу закатывают как правило либо совсем оголтелые противники файра, работавшие с ним на уровне "где-то слышал" и "попробовал - не получилось", либо такие же оголтелые фанатики альтернативных СУБД, занимающиеся обычным калометанием.

> (null=null)=>false

Прогнал. (null=null)=>unknown конечо Но суть дела от этого не меняется.

хех а я бы как раз заметид что (null=null)=>false было бы правильнее и именно так в oracle -> это к вопросу о null и уникальных индексах ib/fb

> хех а я бы как раз заметид что (null=null)=>false было бы правильнее

"Было бы" - это одно, а "есть в стандарте" это другое.

а ссылочку на стандарт и конкретно это не подскажете? после oracle и sql server исключительно такое поведение оказалось не ожиданным