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

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

Dimitry Sibiryakov
Именно из доки

Хотя нет - вру. О непригодности к серьезной эксплуатации - действительно
из доки. А про баги - на левом сайте.
Posted via ActualForum NNTP Server 1.4
По-секрету, поделюсь с вами официальным сайтом, где можно почитать про баги: http://bugs.mysql.com/
Кстати, у фаербёрда есть багтреккер?
В качестве ответной любезности, хотелось бы узнать, из каких разделов документации MySQL вы узнали о непригодности оного к серьёзной эксплуатации, а из каких разделов документации Firebird -- к его пригодности?
29 дек 07, 15:44    [5111751]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
DocAI
Кстати, у фаербёрда есть багтреккер?

а то. имеющий очи, и знающий про www.firebirdsql.org легко может увидеть ссылку
Firebird Tracker
http://tracker.firebirdsql.org/

DocAI
вы узнали о непригодности оного к серьёзной эксплуатации

ну вы же говорите, что FB непригоден к эксплуатации - типа "небольшие" базы, и "небольшое" кол-во пользователей. Вот и мы делаем такой же вывод про MySQL, Oracle, MS SQL и остальные СУБД. Тоже по документации...

p.s. если у читателей этого топика плохо с чувством юмора, то сообщаю, что последний абзац этого поста - ирония.
29 дек 07, 18:08    [5111990]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
А, ну если чисто поржать, так вот, посмейтесь, баг, которому, как минимум 17 лет.
Что б ни говорили адепты фаербёрда, нифиговый такой баг, нарушающий саму декларативную природу SQL.
З.Ы. Для тех читателей топика, у кого плохо с чувством юмора, сообщаю, что я в курсе, что это баян (за 17-то лет!), но до чего ж смешной, обхохочешься!
29 дек 07, 18:41    [5112038]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
автор
баг, которому, как минимум 17 лет.

все, кто пытается уязвить Firebird или InterBase, тычут в этот "баг". Который, кстати, не фатален и легко обходится.

автор
нифиговый такой баг, нарушающий саму декларативную природу SQL.

да конечно, охрененный баг, который делает невозможной работу с IB/FB (опять ирония, замечу).
И нарушает ВСЮ ДЕКЛАРАТИВНУЮ ПРИРОДУ SQL! А природу-то надо беречь!!!

автор
но до чего ж смешной, обхохочешься!

да скучно, честное-слово. нашли бы чего-нибудь еще, посвежее.

p.s. а у Оракла null = ''. Оракел ацтой.
29 дек 07, 21:13    [5112304]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
автор
баг, которому, как минимум 17 лет.

все, кто пытается уязвить Firebird или InterBase, тычут в этот "баг". Который, кстати, не фатален и легко обходится.
Дык потому что ему сто лет в обед, а всё не пофиксят. Отсутствие оператора UPDATE, кстати, тоже легко обходится. При дОлжном уровне фанатизма, можно "легко обходить" и отсутвие, например, бакапа. Давайте обходиться малым, оно ведь бесплатно, и даже как-то убого работает!
29 дек 07, 21:51    [5112355]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
А, ну если чисто поржать, так вот, посмейтесь, баг, которому, как минимум 17 лет.
Что б ни говорили адепты фаербёрда, нифиговый такой баг, нарушающий саму декларативную природу SQL.
Ух ты, ну прямо нарушение Матрицы :)

Если уж на то пошло, как обстоят дела с этим списком странностей MySQL-я? Среди них такие серьезные, как:

Division by zero - нарушает принципы машинной арифметики, при делении на нуль дает null вместо ошибки
NULL, or when NULL IS NOT NULL - нарушает трехзначную логику
February 31st - нарушает Григорианский календарь, одну из основ нашей цивилизации
;)

я, собственно, к тому, что у каждого сервера свои "скелеты в шкафу"; если такую "странность", можно обойти, то и придавать уж очень большое значение этому "багу" не стоит. Через некоторое время работы с сервером разработчик узнает эти странности и узнает как их обходить.

Как выяснилось, на Firebird успешно работают БД большие по объему и с множеством пользователей; это было бы невозможно, если бы он был "игрушечной" СУБД, как тут его часто пытаются представить.
29 дек 07, 21:51    [5112356]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

Если уж на то пошло, как обстоят дела с этим списком странностей MySQL-я? Среди них такие серьезные, как:

Division by zero - нарушает принципы машинной арифметики, при делении на нуль дает null вместо ошибки
NULL, or when NULL IS NOT NULL - нарушает трехзначную логику
February 31st - нарушает Григорианский календарь, одну из основ нашей цивилизации
;)

я, собственно, к тому, что у каждого сервера свои "скелеты в шкафу"; если такую "странность", можно обойти, то и придавать уж очень большое значение этому "багу" не стоит. Через некоторое время работы с сервером разработчик узнает эти странности и узнает как их обходить.

Конкретно эти -- пофикшены, самое позднее, в районе альф пятёрки, т.е. года 2-3 назад. Например
mysql>SET SESSION sql_mode='TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE null_1 (
    ->   id INT NOT NULL,
    ->   text1 VARCHAR(32) NOT NULL,
    ->   text2 VARCHAR(32) NOT NULL DEFAULT 'foo'
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO null_1 (id) VALUES(1);
ERROR 1364 (HY000): Field 'text1' doesn't have a default value
mysql> INSERT INTO null_1 (text1) VALUES('test');
ERROR 1364 (HY000): Field 'id' doesn't have a default value
Кстати, там в комментариях это указано.

Ни одному из этих багов не было и близко 17-ти лет, большинство, если не все, были, как минимум, не более значительны, чем указанное посмешище, однако, их исправили, а не отмазывались про несущественность и легкообходимость.
29 дек 07, 22:16    [5112383]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
DocAl
Давайте обходиться малым, оно ведь бесплатно, и даже как-то убого работает!
Не зарывайся
29 дек 07, 23:03    [5112478]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl
из каких разделов документации MySQL вы узнали

MySQL - Triggers. Кому нужны триггера, в которых ничего нельзя делать?..
После этого смотреть чего там нельзя делать в ХП совсем не хочется.

Posted via ActualForum NNTP Server 1.4

31 дек 07, 22:01    [5114073]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
DocAI
Дык потому что ему сто лет в обед, а всё не пофиксят. Отсутствие оператора UPDATE, кстати, тоже легко обходится. При дОлжном уровне фанатизма, можно "легко обходить" и отсутвие, например, бакапа. Давайте обходиться малым, оно ведь бесплатно, и даже как-то убого работает!

по моему Вы в своем злобствовании переходите всякие разумные границы.
в Firebird якобы "баг" insert into select, а именно видимость вставляемых записей селектом (без order by или ограничения where), является архитектурной особенностью, если хотите. И это не просто какая-то ошибка в коде, которую раз- и исправил.
к слову, запрос insert into select from, который зацикливается, является в большинстве случаев ИДИОТИЧЕСКИМ. Поэтому под "обходом" я имел в виду в том числе и корректное задание where в таком
select.

Кстати, я думаю что Вам это пытались объяснить года 2 или 3, т.е. столько, сколько Вы тут злопыхаете. Мне кажется, что обсуждать этот вопрос с Вами бессмысленно, т.к. если Вы хотите найти изъян, Вы найдете его в любом месте. Например, будете утверждать что FB плох тем, что Хорсун живет на Украине, а Еманов - в Пензе.
6 янв 08, 16:33    [5122464]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
по моему Вы в своем злобствовании переходите всякие разумные границы.
в Firebird якобы "баг" insert into select, а именно видимость вставляемых записей селектом (без order by или ограничения where), является архитектурной особенностью, если хотите. И это не просто какая-то ошибка в коде, которую раз- и исправил.
к слову, запрос insert into select from, который зацикливается, является в большинстве случаев ИДИОТИЧЕСКИМ. Поэтому под "обходом" я имел в виду в том числе и корректное задание where в таком
select.

Кстати, я думаю что Вам это пытались объяснить года 2 или 3, т.е. столько, сколько Вы тут злопыхаете. Мне кажется, что обсуждать этот вопрос с Вами бессмысленно, т.к. если Вы хотите найти изъян, Вы найдете его в любом месте. Например, будете утверждать что FB плох тем, что Хорсун живет на Украине, а Еманов - в Пензе.
Reference manual по фаербёрду отсутствует, SMP в суперсервере нет, проблема двойной буферизации в классической архитектуре решается методом страуса, баги, нарушающие декларативность SQL, живут вечно и провозглашаются фичами, мне совершенно фиолетово, где живут разработчики любой СУБД, а вы, kdv, можете продолжать работать напёрсточником, я вам более не мешаю.
6 янв 08, 17:03    [5122506]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl
Reference manual по фаербёрду отсутствует

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

Posted via ActualForum NNTP Server 1.4

6 янв 08, 19:04    [5122709]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
DocAl
проблема двойной буферизации в классической архитектуре решается методом страуса, баги, нарушающие декларативность SQL
Похоже, "спецы" вроде Ё размножаются...
Или это многодневная пьянка так влияет...
6 янв 08, 19:31    [5122743]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

DocAl
Reference manual по фаербёрду отсутствует

