Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 22 23 24 25 26 [27] 28 29 30 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
fynda
DocAl

Для работы с бинарным логом используется отдельная утилита, идущая вместе с сервером.


Ладно, фиг с ним с логом, скажите - нормальный бэкап у mySQL появился уже, хотя бы в виде отдельной утилиты? Или по-прежнему надо базу часами из скрипта восстанавливать?
Для InnoDB это платная тулза, для MyISAM бинарный бакап всю жисть есть, благо не бином Ньютона. Только что не так распространён, как дамп в SQL-формат, т.к. доступ к файлам нужен, а на хостинге с этим мало кто будет заморачиваться, всё-таки, именно в вебе MySQL чаще всего используется.
8 янв 08, 13:59    [5125739]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
fynda
Ладно, фиг с ним с логом, скажите - нормальный бэкап у mySQL появился уже, хотя бы в виде отдельной утилиты? Или по-прежнему надо базу часами из скрипта восстанавливать?
Кстати, если вам нужно моментальное восстановление -- так держите резервный сервер на репликации. Хотя это не для всех случаев, но для тех, что да -- самое быстрое решение.
8 янв 08, 14:00    [5125742]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785
DocAl

Для InnoDB это платная тулза, для MyISAM бинарный бакап всю жисть есть, благо не бином Ньютона.


MyISAM не так интересен, а что за тулза для InnoDB? И как работает?
8 янв 08, 14:42    [5125825]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

DocAl
В MySQL, кстати, есть свой встроенный репликатор.

Умеет реплицировать с IB/FB или Oracle?

Posted via ActualForum NNTP Server 1.4

8 янв 08, 16:05    [5126065]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

DocAl

По поводу одного триггера на одно событие, согласен, что это неудобно,
но это "легко обходится" (с) kdv

Способ?

Posted via ActualForum NNTP Server 1.4

8 янв 08, 16:07    [5126068]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
fynda
DocAl

Для InnoDB это платная тулза, для MyISAM бинарный бакап всю жисть есть, благо не бином Ньютона.


MyISAM не так интересен, а что за тулза для InnoDB? И как работает?
Вы не обидитесь, если я отошлю к документации по ней?
8 янв 08, 16:11    [5126085]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Dimitry Sibiryakov

DocAl

По поводу одного триггера на одно событие, согласен, что это неудобно,
но это "легко обходится" (с) kdv

Способ?
Posted via ActualForum NNTP Server 1.4
Вызывать хранимки из общего на всех триггера?
8 янв 08, 16:12    [5126091]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Dimitry Sibiryakov

DocAl
В MySQL, кстати, есть свой встроенный репликатор.

Умеет реплицировать с IB/FB или Oracle?
Posted via ActualForum NNTP Server 1.4
Нет, но, в общем-то, имеющийся бинарный лог не так уж сложно для этого приспособить. Хотя, конечно, повесить триггера на вставку/удаление/обновление и не париться -- оно, конечно, проще. Но не единственный возможный вариант, если действительно надо.
8 янв 08, 16:14    [5126099]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

DocAl
Вызывать хранимки из общего на всех триггера?

Мсье шютник, однако... Ты только представь, что у тебя есть задание
внедрить (программно!) протоколирование в чужую БД. Кто там благородно
наставит в триггера вызов твоей хранимки?

Posted via ActualForum NNTP Server 1.4

8 янв 08, 16:24    [5126125]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Тот же, кто благородно наставит туда триггера?
8 янв 08, 16:51    [5126204]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

DocAl
Тот же

Наив.

Posted via ActualForum NNTP Server 1.4

8 янв 08, 17:02    [5126234]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
DocAI
Ведь совершенно понятно, что если в классической архитектуре два разных соединения работают с одними и теми же данными, то эти данные будут храниться в буферах обоих соединений, вот вам и двойная буферизация

я об этом на курсах рассказываю уже лет 8. причем, практически всем пользователям FB известно, что для классика размер кэша выставлять больше 2048 страниц не нужно ибо чревато ухудшением производительности.

DocAI
Но ничего, заради халявы (а какие ещё известны достоинства фаербёрда?)


может Вам никакие и неизвестны. опять же - злопыхание и демагогия.

DocAI
не жалко и 4,6 гигов оперативки на 160 соединений. Будет 600 соединений -- докидаем до 16 гигов, никаких проблем, подумаешь, пятисоткратная буферизация!


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

DocAI
а если хочется получить приличную производительность

опять же, что именно понимается под "приличной" и "неприличной" производительностью?

Допустим, с Ваших слов я "вру" людям скрывая явные и ужасные недостатки Firebird. При этом люди, натыкаясь на них, мучаются и жрут кактус. То есть, по Вашему получается, что Firebird это вообще полный отстой, с тучей багов, кривой архитектурой и т.п., который годится разве что на самописную телефонную книгу. Так? При этом сами Вы с Firebird не работали. Тоже так?
8 янв 08, 18:06    [5126437]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
Если вы используете ODBC или что-то подобное и подключаетесь к MySQL как к стандартному источнику данных -- вряд ли тут возможно настаивать на приобретении коммерческой лицензии на MySQL. А вот если вы используете нативные драйвера MySQL -- тогда да, надо покупать.
То есть, в случае ODBC как бы рассматриваем сервер с данными - сам по себе, и программу - саму по себе? Гм, я бы не стал рисковать таким образом, так как если (не дай бог) кто- нибудь прикопается, он легко докажет, что программа умеет работать только и именно с той структурой данных, которая в базе, да еще эту структуру разрабатывал я, и они обе- и программа, и база данных - неразрывно связаны функционально. Во всяком случае, здесь, здесь и здесь ничего про ODBC не сказано, наоборот, нас мягко подталкивают к покупке даже когда можно и не покупать :)
вот немного оттуда:
автор
В общем случае мы рекомендуем приобретать контракт на поддержку компании MySQL AB и тем, кому для использования ПО баз данных MySQL не требуется коммерческой лицензии: этим вы будете способствовать развитию технологии MySQL и заодно немедленно получите для себя дополнительные преимущества

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


Другими словами- тот кто хочет получать прибыль, пусть покупает. Ок, посмотрим цены.
Они здесь. Смотрим:
MySQL Enterprise Basic €479.00 /Server/Year
MySQL Enterprise Silver €1599.00 /Server/Year
MySQL Enterprise Gold €2399.00 /Server/Year
MySQL Enterprise Platinum €3999.00 /Server/Year

Неплохо, моя программа "Продвинутый калькулятор в связке с БД" уже становится тяжелее для заказчика на 479 евро. Или я не те цены нашел, может быть есть подешевле?
...а что означает "Server/Year"? это надо платить каждый год?

Собственно, имхо:
1.Если программа/задача небольшая или средняя, соответственно цена сервера существенна в общей сумме, то зачем покупать MySQL, если можно взять Firebird, и написав на листочке "не используй запрос insert into mytable select from mytable" и повесив листочек на монитор, работать спокойно?
2.Если программа/задача большая и очень хочется взять платный сервер (главным образом чтобы получить ощущение "если не дай бог что- то случится, то можно позвонить в поддержку, и уж они-то сразу решат проблему"), то почему брать MySQL, а не сервер "побольше"?
8 янв 08, 21:12    [5126826]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
S.G.
Гм, я бы не стал рисковать таким образом, так как если (не дай бог) кто- нибудь прикопается, он легко докажет, что программа умеет работать только и именно с той структурой данных, которая в базе, да еще эту структуру разрабатывал я, и они обе- и программа, и база данных - неразрывно связаны функционально.

думаю после показательной порки СКОтов таких идиотов более не найдется, лидеры индустрии раздавят в ту же секунды. во первых прочтите все же лицензию GPL и ее требования, ваша прога линкуется разве что с ОDBC/JDBC и прочими компанентами, т.е. если и нужно лицензировать, то только такой компанент. oracle, db2, sybase и тонна другого пропритарного софта гораздо сильнее линкуется с GPLным линухом, чем вы с ODBC ...

S.G.

1.Если программа/задача небольшая или средняя, соответственно цена сервера существенна в общей сумме, то зачем покупать MySQL, если можно взять Firebird, и написав на листочке "не используй запрос insert into mytable select from mytable" и повесив листочек на монитор, работать спокойно?

неа, вам еще нужен листочек на update и delete ... и самое страшное прочесывать ЧУЖОЙ код, отлавливая код тех кто не догадался, что кто-то умудрился нарушить декларативность SQL (а без доки єто не мудрено). ИМХО добавить вызов логирования последней строчкой тригера на пару порядков проще, чем искать "ошибки" в чужем коде ...
8 янв 08, 23:11    [5127037]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
автор
и самое страшное прочесывать ЧУЖОЙ код, отлавливая код тех кто не догадался, что кто-то умудрился нарушить декларативность SQL (а без доки єто не мудрено)


не бывает такого. когда люди пытаются использовать такие конструкции, они напарываются на неожиданное поведение СРАЗУ. Таким образом, подобные запросы не могут в приложениях "работать", а потом вдруг "не заработать".

автор
а без доки єто не мудрено

нормальные люди обычно читают релизноты. в которых все прописано.
8 янв 08, 23:36    [5127067]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
добавлю, что я вовсе не против документации. просто я в курсе, что происходит с документацией по FB.
8 янв 08, 23:37    [5127069]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

автор
а без доки єто не мудрено

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

ну а теперь url на ноту где описывается косяк со стабильностью курсора в студию
8 янв 08, 23:53    [5127093]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
в релизнотах на 1.5.3 это есть, в 2.0.3 нет. Вопрос к редактору релизнотов.

ссылки на релизноты есть на www.ibase.ru/firebird.htm
также релизноты обязательно входят в дистрибутивы. в 2.0 входят и на 1.5.

(зацикливание insert into select без sort или where не описано нигде, если я правильно
помню. это поведение относится ко всем версиям IB/FB/YA).

в 1.5.3 это
Two Gotchas with SELECT FIRST

1. This:
delete from TAB1
where PK1 in (select first 10 PK1 from TAB1);

will delete all of the rows in the table. Ouch! the sub-select is evaluating each 10 candidate rows for
deletion, deleting them, slipping forward 10 more...ad infinitum, until there are no rows left. Beware!

2. Queries like:

...
WHERE F1 IN ( SELECT FIRST 5 F2 FROM TABLE2
ORDER BY 1 DESC )

won't work as expected, because the optimization performed by the engine transforms the correlated
WHERE...IN (SELECT...) predicate to a correlated EXISTS predicate. It's obvious that in this
case FIRST N doesn't make any sense:
...
WHERE EXISTS (
SELECT FIRST 5 TABLE2.F2 FROM TABLE2
WHERE TABLE2.F2 = TABLE1.F1
ORDER BY 1 DESC )
9 янв 08, 04:53    [5127331]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

kdv
insert into select

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

Posted via ActualForum NNTP Server 1.4

9 янв 08, 09:14    [5127463]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
S.G.
Собственно, имхо:
1.Если программа/задача небольшая или средняя, соответственно цена сервера существенна в общей сумме, то зачем покупать MySQL, если можно взять Firebird, и написав на листочке "не используй запрос insert into mytable select from mytable" и повесив листочек на монитор, работать спокойно?
2.Если программа/задача большая и очень хочется взять платный сервер (главным образом чтобы получить ощущение "если не дай бог что- то случится, то можно позвонить в поддержку, и уж они-то сразу решат проблему"), то почему брать MySQL, а не сервер "побольше"?
Ну, мы действительно рассматриваем проблему с разных точек зрения, т.к. меня истересуют СУБД с точки зрения использования в качестве бакэнда сайта. В этом случае, проблемы лицензирования отходят на задний план, т.к., во-первых, это, как правило, не коробочный продукт, а решение, изготовленное под заказчика, а во-вторых, для LAMP в лицензии сделано особое исключение, так что для такого использования покупать коммерческую лицензию точно не требуется.

И в такой ситуации, собственно, я не вижу никаких преимуществ у фаербёрда, зато недостатков полно: суперсервер не SMP, да ещё и не на любой ОС есть. Классическую архитектуру для таких задач использовать -- это надо быть большим фанатом фаербёрда, чтоб игнорировать недостатки такого подхода. Памяти на вебсервере много не бывает, время соединения критично, при этом соединений много, они непродолжительны и работают примерно с одним и тем же набором данных. Кроме того, если вебсервер и СУБД работают физически на одной и той же машине, полагаться на кэш файловой системы вообще недопустимо: он же постоянно будет вымываться статикой!
9 янв 08, 09:32    [5127497]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Dimitry Sibiryakov

kdv
insert into select

А не кажется ли вам, что этот оператор надо вообще запретить, как
нарушающий первую (или вторую) нормальную форму - создающий записи с
повторяющейся информацией?..
Posted via ActualForum NNTP Server 1.4
А вам не кажется, что в селекте могут быть какие-то манипуляции с данными?
9 янв 08, 09:32    [5127499]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

DocAl

А вам не кажется, что в селекте могут быть какие-то манипуляции с данными?

А это без разницы - НФ объявляет вне закона любое соотношение между
данными записей y=f(x), а не только тупое y=x.

Posted via ActualForum NNTP Server 1.4

9 янв 08, 09:48    [5127534]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Dimitry Sibiryakov

kdv
insert into select

А не кажется ли вам, что этот оператор надо вообще запретить, как
нарушающий первую (или вторую) нормальную форму - создающий записи с
повторяющейся информацией?..
Не кажется
9 янв 08, 10:26    [5127683]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

в 1.5.3 это
Two Gotchas with SELECT FIRST

и как кодер должен был догадатся, что это не кривизна SELECT FIRST, а нарушение декларотивности SQL !? из этой ноты следует, что SELECT FIRST вызывает такое зацикливание, где описание природы кривизны ? я например зная о баге и имея нормальный опыт не понимаю почему update a=5, b=a сработает криво, а update с подзапросом нормально. как это влияет на открытые курсоры и т.д. и т.п. подавляющее большинство кодеров не будут себя утруждать проверкой сотен комбинаций вытикающих из этой "Gotcha"
9 янв 08, 12:29    [5128460]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54800

Yo.!
подавляющее большинство кодеров не будут себя утруждать

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

Posted via ActualForum NNTP Server 1.4

9 янв 08, 12:36    [5128498]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 22 23 24 25 26 [27] 28 29 30 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить