Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hi Alexey Kovyazin реализации серверной логики (языки, хп, инструменты разработчика) Лично ткнувшись носом, вараинтк ак в тригере прерать выполнения запроса, в котором он исполнаяется http://forums.mysql.com/read.php?99,43881,94952#msg-94952 И тутже http://forums.mysql.com/read.php?99,99214,99300#msg-99300 Т.е. мелочей коотрые могут подпортить жизнь много :-) WBR Evgeny Putilin.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, freemanzav! You wrote on Mon, 02 Oct 2006 22:24:21 -0700: f Вот что говорит по этому поводу Jim Starkey f http://www.firebirdnews.org/?p=715. Это ведь не сегодня (и не вчера) сделанное открытие. И выводы сделаны не совсем в тему. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixangry_dogtndottobdotru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Eugene wrote: Alexey Popov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Классик - в печку. Руки прочь от классика! Вот что говорит по этому поводу Jim Starkey http://www.firebirdnews.org/?p=715. Он говорит, что если все останется как есть, то капец FB, и что его типа задавят
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
freemanzav wrote: Вот что говорит по этому поводу Jim Starkey Не читайте на ночь советских газет (с) Он говорит, что если все останется как есть, то капец FB, и что его типа задавят Уход от останется как есть не есть смерть классику, даже в его интерпретации. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov ... Fynda wrote: я слегка бухой и мало-мало расстроеный Надо было в баню идти :-) слово быстро по отношению к этому процессу имхо даже _рядом не лежало_ Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно тормозной. Но у них есть и более другие способы. Например, у PG: http://www.postgresql.org/docs/8.1/interactive/backup-online.html Мигрировать с 7.4 на 8.1 он позволяет ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Мигрировать с 7.4 на 8.1 он позволяет ? Это несколько другая задача, ее AFAIK ни одна СУБД не решает быстрым бекапом, про который шла речь выше. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov wrote: я слегка бухой и мало-мало расстроеный Надо было в баню идти :-) Мну не мог, по причинным объективам. слово быстро по отношению к этому процессу имхо даже _рядом не лежало_ Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно тормозной. Но у них есть и более другие способы. Например, у PG: http://www.postgresql.org/docs/8.1/interactive/backup-online.html Это я видел (хотя до сих пор не использую - каюсь), но боюсь что при переходе с одной мажорной версии на другую такое не прокатит - формат-то у базы наверняка поменялся за это время. Так что приходится скриптами на всякий случай, через вот такие тормоза и грабли :( . PS. Кстати, раз уж пошла такая пьянка - а создание redo-лога в каком-либо виде в fb вообще планируется?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Самая последняя закоммиченная. Т.е. так которая должна быть в базе при сносе сервера. При этом не хранить указатели на предыдущие версии. Не, так не пойдёт. Распиши что и как сохранять на примере с 3-мя тр-циями, каждой из которых видна своя версия Стартует первая транзакция и обновляет запись. Версия пишется в память. Стартует вторая транзакция делает селект. Как обычно. Первая транзакция коммитится. При этом запись из файла переносится в память, а из памяти пишется на диск. и т.д. Чем вр.файл отличается от основного ? Тем что версии не разманы по всему файлу бд. И могут чистится по коммитам без свипа. А с какой стати они не будут размазаны по вр.файлу ? Или для каждой тр-ции и каждой таблицы - свой файл ? Количество версии обычно должно быть намного меньше чем обычных записей в БД. Поэтому для аналоги свипа достаточно будет обработать этот временный файл небольших размеров. Сборка мусора удаляет не только старые версии записей, она также удаляет ненужные блобы и ключи индексов С индексами конечно есть проблема. Сейчас версии тоже вставляются в индекс. Если их не вставлять то надо как решить проблему выборки незакоммиченных версий. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun ... Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Он первый начал :) Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Так он и так шарится - через кеш FS :))) Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Не вымрет. Хотя бы потому, что это полуготовое кластерное решение -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Надеюсь, я таки вымру раньше. У классика, окромя распараллеливания, есть ещё одно интересное свойство - умирать в случае чего скромненько, не утягивая за собой остатние полторы сотни коннектов. И никакое увеличение борзодействия меня лично не заставит забыть об этой маленькой радости. А также он имеет реальные перспективы для работы в кластерах. После соответсвующей доводки напильником. Такшта кто там тупик и кто быстрее вымрет на фоне бурного развития возможностей железа параллельно с развитием тормознутости осей и сложности задач, это мы ещё будем посмотреть. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: у которых кэш между коннектами не шарится Кролики - это не только ценный мех (с) А независимый кеш - отнюдь не обязательный атрибут классика, в общем случае. Из преимуществ классика можно назвать лучшую защиту от сбоев и потенциальную кластеризуемость. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun пишет: Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. А с точки зрения сетевой безопасности порождающиеся под чутким надзором xinetd экземпляры классика мне наиболее симпатичны, чем постоянно существующий в одном экземпляре суперсервер. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad пишет: Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Может и ни при чем. Но такая вот особенность в FB CS имеется. Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Не сразу, а медленно и постепенно :) Так он и так шарится - через кеш FS :))) А мог бы шариться еще эффективнее и умнее. Со всякими там новомодными методиками вытеснения страниц, с опцией cache warming для особых эстетов и т.п. Кстати, если рассматривать потенциальную возможность того, что в FB будет шифрование, то в таком варианте кэш FS ну никак не поможет. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Не вымрет. Хотя бы потому, что это полуготовое кластерное решение Ну, в общем-то с таким вариантом и с доводом надежности не поспоришь. Да собственно против архитектуры я ничего не имею. Я имел в виду именно сочетание распараллеливания и общего кэша.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov пишет: всякими там новомодными методиками вытеснения страниц Которые постгрес который год тасует в попытках убежать от патентного права :-) Тяжелый случай. Способ потребления кислорода человеком под названием дыхание случайно никто еще не запатентовал? Надо бы подсуетиться...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun ... Horsun Vlad пишет: Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Может и ни при чем. Но такая вот особенность в FB CS имеется. Дык - мало ли у него ещё особенностей. Но выбрал ты именно эту :) Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Не сразу, а медленно и постепенно :) Ага, так и запишем ;) Так он и так шарится - через кеш FS :))) А мог бы шариться еще эффективнее и умнее. Эффективнее - между разными процессами, по сравнению с центральным управлением ? Не факт - накладные расходы на межпроцессную синхронизацию могут съесть все остальные полученные выгоды Со всякими там новомодными методиками вытеснения страниц, Ты плохо думаешь о современных FS :) с опцией cache warming для особых эстетов и т.п. Эстеты пока отдыхают :) Кстати, если рассматривать потенциальную возможность того, что в FB будет шифрование, то в таком варианте кэш FS ну никак не поможет. Это зависит от накладных расходов на шифрование. Которое, между прочим, опционально. Я не большой любитель классика, да и гемору он нам конечно прибавляет, но у него есть достаточное кол-во плюсов чтобы его не выкидывать -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun писал(а): Kovalenko Dmitry пишет: Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по родным компонентам прямого доступа. Все советуют native А такое разнообразие одних только ODBC драйверов наводит на мысль, что это не от хорошей жизни. Чисто интуитивно напрашивается мысль: пишут все кому не лень, потому что не устроило то, что нашли. А были бы эти драйвера в комплекте, многие и не заморачивались бы больше ничем. Да хрен с ним, с разнообразием. Оно вообщем-то уже устаканившееся. Нужно расставить приоритеты (У Кузьменко, слава богу, с этим все нормально). А еще желательно указавать дату, когда продукт последний раз обновлялся - с OLEDB тут вообще все просто ZStyle в начале 2004, SIBProvider - в середине 2003. Вартона вообще выкинуть из списка. Я уважаю его IBO, но я так ни разу и не увидел этот его OLEDB-провайдер в живую. Насчет поставки компонент в составе сервера. Я помню эта тема мусировалась в контексте Yaffil. Дальше дело не пошло. Может мы были жадными, может это просто ... никому не надо было - это уже не важно. Есть мысли по этой теме ? - давайте обсудим 14 октября. Хотя обсждать, конечно, нужно еще и с владельцами самого FB. А про Delphi мысль непонятна. Что значит оторвать? Оторвать то, может, и легко, только не забывай, что FB своей популярностью в основном обязан именно Delphi. По крайней мере в России. Я знаю о ней и ценю её. Но тут в этой ветке уже говорилось о вполне реальных ассоциациях которую эта популярность вызывает. Поэтому, думаю, даже те, кто юзает FB для серьезных проектов, и не используют Delphi, как-то не очень афишируют это. Хотя чего казалось бы - видишь в сети урода, который поливает FB - ну потрать пять минут, ответь чудаку. Скорее всего я все утрирую. Можете меня, за это, бросить в терновый куст :))) Все, завязываю. Прошу прощения, если кого-то сильно задел. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] сервера. Я помню эта тема мусировалась в контексте Yaffil. Дальше дело не пошло. На фирменных дисках дятла есть Gemini ODBC ;-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Опять мимо. Ты хоть что-нибудь читал по теме ? Ещё попытка - вроде бы по дефлоту версии сперва в памяти хранятся а не пишутся на диск? Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Да, есть. К 3-ке они будут рассматриваться пристальнее Вот это особо мне интересно. Какие есть варианты чтобы отказаться от свипа? Ну например хранить незакоммиченные версии во отдельном месте И шо ? Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Кстати, вроде бы примерно так оракл работает? Как кстати savepoints работают? Была статья и не одна. Например на ibase.ru и в ibdeveloper Я както сорцы на эту тему читал. Версии складируют в память. Откат сэйвпойта не создаёт версий. Тиражируемый софт может : а) пользовать тот, который встроен даже в win98 б) ставить свой простейший планировщик Нах эти извраты с планировщиками. Проще забить. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Иногда пытаются, правда, сомневаюсь, что целенаправленно. Тому в подтверждение, что различные CMS вовсю включают FB в списки поддерживаемых серверов. Сам я мечтаю перенести сайт организации на динамическую основу, но совершенно не хочу устанавливать и разбираться MySQL, который, и порой только который, поддерживает подавляющее их большинство, ибо FB есть. А зоопарк на сервере разводить не желаю пока не возникнет в этом необходимости (я не хостер, а потому нефиг). По теме, к сожалению, ничего сказать не смогу, т.к. мне не приходилось никогда работать ни с чем кроме Interbase/FB (не тыкать в меня пальцами!) А по сему сравнивать на основании личного опыта не имею возможности. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Опять мимо. Ты хоть что-нибудь читал по теме ? Ещё попытка - вроде бы по дефлоту версии сперва в памяти хранятся а не пишутся на диск? Нет Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Да, есть. К 3-ке они будут рассматриваться пристальнее Вот это особо мне интересно. Какие есть варианты чтобы отказаться от свипа? Не отказаться, а сделать его ещё быстрее Ну например хранить незакоммиченные версии во отдельном месте И шо ? Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? А о отдельных процессах классика в курсе ? Которые не видят память друг-друга Кстати, вроде бы примерно так оракл работает? Не знаю, но уверен что не так Как кстати savepoints работают? Была статья и не одна. Например на ibase.ru и в ibdeveloper Я както сорцы на эту тему читал. Версии складируют в память. Откат сэйвпойта не создаёт версий. Не дочитал ты. Чти ibdeveloper, я там писал Тиражируемый софт может : а) пользовать тот, который встроен даже в win98 б) ставить свой простейший планировщик Нах эти извраты с планировщиками. Проще забить. Тогда об чём вопрос был ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? А о отдельных процессах классика в курсе ? Которые не видят память друг-друга Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. При сносе сервера остаются только версии из файла. Основная проблема тут обеспечить надёжность коммита и не зависнуть при массовых обновлениях. Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Popov пишет: Классик - в печку. Знак восклицания не стоит осмысленно или пропущен по недогляду? Понимаю (читай надеюсь), что в пылу сие произнесено, но все же... гм... Меня бы задело. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Popov ... Horsun Vlad wrote: Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? А о отдельных процессах классика в курсе ? Которые не видят память друг-друга Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. Для кого актуальная ? При сносе сервера остаются только версии из файла. Основная проблема тут обеспечить надёжность коммита и не зависнуть при массовых обновлениях. Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. Чем вр.файл отличается от основного ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. Для кого актуальная ? Самая последняя закоммиченная. Т.е. так которая должна быть в базе при сносе сервера. При этом не хранить указатели на предыдущие версии. Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. Чем вр.файл отличается от основного ? Тем что версии не разманы по всему файлу бд. И могут чистится по коммитам без свипа. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. Для кого актуальная ? Самая последняя закоммиченная. Т.е. так которая должна быть в базе при сносе сервера. При этом не хранить указатели на предыдущие версии. Не, так не пойдёт. Распиши что и как сохранять на примере с 3-мя тр-циями, каждой из которых видна своя версия Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. Чем вр.файл отличается от основного ? Тем что версии не разманы по всему файлу бд. И могут чистится по коммитам без свипа. А с какой стати они не будут размазаны по вр.файлу ? Или для каждой тр-ции и каждой таблицы - свой файл ? Сборка мусора удаляет не только старые версии записей, она также удаляет ненужные блобы и ключи индексов -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Всем привет! К сожалению, тема вышла за пределы взвешенного разговора и перешла к самопоyтованию и выпячиванию своих комплексов. Давайте будем обсуждать идеи в соответтсвующих темах - создавайте и обсуждайте. Да, есть много верных замечаний - ну давайте над ними и работать. Для начала я бы предложил всем участникам и хотетелям сброситься по бутылочке хорошего пива в фонд Firebird - по 50 рублей сюда http://www.ibase.ru/fbfunds.htm Еще чуток и мы сможем нанять хорошего дизайнера (не Лебедева, но и не коленочника, не отличающего table от css ) и сделать промосайт для Firebird. Вот это реальное дело, которое повысит визибилити Firebird и будет положительно влиять на увеличение рынка труда и оценку умений связанных с разработкой Firebird-based application. Вот небось сидите, откупорили Крушовице и киваете, вместо того чтобы Firebird помочь. С уважением, Алексей Ковязин
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: К сожалению, тема вышла за пределы взвешенного разговора и перешла к самопоyтованию и выпячиванию своих комплексов. А можно я тоже немножко свои комплексы повыпячиваю и поофтоплю? Не, ну я немножко совсем и у меня уавжытельные причины: уже почти пятница, я слегка бухой и мало-мало расстроеный. Можно, да? Спасибо. Итак к вопросу о медленном backup/restore на FB: Сегодня решил попробовать проапгрейдить базу постгрес, перенеся ее со старого и дряхлого Pg 7.4 на 8.0, дабы уйти наконец от старого ба... то есть фичи этого сервера, напрочь отказывавшегося использовать индекс при объединении таблиц по полям разных типов. Для чего перво-наперво решил сделать этот самый бэкап. Запустил, как умный, pg_dump на машине и стал заниматься своими делами, периодически поглядывая а не завершилось ли. И не то чтоб во мне вообще ничего не шевельнулось на тему а хватит ли места, нет, мысль такая конешно возникала, но я, гадкий ламер, изнеженый файрбердом, как-то привык, что бэкап базы занимает места по крайней мере не больше самой базы - поэтому по дури своей решил, что уж в 15G скрипт-то влезть обязан. Поэтому gzipать его на лету не стал, понадеявшись на здравый смысл. Ха!!! Реальная жизнь - лучшее лекарство от излишнего оптимизма: свободное место на винте все-таки закончилось раньше, чем завершился pg_dump. Сильно удивленный таким к себе неуважением, он сказал что-то типа не получилось записать в файл: 5!=7 и обиженно прекратился, оставив меня с обгрызком бэкапа и нулем свободных байт в /home/mike. Ну да ладно, речь-то собственно не об этом, это так, лирика и мое криворучье. Речь о том, что с момента начала бэкапа до момента его облома прошло примерно часа четыре-пять. А потом еще столько же - на бэкап с загзипливанием на лету. Сколько займет накатывание данных из погзипленного файла на новый сервер - пока неизвестно, сей эксперимент еще пока только в самом начале пути и результаты его будут анализироваться утром. Но одно лично мне ясно - пусть порвут меня на лоскутки коллеги-постргескюлисты, но слово быстро по отношению к этому процессу имхо даже _рядом не лежало_.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Fynda wrote: я слегка бухой и мало-мало расстроеный Надо было в баню идти :-) слово быстро по отношению к этому процессу имхо даже _рядом не лежало_ Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно тормозной. Но у них есть и более другие способы. Например, у PG: http://www.postgresql.org/docs/8.1/interactive/backup-online.html -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: Давайте будем обсуждать идеи в соответтсвующих темах - создавайте и обсуждайте. по 50 рублей сюда и сделать промосайт для Firebird. Мне кажется, что полтинник, как и промосайт, делу не поможет. The Bat - почти на каждом компе, MS Exchange - не у всех. Функциональность разная, суть же почти одинакова. Так вот, создание программы, которая объеденит функции вышеназванных и будет использовать FB в качестве хранилища, вытащит FB на новый уровень.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Про cooperative vs background gc слыхивал ? А про IB6 ? За FB2 уже не спрашиваю ;))) Так в IB вроде сразу два типа - и кооперативная и фоновая. Собственно я выступаю ни за ту, ни за другую сборку. Нужно нечто промежуточное - кооперативный поиск мусора и фоновая чистка. А что такое background gc по-твоему ? Автоматический sweep как таковой не нужен. Та ты шо ?! А OIT вверх продвигать кто будет ? Jim ? Так он в MySQL ушёл ;))) Можно предложит вариант с перерасчётом при commit, но отложенно в мусорщике. Ты понимаешь причины застревания OIT ? А механизм его сдвига после застревания ? А про sweep_interval мы тоже не слыхивали ? sweep_interval - однозначно кривое решение проблемы. ИМХО. Никто не запрещает выставить его в 0 Но например автоматическое обновление статистики индексов реально нужно. Причём тут это к сборке мусора ? При том что задача в целом аналогична сборке мусора. И требуются примерно аналогичные решения. Я тупой и не вижу аналогий Кстати, проблема устаревания статистики как то не вызывает резонанс у общественности. Ибо статистика пока слабо пользуется оптимизатором. Вот когда будут гистограммы, тогда можно будет озаботиться и об этом А кстати TIP урезается снизу иди нет? Первая внятная мысль :) Пока нет. Но будет. Позже. Ибо не самое критичное. Если при snapshot делается копия не всей TIP, то действительно не критично. А с какой стати делать копию всего TIP ? А что такое OIT и накуя он нужён ? -- Хорсун Влад PS сабж восстановил чтобы было понятно, о чём мы говорим :)))
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: А что такое background gc по-твоему ? По моему это когда фоновый поток периодически проверяет все данные на предмет мусора. Можно предложит вариант с перерасчётом при commit, но отложенно в мусорщике. Ты понимаешь причины застревания OIT ? А механизм его сдвига после застревания ? Блин, у меня дикий своппинг в мозгу - вспомнить всё :-0 Застревает как я понимаю если сделат rollback. Чтобы сдивинуть потом нужно в TIP пометить эту транзакцию как commited, но при условии что версии из rollback транзакции почищены. Это всё в свою очередь возможно если нет работающих snapshot транзакций запущенных _до_ старта rollback транзакции. Вот какая хренотень. Получается что основная проблема - это сборка версий старой rollback транзакции. Для этого надо пробегать все таблицы базы... либо Вообщем я пока пас :-| При том что задача в целом аналогична сборке мусора. И требуются примерно аналогичные решения. Я тупой и не вижу аналогий Ну вместе со свипом пересчитывать статистику. Ибо статистика пока слабо пользуется оптимизатором. Достаточно чтобы похерить план :-) Основная проблема - пустая база создаётся из скрипта и бросается на произвол судьбы юзерам. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander! Alexander Goldun wrote: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;) не gnu, а gpl. и не платность под gpl, и т.п. И вообще, сказал А, говори Б. есть как минимум несколько вариантов 1. распространение gpl-приложений с gpl MySQL 2. распространение не-gpl приложений, использующих MySQL 3. разработка приложений внутри компании, работающих с MySQL ... разумеется, что платность относится ко второму случаю. p.s. вопрос надо рассматривать целиком, а не частями. также по фактам одной части не надо утверждать что этот факт распространяется на все остальные случаи. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexey! Alexey Popov wrote: Ну вместе со свипом пересчитывать статистику. это разные задачи. несовместимые. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;) не gnu, а gpl. и не платность под gpl, и т.п. И вообще, сказал А, говори Б. Да мне MySQL с его лицензией побоку. Я с ним сталкиваюсь только на хостинге либо в приходящих резюме с перлами типа Разрабатываю в свободное время программу бухучета типа 1с на Delphi+MySQL 3 :) Я просто сопоставил твою активность в форумах на эту тему и предложение запуска факто-мифов P.S. А вообще, конечно, MySQL напирает. Огромная армия веб-мастеров переквалифицируясь с написания гостевых книг на системы учета тянет за собой этот самый чудо-сервер, ибо других не знают. Ладно бы еще PostgreSQL... Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
А что такое background gc по-твоему ? По моему это когда фоновый поток периодически проверяет все данные на предмет мусора. Не угадал Можно предложит вариант с перерасчётом при commit, но отложенно в мусорщике. Ты понимаешь причины застревания OIT ? А механизм его сдвига после застревания ? Блин, у меня дикий своппинг в мозгу - вспомнить всё :-0 Зачем тогда эта беседа ? Застревает как я понимаю если сделат rollback. Не каждый rollback к этому приводит. Чтобы сдивинуть потом нужно в TIP пометить эту транзакцию как commited, но Не нужно при условии что версии из rollback транзакции почищены. Тут правильно Это всё в свою очередь возможно если нет работающих snapshot транзакций запущенных _до_ старта rollback транзакции. Вот какая хренотень. OIT не бывает выше OAT, так что это не в кассу Получается что основная проблема - это сборка версий старой rollback транзакции. Для этого надо пробегать все таблицы базы... либо Вообщем я пока пас :-| Никаких либо - нужно читать всю БД, чем свип и занимается При том что задача в целом аналогична сборке мусора. И требуются примерно аналогичные решения. Я тупой и не вижу аналогий Ну вместе со свипом пересчитывать статистику. Статистика индекса - это значения всех ключей. Свип не читает все индексы. Он даже не читает все версии всех записей. Так что - аналогия только в фоновом выполнении. Но тогда можно сказать, что обновлять статистику можно по-аналогии с cache_writer Ибо статистика пока слабо пользуется оптимизатором. Достаточно чтобы похерить план :-) Основная проблема - пустая база создаётся из скрипта и бросается на произвол судьбы юзерам. Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) -- Хорсун Влад PS Насчёт произвола юзеров из кода FB : /** * * g d s _ $ c r e a t e _ d a t a b a s e * ** * * Functional description * Create a nice, squeeky clean database, uncorrupted by user data. * **/ ... /** * * g d s _ $ a t t a c h _ d a t a b a s e * ** * * Functional description * Attach a moldy, grungy, old database * sullied by user data. * **/ :)))
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Прошу помочь вспомнить и упорядочить сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander! Alexander Goldun wrote: Я просто сопоставил твою активность в форумах на эту тему и предложение запуска факто-мифов а, это никак не связано. просто я считаю, что разработчик хоть чуточку должен разбираться в лицензиях используемого софта. Например, я в IBAnalyst хотел вставить тулбар. мне посоветовали ToolBar2000. А он оказался платным для коммерческого использования. Соответственно, от предложения пришлось отказаться :-) P.S. А вообще, конечно, MySQL напирает. Огромная армия веб-мастеров переквалифицируясь с написания гостевых книг на системы учета тянет за собой этот самый чудо-сервер, ибо других не знают. Ладно бы еще если на 3-ей версии, то ничего хорошего не получится. PostgreSQL... Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться? вряд-ли. надо будет забабахать свое сравнение? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
O6opoTeHb wrote: Прошу помочь вспомнить и упорядочить сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный... Дык. Воинствующие ламеры подтянулись. Подожди, скоро нуллом начнут размахивать и крушить им всё направо и налево. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный... Дык. Воинствующие ламеры подтянулись. Подожди, скоро нуллом начнут размахивать и крушить им всё направо и налево. ОФФ: крушить... интересно... нада буит с воздушки попробовать винт битый расстрелять... антиресна жышь..:)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться? С точки зрения функциональности, 5-ка - это сильный шаг вперед. Хотя часть нововведений работает скорее для галочки - тормозно, глючно или с интересными ограничениями. А вот с точки зрения производительности ядра, все еще менее весело. 4-ка на большой нагрузке (разговор про движок InnoDB, базу размером много больше ОЗУ и отнюдь не read-only операции) работает неудовлетворительно, 5-ку сейчас на той же задаче пытаемся оценить параллельно с PG8 и FB2. Будут результаты - отпишусь. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun писал(а): Вот скажите мне - через что работают с MSSQL из Delphi ? Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по родным компонентам прямого доступа. Вот и я абсолютно о том же. Но у нас упорно - это типа у нас нативе, а это у нас как у вас. Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. При этом на этом поле у нас есть (была?) реальная фора - здесь я во многом верю Котляревскому, но елки палки - несколько транзакций через ADO можно было делать еще в 2001 году, несколько открытых активных рекордсетов - по жизни. Нет, мы этого знать не хотим и не будем на это опираться. Что там у нас в MSSQL? MARS в 2005-ом?. Какая охная технология! И так далее и тому подобное. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry wrote: Вот и я абсолютно о том же. Но у нас упорно - это типа у нас нативе, а это у нас как у вас. Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Кто-то ограничивает чьи-то возможности? Тебя держат за руки и заставляют пользовать IBX? Хто? Скажи, я ему в глаз плюну. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Застревает как я понимаю если сделат rollback. Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Получается что основная проблема - это сборка версий старой rollback транзакции. Для этого надо пробегать все таблицы базы... либо Вообщем я пока пас :-| Никаких либо - нужно читать всю БД, чем свип и занимается Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Ну например хранить незакоммиченные версии во отдельном месте или даже в памяти. Как кстати savepoints работают? Основная проблема - пустая база создаётся из скрипта и бросается на произвол судьбы юзерам. Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) Не катит для тиражируемого софта. Да и ось м.б. - 98 -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Ded писал(а): Вот и я абсолютно о том же. Но у нас упорно - это типа у нас нативе, а это у нас как у вас. Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Кто-то ограничивает чьи-то возможности? Тебя держат за руки и заставляют пользовать IBX? Хто? Скажи, я ему в глаз плюну. Меня никто ни за что не держит. Но когда речь заходит о том что бы писать приложения совместимые с MSSQL и FB - я какого только бреда не видел. Даже не припомню, чтобы хотя бы посоветовали посмотреть в сторону ODBC - нет, давайте будем городить городульки над ADO и VCL-ными компонентами. Они же у нас нативные! Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Подсказать какие мысли возникают в связи с последним? Тут только и остается подумать - что слава тебе Билли, что появилась .NET на которой у сервера появилась хоть какая-та возможность жить своей жизнью, а не в качестве чьего-то довеска. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Popov ... Horsun Vlad wrote: Застревает как я понимаю если сделат rollback. Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Опять мимо. Ты хоть что-нибудь читал по теме ? Никаких либо - нужно читать всю БД, чем свип и занимается Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Да, есть. К 3-ке они будут рассматриваться пристальнее Ну например хранить незакоммиченные версии во отдельном месте И шо ? или даже в памяти. Думаем о восстановлении после краша, и отметаем этот вариант Как кстати savepoints работают? Была статья и не одна. Например на ibase.ru и в ibdeveloper Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) Не катит для тиражируемого софта. Да и ось м.б. - 98 Тиражируемый софт может : а) пользовать тот, который встроен даже в win98 б) ставить свой простейший планировщик -- Хорсун Влад PS мне начинает это надоедать...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry wrote: Меня никто ни за что не держит. Но когда речь заходит о том что бы писать приложения совместимые с MSSQL и FB - я Имхо в приложениях, задача которых - быть совместимыми и с MSSQL и с FB, какие компоненты пользовать - ну просто последняя спица в колеснице. Концептуально сервера совершенно разные, их объединяет полтора десятка операторов с похожим синтаксисом. Тут сама логика реализации систем разная, а компоненты - дело десятое. Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Серёжа Мереуца, как мне кажется, про Дельфи вспоминает только всвязи с заходом в какую-нить конфу. На Ц люди ваяют, на жабе. На всяких там перлах-питонах и прочей гадости... -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Evgeny Putilin писал(а): Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Дим ты тут о чем? вообщето некоторые не первый год пользуются Java + FB вов всех извращеных связях. Но почемуто Delphi+FB больше. Жень, у меня тоже толпа покупателей провайдера только ради использования в связке с MSSQL. Но эти маньяки - не показатель. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Ded [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Серёжа Мереуца, как мне кажется, про Дельфи вспоминает только всвязи с заходом в какую-нить конфу. На Ц люди ваяют, на жабе. На всяких там перлах-питонах и прочей гадости... Ребята, я тут чего тему как-то потерял. МЫ ТУТ ВООБЩЕ ЧЕГО ОБСУЖДАЕМ? Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты - собственно по предмету будут высказывания или будем философией заниматься?!
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Мы утилиты обслуживания/репликации своей системы на Python-е лабаем. ;-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexey! Alexey Popov wrote: Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. мда. это БЫЛО изначально. Варианты есть. Ну например хранить незакоммиченные версии во отдельном месте или даже в памяти. и при чем тут sweep? Алекс, разговор с тобой очень сильно похож на диалог - кастрюлю на огонь поставил? - там провод оторвался - какой провод? то есть что ни возьми - ну практически все не в кассу. Как кстати savepoints работают? прочитай: www.ibase.ru/devinfo/savepoints.htm еще см. какой-то номер ibdeveloper.com Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) Не катит для тиражируемого софта. Да и ось м.б. - 98 почему же не катит? У Ораклов и Микрософтов катит, а тебе - не катит? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Oleg LOA wrote: Ребята, я тут чего тему как-то потерял. МЫ ТУТ ВООБЩЕ ЧЕГО ОБСУЖДАЕМ? Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты - собственно по предмету будут высказывания или будем философией заниматься?! Дык этта. Димка, если я правильно его понял, в число слабых мест FB по сравнению с обычными серверами ;) включил то, что с ним подавляющее большинство работают через нативные компоненты и с помощью Дельфей. А я ему говорю - да и хрен с ним, каждый дрочить как он хочить (С). Наличие нативных компонент не является слабиной, поскольку через ненативные тоже никто не запрещает. Не вижу тут слабого места. Так что упрёк не принимаю, отвечал в контексте предмета обсуждения. А ход мыслей нашего объектно ориентированного собрата ;) мне тоже не совсем в данном случае ясен. И во многих других случаях тоже, но это уже моё личное горе, которое обсуждать и вправду не имеет смысла :-D -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по родным компонентам прямого доступа. Вот и я абсолютно о том же. Но у нас упорно - это типа у нас нативе, а это у нас как у вас. Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Есть такое. Дед, конечно, прав, кто как хочет, так и... Но вот свежайший пример навскидку: http://sql.ru/forum/actualthread.aspx?tid=340299#3159886 Все советуют native. Все рассказывают про какие-то лишние тормоза, как будто дополнительные микросекунды на вызов могут сказаться при разработке массовых бизнес-приложений. Но напомни, плиз, если я скачаю дистрибутив FB, там в комплекте будут ODBC и OLE DB драйверы? Судя по http://ibase.ru/components.htm - нет, не будут. Вижу там 5 разных драйверов ODBC, 3 штуки OLE DB. А оно надо - так много? Заморачиваться, выбирать, пробовать. Ах, еще и платить надо? У PG8 в этом плане проще и понятнее. ODBC драйвер в дистрибутиве есть. OLEDB есть. Хоть про второй инсталлятор и предупреждает честно, что он еще сырой, но тем не менее он есть и понятна политика: он, очевидно, будет и в дальнейшем. И не надо ничего искать и выбирать. А такое разнообразие одних только ODBC драйверов наводит на мысль, что это не от хорошей жизни. Чисто интуитивно напрашивается мысль: пишут все кому не лень, потому что не устроило то, что нашли. А были бы эти драйвера в комплекте, многие и не заморачивались бы больше ничем. А про Delphi мысль непонятна. Что значит оторвать? Оторвать то, может, и легко, только не забывай, что FB своей популярностью в основном обязан именно Delphi. По крайней мере в России.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Vladimir A.Bakhvaloff ... Одна надежда: может всё-таки объясните в итоге разговора... ;) Собственно только поэтому я и поддерживаю эту беседу -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Lendel ... А что мешает сделать лучше, кроме времени, сил и денег? Тут мало причин ? :))) -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
распространенности в бизнес-сфере и в некоторых технических аспектах. По О технических аспектах можно подробнее :-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Lendel [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Достаточно. :-)) Я было подумал, что может есть еще причины. Например, код тоскливый, концептуальные ошибки или что-то еще. Дмитрий В дополнение к этим. И код у FB местами крайне тоскливый и концептуальных косяков хватает :-(.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Dmitri Kuzmenko said the following on 14.09.2006 19:33: ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую софтину, если только я не линкую ее с клиентской библиотекой от MySQL. забей. про линковку уже они не говорят. Если твоя прога не GPL и она МОЖЕТ работать с MySQL, то или ты или твой клиент должен покупать MySQL. Причем меня может устроить клиентская библиотека от MySQL 4.0.x - которая была еще под LGPL, т.е. по условиям лицензии мне достаточно уже поздно. мне начать материться по поводу не читают и тут? :-) Бесплатным оставлен MySQL 3.22.19 (или как его там). Выше все подчиняется новым правилам. Это не я не читаю, это ты не читаешь ;) MySQL доступен под _двумя_ лицензиями. Что они там пишут в коммерческой лицензии или как они трактуют биб..., вернее GPL - это их проблемы. Но MySQL _можно_ использовать на условиях GPL, и именно на этих условиях он входит в многочисленные дистрибутивы linux. Т.е. мне достаточно выполнять условия GPL, все остальное - это домыслы. Читаем FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem If people were to distribute GPL-covered software calling it part of a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear. Т.е. я не распространяю MySQL как часть моей системы (part of), и я не использую в своей программе GPL-ные библиотеки MySQL. или купить у сторонних разработчиков вроде http://crlab.com/ При этом коммерческая лицензия на сам MySQL не нужна. прежде чем придумывать, лучше изучить все имеющиеся тонкости. crlab если не распространяет свои дрова под gpl, должен тебя обязать купить драйвер к mysql. Нет. Они продают свои собственные драйверы, причем это значительно дешевле чем коммерческая лицензия на MySQL. Для MySQL это невыгодно, конечно, но сделать они ничего с этим не могут. Мало того - это их сертифицированный партнер: http://solutions.mysql.com/solutions/item.php?id=248 И вообще, нет там уже слов кроме использует. Если твоя софтина коммерческая и РАБОТАЕТ с MySQL - все, ты ОБЯЗАН для конкретной установки купить коммерческий MySQL. Или не ты, а твой клиент. Да, именно так сделан их сайт. Чтобы внушить читающему неизбежность покупки коммерческой лицензии... ;-) Но как только они перестанут распространять свой продукт под GPL, его тут же не будет ни в одном дистрибутиве линукса - и этим они только нанесут удар по собственному бизнесу ;) -- Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
hi Oleg Deribas Да, именно так сделан их сайт. Чтобы внушить читающему неизбежность покупки коммерческой лицензии... ;-) Но как только они перестанут распространять свой продукт под GPL, его тут же не будет ни в одном дистрибутиве линукса - и этим они только нанесут удар по собственному бизнесу ;) Все правильно у них есть GPL лицензия но еще есть LGPL (для версии 3.чегото там), но лично я почемуто не стремлюсь распространять весь свой код под GPL. А она заразная, т.е. смысл послания их сайта не то что бы купите их лицензию а то что или дарито свой код или купите наш. WBR Evgeny Putilin.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Oleg Deribas пишет: Это не я не читаю, это ты не читаешь ;) Нет, это ты не понял. Это просто анти-PR акция. Ход, практикуемый адвокатами или обвинителями в судах с присяжными - выдать какую-либо информацию, которую может и не пришьют к делу, но осадочек в умах присяжных останется, который потом может повлиять на решение при сомнениях :)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander Goldun said the following on 15.09.2006 13:15: Это не я не читаю, это ты не читаешь ;) Нет, это ты не понял. Это просто анти-PR акция. Ход, практикуемый адвокатами или обвинителями в судах с присяжными - выдать какую-либо информацию, которую может и не пришьют к делу, но осадочек в умах присяжных останется, который потом может повлиять на решение при сомнениях :) Так ведь я примерно то же самое написал, но немного другими словами ;-) -- Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Начиная с версии 8 - хороший сервер. У них по прежнему на подключение процесс создаётся типа как в нашем классике?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
sasha wrote: У них по прежнему на подключение процесс создаётся типа как в нашем классике? Да. Только у них буферный кеш общий между процессами. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Добрый день, Alexey! Вы писали от Thu, 14 Sep 2006 03:53:30 -0700: AK Прошу помочь вспомнить и упорядочить AK сравнительные характеристики Firebird, MySQL AK и PostgreSQL (современных версий). AK 4) Любые другие моменты, которые AK кажутся важными. Может не совсем по теме, но 0.Функционал имеет не первостепенную роль при выборе БД 1. Один из самых важных моментов влияющих на распространенность FB это его отсутствие в стандартных дистрибутивах Linux и FreeBSD с нормально документацией 2.Отсутствие поддержки FB в качестве основной БД для распространенных демонов Unix, например почтовиков 3. Отсутствие поддержки FB в стандартных СМS для WEB сайтов В целом FB 2.0 по функционалу во многих вопросах выглядит лучше чем MySQL и PostgreSQL для многих задач. Все упирается в фору по времени, которую получили на момент взрывообразного роста интернет MYSQL и в меньшей части PostgreSQL. По анализу продаваемого на Softkey.ru ПО, работающего с БД, для малого бизнеса и домашнего пользования, FB уверенно опережает MYSQL и PostgreSQL в разы по распространнености, Из этого можно сделать вывод о том, что на платформе Windows для desktop приложений, FB имеет большую распространненость чем на Unix подобных системах. С Уважением, Константин Зайцев.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Konstantin! Konstantin Zaitcev wrote: По анализу продаваемого на Softkey.ru ПО, работающего с БД, для малого бизнеса и домашнего пользования, FB уверенно опережает MYSQL и PostgreSQL в разы по распространнености, Из этого можно сделать вывод о том, что на платформе Windows для desktop приложений, FB имеет большую распространненость чем на Unix подобных системах. и по моим данным IB/FB на Windows - 70%, на разных Unix - 30%. то же самое можно сказать по числу downloads дистрибутивов. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, All! сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без кстати, я на sql.ru постил буквально вчера или позавчера. MySQL теперь четко определил в коммерческой лицензии когда нужно покупать MySQL. http://www.mysql.com/company/legal/licensing/commercial-license.html если раньше можно было написать закрытую софтину, и сказать клиенту - скачай MySQL сам, то теперь - шиш. Коммерческая лицензия приобретается разработчиком, продавцом или клиентом, в случаях: - Selling software that requires customers to install MySQL themselves on their own machines. - If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. - If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. и даже хуже - дальше там текст про аналогичное использование драйверов для MySQL. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Dmitri Kuzmenko said the following on 14.09.2006 15:08: MySQL теперь четко определил в коммерческой лицензии когда нужно покупать MySQL. Да, они там могут писать все что угодно... http://www.mysql.com/company/legal/licensing/commercial-license.html если раньше можно было написать закрытую софтину, и сказать клиенту - скачай MySQL сам, то теперь - шиш. ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую софтину, если только я не линкую ее с клиентской библиотекой от MySQL. Причем меня может устроить клиентская библиотека от MySQL 4.0.x - которая была еще под LGPL, т.е. по условиям лицензии мне достаточно указать где-нибудь в readme что я использую эту библиотеку. Кроме того я могу реализовать протокол mysql самомтоятельно, или купить у сторонних разработчиков вроде http://crlab.com/ При этом коммерческая лицензия на сам MySQL не нужна. Но все вышесказанное, конечно, не отменяет того что MySQL - редкостный отстой ;-) -- Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
В FB (как и в IB) самым ценным (в смысле идей) по сей день является физическая структра БД, транзакционный движок и ещё кое что из jdr. Тому кто это заложил в IB - мега респект. Увы больше ничего качественно нового создано небыло. Медленная но уверенная эволюция. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Oleg! Oleg Deribas wrote: MySQL теперь четко определил в коммерческой лицензии когда нужно покупать MySQL. Да, они там могут писать все что угодно... ты прав. они авторы, имеют право писать все что угодно. ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую софтину, если только я не линкую ее с клиентской библиотекой от MySQL. забей. про линковку уже они не говорят. Если твоя прога не GPL и она МОЖЕТ работать с MySQL, то или ты или твой клиент должен покупать MySQL. Причем меня может устроить клиентская библиотека от MySQL 4.0.x - которая была еще под LGPL, т.е. по условиям лицензии мне достаточно уже поздно. мне начать материться по поводу не читают и тут? :-) Бесплатным оставлен MySQL 3.22.19 (или как его там). Выше все подчиняется новым правилам. Кроме того я могу реализовать протокол mysql самомтоятельно, реализуй. это не отменяет того, что твоя программа может работать с MySQL. Формулировки изменились. или купить у сторонних разработчиков вроде http://crlab.com/ При этом коммерческая лицензия на сам MySQL не нужна. прежде чем придумывать, лучше изучить все имеющиеся тонкости. crlab если не распространяет свои дрова под gpl, должен тебя обязать купить драйвер к mysql. И вообще, нет там уже слов кроме использует. Если твоя софтина коммерческая и РАБОТАЕТ с MySQL - все, ты ОБЯЗАН для конкретной установки купить коммерческий MySQL. Или не ты, а твой клиент. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Так, понятно что MySQL уже не совсем Open Source из-за лицензионных вопросов. Но что с PostgreSQL? Про 1С интересная информация, но по пунктам 1-3 есть какие то мысли? Или просто любые мысли по сравнению? С уважением, Алексей Ковязин
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko wrote: забей. про линковку уже они не говорят. Если твоя прога не GPL и она МОЖЕТ работать с MySQL, то или ты или твой клиент должен покупать MySQL. Если твоя софтина коммерческая и РАБОТАЕТ с MySQL - все, ты ОБЯЗАН для конкретной установки купить коммерческий MySQL. Или не ты, а твой клиент. Оба предложения касаются *только* распространяемого софта. Если я свой софт использую у себя (пусть даже и в коммерческих целях), то никому я ничего не должен. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: Так, понятно что MySQL уже не совсем Open Source из-за лицензионных вопросов. Очень даже Open Source :-) Просто надо понимать ограничения. Но что с PostgreSQL? Начиная с версии 8 - хороший сервер. Уступает нам лишь в распространенности в бизнес-сфере и в некоторых технических аспектах. По функциональности сильно превосходит. -- Дмитрий Еманов