Ну а у мускуля он есть, и что - от этого у него лог транзакций появился
или из триггеров стало можно обращаться к таблицам?
Posted via ActualForum NNTP Server 1.4
А что, лог транзакций куда-то исчезал?
И в чём конкретно у вас проблема с обращением к таблицам?
7 янв 08, 07:04    [5123369]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl
А что, лог транзакций куда-то исчезал?

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

Кстати, об отличных доках:
MySQL5
But remember that functions are subject to severe
limitations: you cannot access tables from within a function.
Precisely the same limitation applies for triggers.

MySQL5
Triggers are very new. There are bugs. Therefore I give the
same warning that I gave for stored procedures. Do not try triggers with
a database that has important data in it.

MySQL5
The manual used also to say that a trigger can delete from
another table, or is activated when you delete a transaction, whatever
that is supposed to mean. Forget that, the MySQL implementation can't do
such things.

Ну и покажите мне на примерах, как я могу получить протокол всех
операций в базе этого... "СУБД". Т.е. кто (имя пользователя) что
(название операции) с чем (имя таблицы и значение РК) и когда делал.

Posted via ActualForum NNTP Server 1.4

7 янв 08, 19:31    [5124397]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Документация, вот она. А статьи, статьи всякие бывают. Да и, понятное дело, статьи могут и устареть, а документация поддерживается в актуальном состоянии. Цитата про триггера, например, из статьи трёхлетней давности. Таки да, в MySQL вводятся новые функции, и во время бета-тестирования с этими функциями могут быть проблемы.
Более конкретно на вопросы отвечу завтра, сейчас нет времени, сорри.
7 янв 08, 20:05    [5124467]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl
Документация, вот она. А статьи, статьи всякие бывают.

Т.е. Peter Gulutzan - так, журналамер...

Ну что ж, открываем refman, смотрим:
RefMan
In MySQL 5.1, you can write triggers containing direct
references to tables by name

Т.е. к версии 5.1 в триггере уже можно сделать что-то полезное,
вот только
RefMan
There cannot be two triggers for a given table that have
the same trigger action time and event.

Т.е. всю логику надо пихать в один триггер. Стало быть я должен как-то
извлечь из базы триггер, распарсить его, добавить свои операторы
протоколирования если их там еще нет... Пожалуй, проще будет сказать
шефу "нет, мускуль может и можно будет поддержать в нашем репликаторе,
но только года через 3-4 и то если они доведут его до ума".

Posted via ActualForum NNTP Server 1.4

7 янв 08, 20:31    [5124500]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
DocAI
Reference manual по фаербёрду отсутствует,


тыщу раз уже говорил. документация по IB 6 + FB Release Notes. Неудобно?
Да. Пока нет достаточно энтузиастов. Дока в виде книги - ЕСТЬ. (Х. Борри)

DocAI
SMP в суперсервере нет


пока - нет. используйте классик.

DocAI
, проблема двойной буферизации в классической архитектуре решается методом страуса

где страус, и где проблемы? Я опять спрошу - Вы теоретик? Вы практически в классике где видите проблемы в реальных системах? Или так, опять потрындеть, потеоретизировать?

DocAI
баги, нарушающие декларативность SQL

прекратили-бы уж этот звездеж по поводу ОДНОЙ конструкции insert from select (ну и допустим delete where field in select). Почему Вы одно это поведение выпячиватете как вообще нарушение "декларативности SQL"? Очередной местный ЧАЛ? Ошибки и недостатки в SQL других серверов Вы отказываетесь видеть?

DocAI
мне совершенно фиолетово, где живут разработчики любой СУБД, а вы, kdv, можете продолжать работать напёрсточником, я вам более не мешаю.


не желаю общаться с узколобыми маньяками. диагноз. Я хоть вижу достоинства и недостатки как FB так и других серверов. А Вы в FB только недостатки видите. Т.е., другие сервера идеальны? За сим оставляю Вас в Ваших заблуждениях.
7 янв 08, 22:20    [5124689]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
не желаю общаться с узколобыми маньяками. диагноз. Я хоть вижу достоинства и недостатки как FB так и других серверов. А Вы в FB только недостатки видите. Т.е., другие сервера идеальны? За сим оставляю Вас в Ваших заблуждениях.
Честно говоря, могу вам сказать лишь то же самое.
Некоторые недостатки вы признаёте, если про них популярно рассказывать пару недель, тыкая в то подобие документации, что есть у фаербёрда. А некоторые не признаются никак, наперекор простейшей логике.
Ведь совершенно понятно, что если в классической архитектуре два разных соединения работают с одними и теми же данными, то эти данные будут храниться в буферах обоих соединений, вот вам и двойная буферизация, а если хочется получить приличную производительность, чтобы и третье (десятое) соединение тащило эти данные не с диска, приходится надеяться также и на третью копию этих данных в памяти: в файловом кэше. Но ничего, заради халявы (а какие ещё известны достоинства фаербёрда?) не жалко и 4,6 гигов оперативки на 160 соединений. Будет 600 соединений -- докидаем до 16 гигов, никаких проблем, подумаешь, пятисоткратная буферизация!
8 янв 08, 07:18    [5125125]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

DocAl
А что, лог транзакций куда-то исчезал?

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

Для работы с бинарным логом используется отдельная утилита, идущая вместе с сервером. В принципе, согласен, что реализация работы с логом через стандартный API была бы более удобна, хотя MySQL -- не единственный пример подобной реализации.

Тот же бинарный лог можно использовать и для аудита работы с БД. С теми же оговорками.

По поводу статей, ещё раз повторяю, что статья трёхлетней давности может устареть. Будь её автор хоть семи пядей во лбу, но если он пишет статью "что появилось в бете(альфе) MySQL 5.0", то он и пишет про альфу или бету, честно предупреждая, что описываемые возможности пока реализованы экспериментально, и не следует ими пользоваться на критичных к потерям данных.
В общем-то, эти нововведения до сих пор достаточно новые, но теперь это не вопрос стабильности работы и потери данных, но ограничений функциональности, что затрудняет работу с ними, а иногда даже заставляет отказаться от их использования (например, пока триггера не срабатывают при каскадном обновлении/удалении по внешнему ключу).
Однако, 5.1 уже в статусе релиз-кандидата, так что работа идёт.

Кстати, по поводу
RefMan
In MySQL 5.1, you can write triggers containing direct
references to tables by name

вы так поняли ситуацию. В 5.1 это возможно в любой версии, а в 5.0 эта возможность была введена в 5.0.10 (июль 2005).

По поводу одного триггера на одно событие, согласен, что это неудобно, но это "легко обходится" (с) kdv
8 янв 08, 07:46    [5125138]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
В MySQL, кстати, есть свой встроенный репликатор.
8 янв 08, 07:49    [5125141]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
DocAl
вот вам и двойная буферизация

Сразу видно, что человек не понимает, о чём говорит.
Вот у нас в бухгалтерии на новый год одна девушка пришла в обтягивающем прикиде, вот у неё буферизация так буферизация Картинка с другого сайта.
8 янв 08, 08:55    [5125175]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
не жалко и 4,6 гигов оперативки на 160 соединений. Будет 600 соединений -- докидаем до 16 гигов, никаких проблем,
Ну у меня, например, несколько другие цифры. Каждое соединение отъедает около 6 MB. Итого, на 500 соединений- 3 GB. Вероятно, эта цифра (память на одно соединение класика) зависит от задачи, отчего именно, я не интересовался. /на всякой случай уточняю, кол-во юзеров у меня небольшое, ~20 /

У меня вопрос, тут пару страничек назад как-то быстро пролетел разговор о лицензии MySQL но пролетел как-то быстро, без ясного ответа. Допустим, я делаю проект для сторонней фирмы, т.е. у меня закрытый код, они получают только исполнимый файл, и заготовку БД. В таком случае, по всей видимости, MySQL надо покупать? Во всяком случае здесь так сказано.
8 янв 08, 12:15    [5125500]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
S.G.
У меня вопрос, тут пару страничек назад как-то быстро пролетел разговор о лицензии MySQL но пролетел как-то быстро, без ясного ответа. Допустим, я делаю проект для сторонней фирмы, т.е. у меня закрытый код, они получают только исполнимый файл, и заготовку БД. В таком случае, по всей видимости, MySQL надо покупать? Во всяком случае здесь так сказано.
Если вы используете ODBC или что-то подобное и подключаетесь к MySQL как к стандартному источнику данных -- вряд ли тут возможно настаивать на приобретении коммерческой лицензии на MySQL. А вот если вы используете нативные драйвера MySQL -- тогда да, надо покупать. Впрочем, можно приобрести какие-нибудь коммерческие компоненты доступа, типа MyDAC (никогда не юзал, потому не могу рекомендовать как-то особо, просто название на слуху, запоминается легко )
8 янв 08, 13:22    [5125641]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
fynda
Member

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

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


Ладно, фиг с ним с логом, скажите - нормальный бэкап у mySQL появился уже, хотя бы в виде отдельной утилиты? Или по-прежнему надо базу часами из скрипта восстанавливать?
8 янв 08, 13:44    [5125704]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 21 22 23 24 25 [26] 27 28 29 30 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить