Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
DocAl
Apex
Ведь сейчас ты бы уже вряд ли начал новый проект под MySQL...

Да вот этого предположения, собственно..

Во-первых: потому что он уже имел удовольствие поработать с полнценными СУБД. Во-вторых: он сам мне однажды так сказал.
21 сен 06, 16:20    [3168867]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Понятно, чистый флейм...
21 сен 06, 17:02    [3169166]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
DocAl
Понятно, чистый флейм...

А ты что ожидал? Все плюсы и минусы почти всех СУБД уже давно обсудили...
21 сен 06, 18:06    [3169534]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
NFox
Member

Откуда:
Сообщений: 2
Уважаемые гуру SQL
Скажите пожалуста начинающему юзеру если на машину поставить два SQL сервера (FireBird 1.5 и MySQL 5) будут они конфликтовать друг с другом??

Просто один нужен для работы программы, а второй для поднятия веб-сервера(движка портала)

Заранее благодарен
17 янв 07, 22:05    [3657121]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
NFox
Уважаемые гуру SQL
Скажите пожалуста начинающему юзеру если на машину поставить два SQL сервера (FireBird 1.5 и MySQL 5) будут они конфликтовать друг с другом??

Если не будут делить одну базу....
Но... Мощи-то хватит, железной. А то оба присядут....
17 янв 07, 22:18    [3657137]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
NFox
Member

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

Если не будут делить одну базу....
Но... Мощи-то хватит, железной. А то оба присядут....


Нет.. Базы разные.
Сама по себе база FireBird находится на другом сервере.. на этом просто клиент
А для MySQL будет новая база создана.
17 янв 07, 22:41    [3657175]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
NFox
Нет.. Базы разные.
Сама по себе база FireBird находится на другом сервере.. на этом просто клиент

Это как? Что-то там химичешь не понятное...
FireBird дАлжон быть на той же машине, что и база.
А где клиент - FireBird не волнует...

NFox

А для MySQL будет новая база создана.

Эта гражданочка не из моего батальона...
17 янв 07, 22:49    [3657187]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
doubleJ
кстати, только что товарищ по аське скинул:

1. С использованием ядерных хидеров (типа /usr/include/linux -> /usr/src/linux/include/linux) MySQL просто не компилируется даже!!!
2. Релизы 5.0.20 и 5.0.21 откомпилировать мне вообще не удалось НИКАК. "Internal compiler error".

3. Релиз 5.0.22 Г**НО. Хотя его и удалось откомпилировать, но зато часть _ЭЛЕМЕНТАРНЕЙШИХ_


Че за гон ?
MySQL конечно не идеален, но не так что бы не компилиться. Ну у меня-то он компилиться как-то.
А если запросы валят сервер - на это есть тесты в MySQL test suit, которые надо прогонять, чтобы удостовериться, что все ОК. Скорее всего кривые руки виноваты.

Например, могу предположить, что афтар не запускал скриптов автоконфигурации, а стал собирать с теми Makefile-ами, которые лежат в дистрибутиве.

[qout double]
4. А удаление из таблички в исполнении п***ров из Мускля - это просто песня. Если в Постгресе хотя бы просто отмечается, что строка удалена (а потом автовакуум почистит), то гениальнейшие разработчики мускля сделали проще!!! ОНИ ПРОСТО СОЗДАЮТ НОВУЮ ТАБЛИЧКУ, В КОТОРУЮ КОПИРУЮТ СОДЕРЖИМОЕ СТАРОЙ С ИСКЛЮЧЕНИЕМ УДАЛЕННЫХ СТРОК!!!
[/quot]

Ну это просто гон. Может он с ALTER TABLE перепутал ? DELETE так не делается.
Вообще, как удаляются записи из таблицы, зависит от конкретного Engine-а, а не от MySQL. Да, может на CSV-енджине так и делается (этот энджин хранит таблицы в Comma-separated values-формате, в текстовом файле, так как же там еще-то удалить запись ? ). Но зачем использвать этот энджин для OLTP ? (на самом деле этот энджин только для экспорта-импорта данных нужен).
В общем парень нагнал. Я MySQL не очень люблю конечно, но истина дороже.
18 янв 07, 10:57    [3658607]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Anton Lukyanov
ну тогда файрберд, уговорили
по крайней мере 100% лучше чем MySQL, которая хороша только для SELECT * FROM tablename


Предвзятое отношение. Как раз с Interbase/Firebird MySQL вполне может тягаться. И MVCC есть в главном энджине, и многозадачность есть, и полнофункциональный SQL с процедурами и триггерами. Я бы даже пожалуй из двух зол выбирал бы MySQL, но это скорей потому, что я его хоть чуть-чуть знаю. Interbase знаю только по фичам.
И кстати лог есть нормальный в InnoDB, там не надо каждую страницу измененных данных на диск сбрасывать (как я понимаю, в Interbase другого пути к Durability нет).
18 янв 07, 11:04    [3658659]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
nxdev
Может, кто-либо сказать что-то хорошее о MySQL, как сервера для разработки не Web-ориентированных приложений (может хоть чем-то лучше от Firebird)


А я не понимаю, при чем здесь вообще WEB ? MySQL - универсальная СУБД, "для всего". Ну да, есть PHP для него, но это ж ничего не значит. У них только лицензирование на WEB послабленное.
И все.
18 янв 07, 11:08    [3658692]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
VoDA
insert into table
select ...
from table

Уводил interbase (возможно и его клонов) в бесконечный цикл. т.е транзакция видит результаты своей деятельности.


Да, это известный классический глюк I-base. Там какие-то проблемы со statement-level isolation. Но может быть их уже разрешили, это было-то сколько лет назад.

Даже MySQL такого себе не позволяет.

Не факт, будет зависить от Engine. Вот я как раз сейчас багу правлю, которая имменно с этим связана. Только бага в другую сторону - не видит своих изменений транзакция.
18 янв 07, 11:51    [3659212]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
cooluser
Что касается личного опыта использования MySQL, то он показал себя крайне плохо при больших нагрузках на INSERT, порядка 10 запросов на вставку в секунду приводят сервер в штопор.


Заявление НЕ обоснованное. Производительность INSERT очень зависит от Engine-а и его настроек. В частности, транзакционные движки должны быть помедленнее в теории.
18 янв 07, 11:55    [3659275]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
MasterZiv

Да, это известный классический глюк I-base. Там какие-то проблемы со statement-level isolation. Но может быть их уже разрешили, это было-то сколько лет назад.

неа не разрешили и в планах даже нет, т.е. судя по развитию этой чудо-субд еще 5-10 бага останется. И лога транзакций там до сих пор нет ... так что mysql действительно посерьезней как субд будет.
18 янв 07, 12:02    [3659371]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!
И лога транзакций там до сих пор нет...

Хм... А что, этот атавизьм еще в Мускуле есть?
А-а-а... Ну да... Извините. Это из-за отсутстви самих транзакций видимо...
Появились говорите? Ну да, ну да... Откатывать-то механизм транзакций как без их логов-то....
18 янв 07, 12:21    [3659556]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
kdv
Насчет версионности InnoDB - в прошлом году, в марте, только что-то говорили, что вот мол, и в MySQL "тоже будет версионность", правда, и ACID транзакций вроде не одолели.
А сейчас вообще, MySQL рассматривает InnoDB как "нелюбимую дочь".


Не понял . Как не одолели ? Три уже движка есть, поддерживающие полностью ACID-транзакции.
Один (InnoDb) давно уже и штатным образом применяется в промышленных системах на базе MySQL. И InnoDB появился в MySQL далеко не в прошлом году. В марте уже говорили о том, что InnoDB был куплен Oracl-ом и тогда MySQL потенциально мог остаться без самого ходового транзакционного движка. До этого InnoDB уже работал достаточно долго. Но сейчас уже год (2007) как MySQL работает по соглашению с Oracle-InnoDB о распространении MySQL c InnoDB, и этот год будет работать так же. Так что про "нелюбимую дочь" тоже как-то мимо.

Так что что-то вы не то говорите, видимо по принципу "слышал звон ....".
18 янв 07, 12:40    [3659749]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Di_LIne
И если я задам Вам вапрос - что там с версионностью в MySQL?
Вам ответить будет сложно, так как придется Вам описывать КАЖДЫЙ движок.


Да не придется. Только в одном движке - InnoDB - есть версионность, (точнее в двух, но все равно свойства одинаковые и там, и там). Причем мало чем она отличается от I-Base-овской -
только тем что в InnoDB она не является средством обеспечения Durability.
18 янв 07, 12:44    [3659808]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Di_LIne

Хм... А что, этот атавизьм еще в Мускуле есть?
А-а-а... Ну да... Извините. Это из-за отсутстви самих транзакций видимо...
Появились говорите? Ну да, ну да... Откатывать-то механизм транзакций как без их логов-то....

совет: не повторяйте всякую чуш за мимоходящим, лог (REDO) нужен накатывать транзакции, откатывание (UNDO) немного другая история ...
18 янв 07, 12:52    [3659872]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Di_LIne

Если НЕТ, то чем оно тогда принципиально отличается от LIKE?


Видимо тем, что позволяет делать быстрый поиск по словам в середине текста, а не в его начале.
18 янв 07, 12:55    [3659898]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!
совет: не повторяйте всякую чуш за мимоходящим, лог (REDO) нужен накатывать транзакции, откатывание (UNDO) немного другая история ...

Тогда может быть поясните исключительную необходимость применения ОБОИХ механизмов сразу?
18 янв 07, 13:26    [3660250]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Di_LIne

Тогда может быть поясните исключительную необходимость применения ОБОИХ механизмов сразу?


еще раз - UNDO (откат транзакций) это другая опера, в ИБ клонах она решается чуток по другому. Речь идет о востановлении базы после сбоя путем накатывания лога транзакций на бэкап, это совсем другая задача ничего общего с UNDO не имеет (например в оракле REDO лог защищает за одно и UNDO лог).
зачем нужно накатывать и почему неканает shadow/raid разьяснено например в оракловой доке ...
18 янв 07, 13:51    [3660543]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32892

Привет, Yo.!!
Ты пишешь:

Yo.!
Y> зачем нужно накатывать и почему неканает shadow/raid
Y> разьяснено например в оракловой доке ...
которую йоу чтит как Библию
и рекомендует для всех серверов,
независимо от архитектуры...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

18 янв 07, 13:53    [3660571]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!
[Речь идет о востановлении базы после сбоя путем накатывания лога транзакций на бэкап....

Что-то мне поскучнело... На кой енто мне сдалось? База крутится уже пол-года, в пике до 10 транзакций в секунду.
- Размер такого лога?
- Время восстановления при "накате" лога?
18 янв 07, 13:56    [3660611]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Di_LIne

Что-то мне поскучнело... На кой енто мне сдалось? База крутится уже пол-года, в пике до 10 транзакций в секунду.
- Размер такого лога?
- Время восстановления при "накате" лога?

на кой ?! доверять базу субд которая в любой момент может похерить всю бд в 21 веке глупо, любая юзерская ошибка или глючек контролера и востановить можно только с бэкапа (если повезет учитывая фичу "невостановимый бэкап" клонов иб). ну а дальше считаем за кокое время лишится админ яиц если проебал хотя бы несколько минут работы при 10 транзакций в секунду ...
18 янв 07, 14:13    [3660794]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!
на кой ?! доверять базу субд которая в любой момент может похерить всю бд в 21 веке глупо...

Абсолютно согласен! И имеющийся в FB механизм защиты от сбоев - меня удолетворяет.
Специально над ним, FB, издивались, как только смогли придумать...
И меня очень настораживает тот факт, что у БД, кроме Б/Р есть еще второй, дополнительный мезанизм "защиты"...
- Вы можете себе представить АКМ (который Калашникова) с логированием транзакций?


Yo.!

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

Сколько у Вас лично таких было бекапов? В процентах... 10? 5? 1?

Yo.!

ну а дальше считаем за кокое время лишится админ яиц если проебал хотя бы несколько минут работы при 10 транзакций в секунду ...

Согласен! Полностью... А что из него, целиком, сделают за многочасовой откат по логу?..
18 янв 07, 14:48    [3661157]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Di_LIne

- Вы можете себе представить АКМ (который Калашникова) с логированием транзакций?

современный мобильник вполне сравним с сервером который тянул какую-то задачку на оракле8 лет 8 назад, причем памяти в мобильнике на порядок больше. в калашников весь RAC легко запихнут...

Di_LIne
Согласен! Полностью... А что из него, целиком, сделают за многочасовой откат по логу?..

накат, лог накатывают (на бэкап). не знаю как у mysql, но например оракл может предсказать сколько займет востановление, 10 tps на ночной бэкап не думаю, что дольше 10-15 минут идти будет на современном сервере... пару лишних гб и 10 минут на востановление имхо вполне адекватная цена за сохранность генеталий
18 янв 07, 15:13    [3661410]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить