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

КД>Ты лучше поинтересуйся у него "что такое большие проекты ?"
Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все. Больше преимуществ нет.

Не хочу спорить с т. Пацаком в очередной раз. Мою мотивацию он уже знает.

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

КД>>Ты лучше поинтересуйся у него "что такое большие проекты ?"
OLE>Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все. Больше преимуществ нет.

Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.

OLE>Не хочу спорить с т. Пацаком в очередной раз. Мою мотивацию он уже знает.

Ага. "Я попробовал и мне не понравилось".

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

П>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.
Классифицировать "крупность" проектов не берусь-требования очень разные.

П>Ага. "Я попробовал и мне не понравилось".
Не только "пробовал". Сопровождал довольно крупный продукт работающий с ФБ.

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

КД>>Ты лучше поинтересуйся у него "что такое большие проекты ?"
OLE>Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все.

Это типа ответ на заданный вопрос

Низачот.

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

КД>Это типа ответ на заданный вопрос
А ты типа экзамекн устроил?

КД>Низачот можешь на хлеб намазать.

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

П>>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.
OLE>Классифицировать "крупность" проектов не берусь-требования очень разные.

Однако при этом берешься классифицировать СУБД на "подходит/не подходит для крупного проекта" или "подходит/не подходит для биллинга", при этом не приводя никаких аргументов. Согласен с Дмитирием — сие не есть гут.

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

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

П>>>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.
OLE>>Классифицировать "крупность" проектов не берусь-требования очень разные.

П>Однако при этом берешься классифицировать СУБД на "подходит/не подходит для крупного проекта" или "подходит/не подходит для биллинга"

Ты еще споришь про биллинг?
Или будешь спорить, что для описанной задачи ФБ лучший выбор?
В обоих случаях это не так.

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

OLE>Или будешь спорить, что для описанной задачи ФБ лучший выбор?
Блин. Конечно же НЕ лучший. Опечатка

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

OLE>Ты еще споришь про биллинг?

Что значит "еще"? В прошлый раз никакого спора не было — ты просто отставился кучей минусов и ушел от ответа.

OLE>Или будешь спорить, что для описанной задачи ФБ лучший выбор?

Мои основные требования к базам:
1) Наличие графического интерфейса администрирования
2) Возможность удаленного администрирования с Windows машины
3) Удобное управление Триггерами
4) Процедуры
5) Временные таблицы аля MSSQL — select * into #tmp
6) Ну а также желательно схожий синтакс sql с mssql

1. IBExpert
   
2. IBExpert + services
   
3. ХЗ что имелось в виду, управление триггерами ИМХО достаточно удобное
   
4. Имеются
   
5. Нет, но как правило успешно заменяются "селективными" процедурами
   
6. Привычка — дело наживное

Итого: критичных противоречий не вижу. Учитывая, что сейчас выбор идет между MySQL и Postgresql — Firebird в этом ряду вполне конкурентоспособен. Sybase хорош схожестью синтаксиса, но он платный, что автоматически переносит его в другую весовую категорию. И?

OLE>В обоих случаях это не так.

И как всегда — без аргументов.

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

П>Итого: критичных противоречий не вижу. Учитывая, что сейчас выбор идет между MySQL и Postgresql — Firebird в этом ряду вполне конкурентоспособен.
Конкурентоспособен и не более. Postgresql таки пооптимальней будет, особенно если учесть:

Наша контора работает под MSSQL. В нем до 6 баз данных. В каждой из баз есть таблицы с кол-вом строк около миллиона. Работают с базами около 30 клиентских мест.

Сопровождать конструкцию на ФБ будет достаточно тяжело.

П>И как всегда — без аргументов.
Вспомним "правильные" бекапы?
И заодно отсутвие лога транзакций.

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

OLE>Конкурентоспособен и не более. Postgresql таки пооптимальней будет, особенно если учесть:
OLE>

OLE>Наша контора работает под MSSQL. В нем до 6 баз данных. В каждой из баз есть таблицы с кол-вом строк около миллиона. Работают с базами около 30 клиентских мест.

OLE>Сопровождать конструкцию на ФБ будет достаточно тяжело.

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

Кстати, вчера меня просветили относительно еще одной неотъемлемой состоявляющей решения сложных систем. Оказывается кроме "Оракла, Юникса и Дорогого Адо" требуется еще "Гетерогенный Доступ". Вот так вот. Смешно? А я весь вечер просидел в задумчивости.

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

OLE>Сопровождать конструкцию на ФБ будет достаточно тяжело.

Бездоказательная глупость. Сопровождают и поболее.

П>>И как всегда — без аргументов.
OLE>Вспомним "правильные" бекапы?

Это те, которые тебе хотелось "по F5 но не по F5, через gbak но не через gbak, по cron'у но не по cron'у и чтоб все само собой ап, и сделалось" ? Не, лучше не надо — смешно же! Кстати специально для таких вот привередливых в FB теперь есть инкрементальный бэкап — радуйся.

OLE>И заодно отсутвие лога транзакций.

...который нафик не упал.

Еще раз — какие-нибудь серьезные претензии к применимости FB в данном конкретном случае будут? Или все так и останется на уровне "нельзя и точка"?

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

OLE>>И заодно отсутвие лога транзакций.
П>...который нафик не упал.
П>Еще раз — какие-нибудь серьезные претензии к применимости FB в данном конкретном случае будут?

Ну вот как с тобой говорить? Ты не выгодные для себя аргументы просто с негодованием отметаешь
Я сказал все, что хотел — решать человеку.

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

OLE>Ну вот как с тобой говорить? Ты не выгодные для себя аргументы просто с негодованием отметаешь

Та ты чо?! Ну давай расскажи про лог транзакций, без которого не может работать архикрупная БД аж из миллиона записей. Примеры приведи, анализ. А потом посмотрим.

BTW — c бэкапом, судя по скипу, вопрос отпал?

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

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

П>архикрупная БД аж из миллиона записей.
Та ты чо?! А покажи, где сказано про то, что в базе есть миллион записей? Сказано:

В каждой из баз есть таблицы с кол-вом строк около миллиона

Вопрос: сколько таблиц в базе имеют миллион записей?

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

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

П>>Та ты чо?! Ну давай расскажи про лог транзакций, без которого не может работать
OLE>Работать может. Надежность снижается.

А мужики-то не знают! Ну давай расскажи теперь как она снижается.

OLE>И, в случае сбоя, восстанавливать сложнее.

В случае физической порчи БД — практически однофигственно.

OLE>Вопрос: сколько таблиц в базе имеют миллион записей?

Да хоть все — каким боком тут лог транзакций? Он что, сильно зависит от таблиц с миллионом записей? А я грешным делом думал, что от количества записей, которые затрагивают транзакции.

OLE>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива.

Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то":

1. Не лазить напрямую в метаданные кривыми ручонками.
   
2. Проверять (автоматически) сделанный бэкап на восстановимость
   
3. Юзать наряду с gbak'ом nbackup

И все! Ваши волосы тотчас же станут густыми и шелковистыми. (с) Но это конечно безумно сложная процедура — никак не под силу программисту "больших БД"!

OLE>И про то, как делать ф5 при неотключенной (использующейся) базе.

Покури уже наконец насчет инкрементального бэкапа, а то скучно с тобой разговаривать становится.

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

П>А мужики-то не знают! Ну давай расскажи теперь как она снижается.
П>В случае физической порчи БД — практически однофигственно.
А давай вырубим серверок во время физической записи транзакции ФБ и, допустим, Postgre? А потом рассмотрим шансы и время на восстановление базы, максимально актуального состояния.

П>Да хоть все — каким боком тут лог транзакций? Он что, сильно зависит от таблиц с миллионом записей? А я грешным делом думал, что от количества записей, которые затрагивают транзакции.
Это условие тоже не оговорено в задаче. Какова активность транзакций? Ты не знаешь. А предполагаешь что-то свое. Причем заниженное.

OLE>>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива.
П>Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то":
П>

П>
1. Не лазить напрямую в метаданные кривыми ручонками.
   П>
2. Проверять (автоматически) сделанный бэкап на восстановимость
   П>
3. Юзать наряду с gbak'ом nbackup
   П>

Ты упустил еще один пункт:
— Не использовать ФБ в подобных задачах. Благо альтернатив полно.

OLE>>И про то, как делать ф5 при неотключенной (использующейся) базе.
П>Покури уже наконец насчет инкрементального бэкапа, а то скучно с тобой разговаривать становится.
Я все это знаю. Но ты мне напоминаешь СГ в некоторых своих миссионерских порывах. Не всюду ФБ затычка.

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

OLE>А давай вырубим серверок во время физической записи транзакции ФБ и, допустим, Postgre? А потом рассмотрим шансы и время на восстановление базы, максимально актуального состояния.

Давай. Сперва о шансах: ты гарантируешь, что после этого база Postgresql самовосстановится в 100 случаев из 100? Если нет и произойдет таки физический краш — ты готов сравнить время восстановления из shadow/nbackup/gbak firebird и погзипленного скрипта постгреса?

OLE>Это условие тоже не оговорено в задаче. Какова активность транзакций? Ты не знаешь. А предполагаешь что-то свое.

Ты тоже. Причем в отличие от меня — совершенно неаргументированно и безапеляционно.

OLE>Ты упустил еще один пункт:
OLE>- Не использовать ФБ в подобных задачах. Благо альтернатив полно.

Щастя нет — при достаточно малом радиусе кривизны рук (а чтоб при использовании FB не следовать поскипанным пунктам — он должен стремиться к нулю) можно заставить хреново работать любую СУБД (да и вообще любую сложную систему). Я знаю пример когда постгрес (который ты тут так усиленно расхваливаешь) полдня крутил restore базы данных, которая по идее должна быть online круглосуточно. И знаю другой пример, когда он посреди ночи выжрал 100% ресурсов и фактически застопорил работу системы, о чем стало известно только утром. Но я, в отличие от тебя, не кричу по любому поводу на весь форум "постгрес — г....", а стараюсь решать эти локальные проблемы локальными же средствами. И знаешь, как правило удается.

OLE>Я все это знаю.

То есть то, что ты тут пишешь — есть предумышленная провокация, расчитанная на неосведомленность оппонента? Круто, ничего не скажешь!

OLE>Но ты мне напоминаешь СГ в некоторых своих миссионерских порывах. Не всюду ФБ затычка.

Я, в отличие от, про "всюду" нигде не писал и не пишу. Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне, ничуть не хуже рассмотренных постгре и мускуля. А делать глобальные выводы на основании представления о сферических "больших БД" в вакууме — уволь, не тянет совершенно. Это уж как-нибудь сам.

П>Я, в отличие от, про "всюду" нигде не писал и не пишу. Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне, ничуть не хуже рассмотренных постгре и мускуля. А делать глобальные выводы на основании представления о сферических "больших БД" в вакууме — уволь, не тянет совершенно. Это уж как-нибудь сам.

у fb куда не ткни везде какая-то херня — sql кривой (http://rsdn.ru/Forum/Message.aspx?mid=573511&only=1

Автор: Sinclair
Дата: 18.03.04

), оптимизатор кривой (cost based поломали теперь так и остался rule based), лога нет (drop table сделал и все никакие бэкапы не помогут, т.к. нельзя востановится на момент времени до сбоя) и т.п.

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

П>Но я, в отличие от тебя, не кричу по любому поводу на весь форум "постгрес — г....", а стараюсь решать эти локальные проблемы локальными же средствами. И знаешь, как правило удается.
Покажи, где я говорил, что ФБ — г....?

П>То есть то, что ты тут пишешь — есть предумышленная провокация, расчитанная на неосведомленность оппонента? Круто, ничего не скажешь!
Это не провокация. Это просто другое мнение, которое ты ну никак не хочешь признать, а только размахиваешь флагом. Но ведь есть проблемы в этой области. Ну признайся.
А руки... Если сопровождать закрытый софт... Ну и при чем тут руки то?

П>Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне

А мое ИМХО-не подходит.