Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
Yo.!!
Guest
2kvd
MS sql express это ни что иное как след. версия MSDE, потому не стоит лезть в бутылку
Di_LIne

С версионностью. во все ее проявлениях, IB/FB/YA - в переди планеты все.
Ибо IB - есть родоначальник версионности... Со всеми втекающими.

чо за лажа ? IB появился через десятилетя после оракловой версионности. там был разве, что Rdb версионность в котором появилось года через 3 после 3й версии оракла, где уже было неблокируемое чтение. Но IB к Rdb ни какого отношения, если не считать пару баек из агенства ОБС.

на счет MySQL, ИМХО он стандарт (до определенных размеров) в задачах типа инет-трафика билинг, складывания логов и т.п. но меня давно волнует вопрос: там появилось понятие bind ?
2 июл 06, 22:12    [2834601]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!!
2kvd
MS sql express это ни что иное как след. версия MSDE, потому не стоит лезть в бутылку
Di_LIne

С версионностью. во все ее проявлениях, IB/FB/YA - в переди планеты все.
Ибо IB - есть родоначальник версионности... Со всеми втекающими.

чо за лажа ? IB появился через десятилетя после оракловой версионности. там был разве, что Rdb версионность в котором появилось года через 3 после 3й версии оракла, где уже было неблокируемое чтение. Но IB к Rdb ни какого отношения, если не считать пару баек из агенства ОБС.

- Фсё! Пипец!
- Оракловская версионность, интербайсовская...
2 июл 06, 22:19    [2834606]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
kdv
p.s. когда Microsoft называет свой MSDE как "Desktop Engine", то я такую интерпретацию воспринимаю совершенно однозначно.
Простите, но, в данном случае, восприятие Вас подводит. MSDE - абсолютно нормальная версия сервера, хотя и с некоторыми ограничениями, которые можно посмотреть здесь. В число таких ограничений не входит монопольный, или однопользовательский, режим доступа к серверу. Подобного ограничения нет ни у одной версии MSSQL.
2 июл 06, 23:11    [2834662]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Хорошо, внимательно просмотрю страницу, и постараюсь ответить на все пропущенные вопросы. Если что-то всё равно не замечу -- вы не стесняйтесь, повторите,)
Di_LIne

Вы можете привести, пусть 10 примеров, бух. или складских программ
на МуСКЛ?

Увы, так же, как не смогу привести и хотя бы пары примеров складских программ на IB/YF/FB, не моя тематика.)
Пожалуй, определённую роль сыграл тут и вопрос лицензий (мы ведь сравниваем MySQL с Firebird, а не ораклом за 100 рублей?) ), MySQL бесплатно распространяется под лицензией GPL, соответственно, в определённых случаях, при распространении софта, использующего эту СУБД, на него также могут распространятся требования GPL, а разработчики "бух. или складских программ" исходники раскрывать обычно либо боятся (а вдруг что-то сломают?), либо жадничают (а кто тогда купит?)

Di_LIne

Тогда скажите, как Вы сами оцениваете скорость MySQL на Win32 и Линухе?

Под Linux оцениваю как удовлетворяющую мои потребности. Под Win32 не оцениваю никак -- предпочитаю не связываться с сколько-нибудь серьёзными задачами под этой ОС. Тестовые базы работали, на них проблем с производительностью не замечал, да и в инете не встречал жалоб на существенную, в разы, разницу в производительности MySQL на Win32 и Linux или FreeBSD.

Di_LIne

- Так что там с MySQL без PHP?!

Простите, на столь неконкретно поставленный вопрос я ответить не смогу. Могу, конечно, перечислить распространённые интерфейсы к MySQL, для других ЯП, но вряд ли вы хотите такого ответа.
Di_LIne

Так где же Ваша объективность?

Абсолютная объективность -- миф. Однако на конкретные вопросы я стараюсь отвечать, отвечать, в меру сил, объективно.
Di_LIne

Так что там с применением MySQL кроме WEB-приложений?
Может быть Вы соизволите что-либо ответить на этот вопрос?

Хорошо, отвечу: я применяю. Вас удовлетворит такой ответ? Если нет, и у вас есть какие-то конкретные сомнения в возможности этого применения -- спрашивайте, постараюсь ответить. Только предметно, а не на уровне "где же миллионы леммингов?".

А теперь, если позволите, мои вопросы и уточнения.

Вы вступили в дискуссию с заявлением, мол, MySQL не подходит для, в частности, применения в баннерных сетях. Не подходит из-за
1. неустойчивости к взлому;
2. недостаточной производительности на транзакциях select+insert+index
По первому пункту мы, вроде бы, пришли к выводу, что к собственно СУБД в баннерной сети он имеет крайне опосредованное отношение. Подтверждаете ли вы этот вывод?
По второму же, вы сослались на довольно косвенные результаты тестирования mnoGoSearch, которые были не в пользу MySQL.
Тут я хотел бы заметить, что не вижу большой потребности в использовании частых апдейтов в реализации баннерной сети, но этот момент можно было бы обсуждать при какой-то конкретной предъявленной реализации.
Если не затруднит, дайте ссылочку на описание этого тестирования? Я, конечно, смогу его найти, но у вас довольно много постов на форуме, это займёт некоторое время, а по каноническому названию mnoGoSearch найти ту тему не выходит.
Тут я, конечно, проявил определённую субъективность, предположив, что в качестве ОС на вебсервере будет использоваться FreeBSD (возможно, в какой-то степени меня извиняет тот факт, что _КАКАЯ_ТО_ ОС на вебсервере всё равно будет использоваться, и на вебсерверах довольно часто это именно FreeBSD), и заметил, что возможность использования только классического режима в Firebird под FreeBSD вряд ли положительно отразится на привлекательности Firebird для решения данной конкретной задачи. По-моему, в этом был определённый резон, вы не находите? Также вы тут довольно невнятно высказались о преимуществах версионности Firebird (очевидно, перед оной в MySQL)... И надо сказать, из дальнейшего выяснения этих преимуществ я узнал лишь, что саму идею версионности придумали в IB, а значит, жёлтые штаны -- два раза "ку", а MySQL здесь не стояло, однако, конкретных претензий к версионности InnoDB я так и не услышал. Простите мне это хулиганство, я тут покрупнее напишу, чтобы вы не пропустили вопрос таки
Так что вас не устраивает в версионности InnoDB?
Не сочтите за какое-то давление, просто я этот вопрос несколько раз задал, а ответа не получил, мне оно как-то даже интересно, может быть, я действительно что-то важное не замечаю?

Ну и последний момент, который хотелось бы уточнить:
Di_LIne
DocAl

А не надо горячиться... Вот и вопрос о том, как через один коннект обрабатывать много параллельных транзакций вы пропустили сгоряча,)

Ок. Отвечаю: - В DLL устанавливаю соединение с Базой и через N-ое кол-во
ДатаСетов верчу и кручу Базу.

Я правда не знаю, потому и спрашиваю: если Firebird запущен в классическом режиме, и с ним проворачивают такой фокус, то для всех этих ДатаСетов будет общие буфера, и один процесс сможет одновременно и _параллельно_ обрабатывать несколько запросов?
2 июл 06, 23:15    [2834665]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

на счет MySQL, ИМХО он стандарт (до определенных размеров) в задачах типа инет-трафика билинг, складывания логов и т.п. но меня давно волнует вопрос: там появилось понятие bind ?

Поясните суть понятия bind в данном контексте, и я попробую ответить.
2 июл 06, 23:16    [2834666]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!!
Guest
DocAl

Поясните суть понятия bind в данном контексте, и я попробую ответить.

в пхп это наверно выглядело бы так:
$sql = "select * from mytable where column=:param" ;
mysql_prepare($sq);
mysql_bind('param', $myvariable);
mysql_execute($sql) ;

т.е. сервер выполняет не просто строку с sql, а строку с "прибиндиными" переменными, у oracle это снижает кол-во hard parse, и гемороя с sql injection
2 июл 06, 23:26    [2834678]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Yo.!!
чо за лажа ? IB появился через десятилетя после оракловой версионности. там был разве, что Rdb версионность в котором появилось года через 3 после 3й версии оракла, где уже было неблокируемое чтение. Но IB к Rdb ни какого отношения, если не считать пару баек из агенства ОБС.
Чо за лажа ? (с)
Даты давай, про "десятилетя"
2 июл 06, 23:33    [2834685]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

Поясните суть понятия bind в данном контексте, и я попробую ответить.

в пхп это наверно выглядело бы так:
$sql = "select * from mytable where column=:param" ;
mysql_prepare($sq);
mysql_bind('param', $myvariable);
mysql_execute($sql) ;

т.е. сервер выполняет не просто строку с sql, а строку с "прибиндиными" переменными, у oracle это снижает кол-во hard parse, и гемороя с sql injection

Ммм... Наверное, нету, по крайней мере, я для этого использую sprintf.)
Впрочем, не исключено, что что-то подобное можно сделать через хранимку, но... Как-то это перректально.)
2 июл 06, 23:34    [2834687]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!!
Guest
2hvlad
сори, похоже погорячился oracle это 83й, Interbase 86й, но самое интересное, что оказывется оракл вырос из Rdb !?
http://www.oracle.com/technology/products/rdb/pdf/2003_tech_forums/13_rdbs_first_20_years.pdf
я потрясен
3 июл 06, 00:03    [2834725]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
насколько я помню oracle dbms, oracle rdb и oracle codacyl dbms - это разные по сути продукты. Последние 2 - творения dec.
3 июл 06, 01:05    [2834759]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Yo.!!
2hvlad
сори, похоже погорячился oracle это 83й, Interbase 86й,
В 86-ом была уже 2-я версия : http://www.ibase.ru/ibhistory.htm

Yo.!!
но самое интересное, что оказывется оракл вырос из Rdb !?
http://www.oracle.com/technology/products/rdb/pdf/2003_tech_forums/13_rdbs_first_20_years.pdf
я потрясен
Первое упоминание в этом документе о версионности в RDB/VMS находится на 26-ой странице и относится к версии 4.1, которая вышла в конце 91-го года (стр. 28)
3 июл 06, 01:24    [2834763]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!!
Guest
hvlad
В 86-ом была уже 2-я версия : http://www.ibase.ru/ibhistory.htm

ну да, первой то и небыло, это у них мода такая - первый продукт называть 2.0 (у оракла тоже небыло 1й версии). а вообще я не вижу никакой связи Rdb и Interbase. ну кто-то перешел в другую компанию и начал писать с нуля новую субд, код то им DEC не отдал. Судя по моему документику часть людей делавших Rdb из DEC и в оракл свалили, но это не говорит о родстве систем.
3 июл 06, 01:42    [2834766]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Старки
Nat and I overlapped at CCA in the mid-1970s before I went to DEC. The SDD-1 project with Dave Shipman, and Jim Rothnie came much later. Bernstein collaborated, but was then an assistant professor at Harvard, not a CCA employee.

Bernstein was later hired by DEC, who had funded much of his earlier research. He had published a claiming there only two or three four ways to concurrency control, only so many ways to recovery, etc., so there were only a small number of ways to write a database system, so people were wasting their time thinking out it any. We argued quite a bit since Rdb/ELN essentially broke his argument. He eventually conceded the point (this was around 1983/84).

He never mentioned an earlier paper on multi-generational concurrency control, and I was certainly unaware of it. It would have been very interesting reading.

As for pre-Interbase commercial use of multi-generational concurrency control, of course there was one -- DEC's Rdb/ELN. Not only did it use much the same technology as InterBase, it was also called JRD.

The inspiration for multi-generational concurrency control was a database system done by Prime that supported page level snapshots. The intention of the feature was to give a reader a consistent view of the database without blocking writers. The idea intrigued me as a very useful characteristic of a database system. Sometime later, and I member the exact instant, it occurred to me that a single mechanism could be used to provide a static snapshot, provide a transaction recovery mechanism, and handle concurrency control. The DEC JRD started a few days later as an advanced development project, and was later picked up by DEC's storage systems as the software core for a database machines based on the HSC disk controller, code named "Hawk". The first product in the family was Jayhawk, a dedicated server implementation on the MicroVax-II using Dave Cutler's VAX Eln operating system. Cutler took a fancy to JRD and decided he'd rather have a full blown relational database than an ISAM system, so we agreed to do a first release on ELN and ELN's development system, VMS.


vs

Джекобс
We indeed had multiversioning in V3. We had a separate Before Image (BI) file
that had old block copies. It was used to provide non-blocking reads, and
avoid read-write contention. However, for some reason I don't recall exactly,
we didn't apply read consistency to indexes, or properly stop a scan or
something. I would have to think harder to recall the precise details (and
maybe I'm too old to ever remember precisely!).

A statement would see its own changes in a funny way. Thus, a statement like
this

insert into emp
select * from emp

would in fact read the very rows it was inserting and with 14 rows in EMP you
might end up with either an infinite loop (I don't recall that ever happening)
or some "random" (unpredictable) number of rows!
3 июл 06, 01:50    [2834767]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
cooluser
Member

Откуда: Новосибирск
Сообщений: 233
Di_LIne

Не спорю: использовали в них PHP+МуСКЛ.
Если выбросить из рассмотрения стыковку PHP <-> МуСКЛ, то что остается от МуСКЛ?
Вы можете привести, пусть 10 примеров, бух. или складских программ
на МуСКЛ?


Еще раз повторюсь, основное и главное преимущество MySQL для разработки под Web - это хорошая интеграция с языком PHP. :)

Поэтому действительно, если выборосить PHP, от Мускуля останется гораздо меньше толку :)
3 июл 06, 06:42    [2834828]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Yo.!!
сори, похоже погорячился oracle это 83й, Interbase 86й

86й - это Interbase. До этого было другое название (до сих пор в расширении файла этот атавизм присутствует:-)). Так и Oracle по-другому назывался. Кстати, в 3-й версии оракла версионность была. Но насколько версия была работоспособной?
3 июл 06, 09:59    [2835129]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

Не спорю: использовали в них PHP+МуСКЛ.
Если выбросить из рассмотрения стыковку PHP <-> МуСКЛ, то что остается от МуСКЛ?
Вы можете привести, пусть 10 примеров, бух. или складских программ
на МуСКЛ?


Еще раз повторюсь, основное и главное преимущество MySQL для разработки под Web - это хорошая интеграция с языком PHP. :)

Поэтому действительно, если выборосить PHP, от Мускуля останется гораздо меньше толку :)

Ну, допустим, интеграция с MSSQL не сказать чтобы сильно хуже была, однако... Даже простейшая задача, вроде постраничного вывода, требует уже каких-то ухищрений.
3 июл 06, 12:46    [2836138]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
cooluser
2. MySQL вроде народ использует в серьезных проектах, не только для вебморд, в области приложений для автоматизации хостинга, проблем особых нет, правда там размеры БД не очень большие

Что касается личного опыта использования MySQL, то он показал себя крайне плохо при больших нагрузках на INSERT, порядка 10 запросов на вставку в секунду приводят сервер в штопор.
Скорее всего вы не читали доки/ мадо работали с MySQL.
на MyISAM - действительно может быть проблема с большим количеством параллельных Insert-ов.
InnoDB - её решает + транзакции, триггер и т.п.

PS не агитирую за MySQL, просто укажываю на неточность аргументов.
3 июл 06, 13:08    [2836314]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
cooluser
Di_LIne

Не спорю: использовали в них PHP+МуСКЛ.
Если выбросить из рассмотрения стыковку PHP <-> МуСКЛ, то что остается от МуСКЛ?
Вы можете привести, пусть 10 примеров, бух. или складских программ
на МуСКЛ?


Еще раз повторюсь, основное и главное преимущество MySQL для разработки под Web - это хорошая интеграция с языком PHP. :)

Поэтому действительно, если выборосить PHP, от Мускуля останется гораздо меньше толку :)
Если выбросить PHP, то останется SLQ-server

а лучше или хуже ИМХО нужно выяснять по конкретным задачам.
Для чего-то лучше, для чего-то нет.

К примеру логи хранить, биллинг. если нужно много-платформенность (не идет MS SQL), и нет денег (не подходит Oracle) - то мозможно для конкретной задачи пойдет MySQL.

PS уже есть множество приложений (не только Веб), которые by design работают только (или наиболее обкатаны) на MySQL.
3 июл 06, 13:28    [2836448]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
cooluser
Member

Откуда: Новосибирск
Сообщений: 233
VoDA
cooluser
2. MySQL вроде народ использует в серьезных проектах, не только для вебморд, в области приложений для автоматизации хостинга, проблем особых нет, правда там размеры БД не очень большие

Что касается личного опыта использования MySQL, то он показал себя крайне плохо при больших нагрузках на INSERT, порядка 10 запросов на вставку в секунду приводят сервер в штопор.
Скорее всего вы не читали доки/ мадо работали с MySQL.
на MyISAM - действительно может быть проблема с большим количеством параллельных Insert-ов.
InnoDB - её решает + транзакции, триггер и т.п.

PS не агитирую за MySQL, просто укажываю на неточность аргументов.


Да всё я читал...И ветку про проблему с Insert на этот форуме заводил, никто ничего не ответил конкретного, сейчас некогда искать, если кому интересно найду
3 июл 06, 14:06    [2836716]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Буду отвечать раздельно, двбы не мешать усе в кучу.
В рамках дискуссии - это наиболее удобно. имхо, конечно.


DocAl
Хорошо, внимательно просмотрю страницу, и постараюсь ответить на все пропущенные вопросы. Если что-то всё равно не замечу -- вы не стесняйтесь, повторите,)
Di_LIne

Вы можете привести, пусть 10 примеров, бух. или складских программ
на МуСКЛ?

Увы, так же, как не смогу привести и хотя бы пары примеров складских программ на IB/YF/FB, не моя тематика.)
Пожалуй, определённую роль сыграл тут и вопрос лицензий (мы ведь сравниваем MySQL с Firebird, а не ораклом за 100 рублей?) ), MySQL бесплатно распространяется под лицензией GPL, соответственно, в определённых случаях, при распространении софта, использующего эту СУБД, на него также могут распространятся требования GPL, а разработчики "бух. или складских программ" исходники раскрывать обычно либо боятся (а вдруг что-то сломают?), либо жадничают (а кто тогда купит?)
- FireBerd & Yaffil - бесплатные. Конкретные условия - см. у них.
- А что там у МуСКЛ с лецензионностью по Винду?

DocAl

Di_LIne

Тогда скажите, как Вы сами оцениваете скорость MySQL на Win32 и Линухе?

Под Linux оцениваю как удовлетворяющую мои потребности. Под Win32 не оцениваю никак -- предпочитаю не связываться с сколько-нибудь серьёзными задачами под этой ОС. Тестовые базы работали, на них проблем с производительностью не замечал, да и в инете не встречал жалоб на существенную, в разы, разницу в производительности MySQL на Win32 и Linux или FreeBSD.

- Наверное это от задач зависит. Крутить табЫлычку на 100 кил и.. BDE может.
Но, если не изменяет мне память, у 4-ку МуСКЛ это отмечалось...

DocAl
Di_LIne

Так что там с применением MySQL кроме WEB-приложений?
Может быть Вы соизволите что-либо ответить на этот вопрос?

Хорошо, отвечу: я применяю. Вас удовлетворит такой ответ? Если нет, и у вас есть какие-то конкретные сомнения в возможности этого применения -- спрашивайте, постараюсь ответить. Только предметно, а не на уровне "где же миллионы леммингов?".

Я не сормневаюсь в вашей правдивости, конечно применяете.
Но... Сравнивая 2 Сервера мы с Вами должны уходить от личных пристрастий.
Ибо каждый использует то, что знает и умеет.



DocAl

А теперь, если позволите, мои вопросы и уточнения.

Вы вступили в дискуссию с заявлением, мол, MySQL не подходит для, в частности, применения в баннерных сетях. Не подходит из-за
1. неустойчивости к взлому;
2. недостаточной производительности на транзакциях select+insert+index
По первому пункту мы, вроде бы, пришли к выводу, что к собственно СУБД в баннерной сети он имеет крайне опосредованное отношение. Подтверждаете ли вы этот вывод?

(выделение мое....)
- Нет и еще раз нет. Наверное мы с Вами по разному понимаем термин "баннерная сеть". По этому, для уточнения позиций, предлагаю рассматривать ее ИЗНУТРИ.
А по сему: насосом баннерной сети является SQL-сервер.
И как же "крайне опосредованное" отношение может имет ЭТА
неотемлемая, и определяющая часть?


DocAl

По второму же, вы сослались на довольно косвенные результаты тестирования mnoGoSearch, которые были не в пользу MySQL.
Тут я хотел бы заметить, что не вижу большой потребности в использовании частых апдейтов в реализации баннерной сети, но этот момент можно было бы обсуждать при какой-то конкретной предъявленной реализации.

Хм... Фиксация времени последней выдачи баннера из базы - НЕ ЕСТЬ UPDATE??
Интересно, а как Вы тогда предлагаете организовывать ОЧЕРЕДЬ?

DocAl

Если не затруднит, дайте ссылочку на описание этого тестирования?

Хорошо, я сам это поищу.


DocAl

Я, конечно, смогу его найти, но у вас довольно много постов на форуме, это займёт некоторое время, а по каноническому названию mnoGoSearch найти ту тему не выходит.
Тут я, конечно, проявил определённую субъективность, предположив, что в качестве ОС на вебсервере будет использоваться FreeBSD (возможно, в какой-то степени меня извиняет тот факт, что _КАКАЯ_ТО_ ОС на вебсервере всё равно будет использоваться, и на вебсерверах довольно часто это именно FreeBSD), и заметил, что возможность использования только классического режима в Firebird под FreeBSD вряд ли положительно отразится на привлекательности Firebird для решения данной конкретной задачи.

То есть, Вы утверждаете, что SQL-сервер в WEB-проектах должен крутиться под той-же ОС, что и WEB-сервер?
То есть, классический подход комерческого хостинга?..
- Сорри, конечно, но такое я даже не рассматривал. По той причине, что условия хостинга меня ограничивают априоре. Но, для серьезного поекта, это не вариант. Для примера (пробегала такая инфа):
SQL.RU - использует 3 машины:
1. WEB-сервер + 2 SQL-сервер-а (front-end).
И я рассматриваю только такой вариант: Пиво с МУХАМИ - отдельно....
3 июл 06, 16:13    [2837517]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
автор
it was also called JRD

что расшифровывается, кстати, как Jim's Relational Database. То есть СУБД Starkey.

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

Собственно, вижу версионность только в последнем движке InnoDB.
http://dev.mysql.com/doc/refman/5.0/en/innodb-multi-versioning.html

правда, я не понимаю, как такая версионность сочетается с тем, что
http://dev.mysql.com/doc/refman/5.0/en/innodb-lock-modes.html
shared lock (read) конфликтует с exclusive lock (update/delete).
3 июл 06, 16:40    [2837698]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
DocAl
Так что вас не устраивает в версионности InnoDB?
Не сочтите за какое-то давление, просто я этот вопрос несколько раз задал, а ответа не получил, мне оно как-то даже интересно, может быть, я действительно что-то важное не замечаю?

- Не устраивает... все! Серьезно.
1. Разнообразие "движков", каждый из которых "заточен" под конкретную цель.
Ставя так вопрос, Вы уходите за рамки темы дискуссии, ибо тогда нужно сравнивать MySQL с разными движками с одним FB.
И если я задам Вам вапрос - что там с версионностью в MySQL?
Вам ответить будет сложно, так как придется Вам описывать КАЖДЫЙ движок.
Что есть голый факт.
И у меня очень большие сомнения, что применяя разные движки, ко всем ним МОЖНО применять одно название - MySQL.


DocAl

Ну и последний момент, который хотелось бы уточнить:
Di_LIne
DocAl

А не надо горячиться... Вот и вопрос о том, как через один коннект обрабатывать много параллельных транзакций вы пропустили сгоряча,)

Ок. Отвечаю: - В DLL устанавливаю соединение с Базой и через N-ое кол-во
ДатаСетов верчу и кручу Базу.

Я правда не знаю, потому и спрашиваю: если Firebird запущен в классическом режиме, и с ним проворачивают такой фокус, то для всех этих ДатаСетов будет общие буфера, и один процесс сможет одновременно и _параллельно_ обрабатывать несколько запросов?

Если сервер - SS, то да! Если CS - нет.
И у Вас не было бы этих вопросов, если бы Вы ознакомились с ЭТИМ
3 июл 06, 16:41    [2837702]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
Yo
MS sql express это ни что иное как след. версия MSDE, потому не стоит лезть в бутылку

я не лезу в бутылку. И знаю что такое MS SQL Express.

автор
Но IB к Rdb ни какого отношения, если не считать пару баек из агенства ОБС.

я уже вижу ты и сам нашел ссылки, в дополнение могу сказать, что Джим обозвал системные таблицы IB как RDB$ вовсе не с потолка. Версионность же в самом Оракле (не Oracle rdb, который был DEC rdb), появилась, если мне не изменяет память, где-то в 1987 году. IB был сделан в 1984-1985.
3 июл 06, 16:46    [2837736]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!!
Guest
kdv

я уже вижу ты и сам нашел ссылки, в дополнение могу сказать, что Джим обозвал системные таблицы IB как RDB$ вовсе не с потолка. Версионность же в самом Оракле (не Oracle rdb, который был DEC rdb), появилась, если мне не изменяет память, где-то в 1987 году. IB был сделан в 1984-1985.


попробую повторить: RDB и JDB это разработки компании DEC и никакого отношения к интербейзу не имеют, ваще никакого. компания-предок IB появилась на 2, повторяю на 2 года позже работающего оракла, а первая версия этой компании (ib2) на 3 года позже. то что какие-то люди из DEC переходили в оракл или IB ничего не менят или если берштейн перешел в мс, то теперь mssql автоматически стал родствиником db2 ?

автор
A statement would see its own changes in a funny way. Thus, a statement like
this

insert into emp
select * from emp

would in fact read the very rows it was inserting and with 14 rows in EMP you
might end up with either an infinite loop (I don't recall that ever happening)
or some "random" (unpredictable) number of rows!

Гы-гы, а interbase так и остался funny ...
3 июл 06, 17:12    [2837907]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Di_LIne
- FireBerd & Yaffil - бесплатные. Конкретные условия - см. у них.
- А что там у МуСКЛ с лецензионностью по Винду?

Вы находитесь во власти каких-то странных иллюзий...
Вообще говоря, лицензии GPL абсолютно по-барабану, виндовс у вас, линукс ли, да хоть ско юниксварь или сан солярис. Там совсем другие требования: если вы разрабатываете ПО на основе исходников какого-то программного продукта, распространяемого по лицензии GPL, вы обязаны выполнять требования лицензии. Такие как: при распространении вашего ПО вы должны распространять его по лицензии GPL, к каждой копии продукта должен прилагаться текст лицензии, и должны обеспечить возможность свободного получения исходников вашего ПО по цене носителя. Что, кстати, не означает, что вы не можете брать деньги за результат своего труда. Также это не означает, что если вы разрабатываете какой-то продукт для внутреннего использования в своей компании, не предназначенный для распространения, то вы обязаны предоставлять его исходные тексты любому желающему, это не так. Firebird, кстати, тоже не в public domain, и распространяется по вполне определённой лицензии, у которой тоже есть свои требования.
Di_LIne

- Наверное это от задач зависит. Крутить табЫлычку на 100 кил и.. BDE может.
Но, если не изменяет мне память, у 4-ку МуСКЛ это отмечалось...

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

Я не сормневаюсь в вашей правдивости, конечно применяете.
Но... Сравнивая 2 Сервера мы с Вами должны уходить от личных пристрастий.
Ибо каждый использует то, что знает и умеет.

Послушайте, я не могу быть совершенно беспристрастен, как и вы, как и кто-либо ещё. Также я не могу с той же степенью уверенности обсуждать чьё-либо ещё использование чего бы то ни было, как собственное. Я предлагаю вам задавать конкретные вопросы, какие именно вы видите принципиально неразрешимые проблемы в использовании MySQL вне веб?
Заметьте, я уже не первый раз предлагаю разрешить ваши сомнение, если вы сформулируете их конкретно, а не междометиями, и каждый раз вы предлагаете мне отрешиться от личных пристрастий и... на этом мысль заканчивается, вроде. По поводу пристрастности позиция выглядит, кстати, довольно неоднозначно: вы утверждаете, что вне веба MySQL ничего не светит, да и в вебе-то так себе, в баннерных сетях вот... небезопасен... Зато Firebird-то какой гигантище, и с разбега, и на месте, и двумя ногами вместе, просто какой-то Fireeagle, а не Firebird! Я же, не ставя под сомнение применимость Firebird вне веба заметил лишь, что на одной из распространённой ОС для веба Firebird для веба же использовать будет затруднительно, по вполне определённой и названной мною причине. Также я утверждаю, что не вижу принципиальных причин для полнейшей невозможности использования MySQL вне веба. Если вы видите какие-то конкретные причины для этого -- так давайте их обсудим, а не будем страдать фигнёй отрешаясь и выпрямляя чакры?
Di_LIne

- Нет и еще раз нет. Наверное мы с Вами по разному понимаем термин "баннерная сеть". По этому, для уточнения позиций, предлагаю рассматривать ее ИЗНУТРИ.
А по сему: насосом баннерной сети является SQL-сервер.
И как же "крайне опосредованное" отношение может имет ЭТА
неотемлемая, и определяющая часть?

Я не знаю, что вы понимаете по-разному. В баннерной сети СУБД наружу не торчит, вся её "уязвимость" заключается в sql injections и подобных воздействиях. sql же injection, не является сама по себе уязвимостью СУБД, это упущение в логике работы сервера приложения. И если вместо MySQL в этой гипотетической баннерной сети будет использоваться Firebird, он точно так же, с поправкой на возможные особенности диалекта SQL словит эту иньекцию, именно поэтому я говорю, что отношение тут крайне опосредованное.
Di_LIne

DocAl

По второму же, вы сослались на довольно косвенные результаты тестирования mnoGoSearch, которые были не в пользу MySQL.
Тут я хотел бы заметить, что не вижу большой потребности в использовании частых апдейтов в реализации баннерной сети, но этот момент можно было бы обсуждать при какой-то конкретной предъявленной реализации.

Хм... Фиксация времени последней выдачи баннера из базы - НЕ ЕСТЬ UPDATE??
Интересно, а как Вы тогда предлагаете организовывать ОЧЕРЕДЬ?

Ну например, INSERT и секционирование? MySQL поддерживает concurrent inserts.
Di_LIne

DocAl

Я, конечно, смогу его найти, но у вас довольно много постов на форуме, это займёт некоторое время, а по каноническому названию mnoGoSearch найти ту тему не выходит.
Тут я, конечно, проявил определённую субъективность, предположив, что в качестве ОС на вебсервере будет использоваться FreeBSD (возможно, в какой-то степени меня извиняет тот факт, что _КАКАЯ_ТО_ ОС на вебсервере всё равно будет использоваться, и на вебсерверах довольно часто это именно FreeBSD), и заметил, что возможность использования только классического режима в Firebird под FreeBSD вряд ли положительно отразится на привлекательности Firebird для решения данной конкретной задачи.

То есть, Вы утверждаете, что SQL-сервер в WEB-проектах должен крутиться под той-же ОС, что и WEB-сервер?
То есть, классический подход комерческого хостинга?..
- Сорри, конечно, но такое я даже не рассматривал. По той причине, что условия хостинга меня ограничивают априоре. Но, для серьезного поекта, это не вариант. Для примера (пробегала такая инфа):
SQL.RU - использует 3 машины:
1. WEB-сервер + 2 SQL-сервер-а (front-end).
И я рассматриваю только такой вариант: Пиво с МУХАМИ - отдельно....

Ну, во-первых, SQL-сервера тут будут не front-end, а как раз таки наоборот.)
Во-вторых, не знаю, в курсе ли вы, но гетерогенные среды могут доставлять много головной боли, а если и не много, то в любом случае, не меньше чем гомогенные. Потому, если у меня будет выбор, ставить ли на вебсервере FreeBSD, и на СУБД FreeBSD, или же на вебсервере FreeBSD, а на СУБД Linux -- я скорей всего предпочту первый вариант, отвлекаясть от субъективизма, могу предположить, что любой зравомыслящий человек, столкнувшись с таким вопросом, сначала задумается, нужен ли ему зоопарк, и есть совсем не нулевая вероятность, что он решит, что не нужен.

А насчёт версионности вопрос вы так и проигнорировали, некрасиво выходит...
3 июл 06, 17:37    [2838055]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить