Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
hvlad

а) Разжевано предостаточно
б) Достаточно вежливо спросить непонятое. Не в этом форуме, а рядом

а) нет даже базовых вещей (уровни изолированости, работа оптимайзера и т.п.)
б) у вас рядом уж больно люд неадекватный ...
21 ноя 07, 19:48    [4947297]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Megabyte
FB - полнофункциональный SQL-сервер. А MySQL - урезанная СУБД, разве что в 5-й версии многое обещали сделать(не работал).

на счет урезаного mysql - если вдруг FB достигнет уровня технологий mysql 3.x это будет невиданый прорыв: у fb есть 2 архитектуры - смешная classic где каждая сессия имеет отдельный кеш и прикольная superserver, где все сессии вроде имеют единый кеш, но юзать может лишь один core (это в эру 4-8 core процесоров). между FB 2.x и mysql4/innodb просто пропасть ...
21 ноя 07, 21:04    [4947428]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67462
Блог
Megabyte
на всех местах работы логику по максимуму переносят на сервер

Пока звучит разумно, но слова "по максимуму" вызывают подозрение - вопрос в том, что именно под ними подразумевается.

Megabyte
дабы не зависеть от клиентской части, ибо тогда можно править логику не имея доступа к исходникам клиента!

Угу, начинается типичная дурость. Почему-то большинству людей в голову не лезет больше одного звена. Поэтому одни тянут "все на клиента", другие - "все на сервер", третьи - "все на аппсервер". Оставшиеся якобы звенья при этом сугубо декоративны, выполняют сугубо техническую роль. Под это иногда подтягиваются очень громкие обоснования, но если копнуть, в реальности оно оказывается очень простым: "вот это звено я делать вроде как слегка научился, поэтому затяну все сюда - а то те мне совсем подозрительны". Результатом этого является кривейшая архитектура, огромные паразитные нагрузки и необходимость синхронно править все звенья для решения простейших задач. Как следствие, бурно растут левые "интерпретаторы метаданных", весь смысл которых - попытаться за счет гибкости и удобства пользователя смягчить кривизну архитектуры.

Megabyte
Ну и естественно меньше передача данных на сервер = меньше траффик!

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

Почему вроде бы умные люди затрудняются в написании именно многозвенных систем - для меня, увы, загадка :(
21 ноя 07, 21:20    [4947467]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Yo.!

на счет урезаного mysql - если вдруг FB достигнет уровня технологий mysql 3.x это будет невиданый прорыв: .

И зачем это MySql переманил к себе разработчика - аффтара этих старых технологий? Наверное чтобы он откатил им 5-ку обратно до тройки.
22 ноя 07, 08:14    [4948030]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

на счет урезаного mysql - если вдруг FB достигнет уровня технологий mysql 3.x это будет невиданый прорыв: .

И зачем это MySql переманил к себе разработчика - аффтара этих старых технологий? Наверное чтобы он откатил им 5-ку обратно до тройки.
А вы не знаете? Чтобы разрабатывать дополнительный движок таблиц, не меняя архитектуры системы, а лишь развивая её гибкость. Потому как к разработчикам двух имеющихся транзакционных движков проявил недвусмысленный интерес Оракл. Никоим образом не умаляя их заслуг, к разработчикам даже не файрбёрда, а интербейса пока проявил интерес только MySQL AB.)
22 ноя 07, 16:56    [4951621]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
Чтобы разрабатывать дополнительный движок таблиц,
не меняя архитектуры системы, а лишь развивая её гибкость.
гы!
это кто-то тебе нашептал, или сам так решил?

зы: я уж умолчу о характере "старого волчары"
и его понятиях что такое "гибкость"...


ззы: а "мульён" движков одной СУБД - это каша, а не СУБД...

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

Posted via ActualForum NNTP Server 1.4

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

Откуда: Моск.
Сообщений: 8541
Джим надеется, что основной движок мускуля перенимет некоторые фичи фалькона как многотабличные полнотекстовые индексы и ролевую систему прав доступа, но пока он просто прикручивает движок.
22 ноя 07, 18:14    [4952219]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5019
Yo.!
Megabyte
FB - полнофункциональный SQL-сервер. А MySQL - урезанная СУБД, разве что в 5-й версии многое обещали сделать(не работал).

на счет урезаного mysql - если вдруг FB достигнет уровня технологий mysql 3.x это будет невиданый прорыв:

Прикалываешься? В MySQL ниже 5-й версии нет того, что имхо должно быть в нормальном SQL-сервере! Даже, по-моему, спор бессмыслен... Какие там технологии у Мускуля?

softwarer
1)Пока звучит разумно, но слова "по максимуму" вызывают подозрение - вопрос в том, что именно под ними подразумевается.
2)Угу, начинается типичная дурость. Почему-то большинству людей в голову не лезет больше одного звена. Поэтому одни тянут "все на клиента", другие - "все на сервер", третьи - "все на аппсервер"...

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

4)Почему вроде бы умные люди затрудняются в написании именно многозвенных систем - для меня, увы, загадка :(


1) По максимуму = вся логика работы с БД, не включая логиру работы приложения(!), т.е. мухи отдельно, котлеты отдельно.

2), 4) Не понял, как связан перенос логики работы с БД на сервер БД с многозвенным построением приложений?
Как я вижу классическую 3-хзвенку:
а) интерфейс, чисто морда, без завязки на бизнес-процессы.
б) бизнес-процесс, логика работы, формирующая по условиям из интерфейса параметры для вызова, например, ХП на сервере.
в) скомпилированный код на сервере БД в виде ХП, который реализует нужную выборку в зависимости от параметров.

Ситуация: Ушел разработчик, все запросы на клиенте. Пусть это был отчет, изменились условия выборки. теперь надо ввести поправочный коэффициент. Что делать? Надо вызывать разработчика, чтоб тот влез в код клиента и правил запрос. Если же все реализовано на сервере, то достаточно спеца. кот. рюхает SQL, он исправит код на сервере.
И даже если у тебя 3-хзвенка, запрос все равно же в код вшит, или вы запросы отдельно в текстовом файле будете хранить? Ну тогда особо "грамотные" юзеры вам его поправят! :)
Или я вас не понял, опишите свой вариант без переноса логики на сервер?

3) Ну про кривость системы, думаю, нет смысла говорить, она от СУБД и языка не зависит, согласны? %)
Пример вообще не в кассу, либо я не понял его смысла!
22 ноя 07, 18:25    [4952281]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
maXmo
Member

Откуда: Моск.
Сообщений: 8541
Megabyte
Если же все реализовано на сервере, то достаточно спеца. кот. рюхает SQL, он исправит код на сервере.
На чём бы ни была написана бизнес-логика, всегда достаточно спеца, который рюхает в том, на чём она написана. На SQL тут ни разу свет клином не сошёлся.
22 ноя 07, 18:46    [4952370]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5019
maXmo
Megabyte
Если же все реализовано на сервере, то достаточно спеца. кот. рюхает SQL, он исправит код на сервере.
На чём бы ни была написана бизнес-логика, всегда достаточно спеца, который рюхает в том, на чём она написана. На SQL тут ни разу свет клином не сошёлся.

Понимаешь, не всегда есть доступ к исходникам!!! Да и даже если есть, при правильной организации труда должно быть четкое разделение обязанностей. Спец. по клиентской части не всегда будет рюхать хорошо SQL.
22 ноя 07, 19:14    [4952499]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
maXmo
Member

Откуда: Моск.
Сообщений: 8541
Megabyte
Понимаешь, не всегда есть доступ к исходникам!!!
вы за опенсорс?

Megabyte
Спец. по клиентской части не всегда будет рюхать хорошо SQL.
хорошо рюхать в SQL надо лишь в одном случае: если собираешься писать на SQL всю бизнесс-логику: хранимки по тыще строк, триггер на триггере и т.п.
22 ноя 07, 20:24    [4952686]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Раз пошла такая пьянка, что у Firebird с масштабируемостью? В плане использования многоядерных систем, количества параллельных соединений и т.п.?
22 ноя 07, 20:46    [4952719]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl
Раз пошла такая пьянка, что у Firebird с масштабируемостью?

За пару килобаксов я тебе на ней даже отказоустойчивый кластер с
распределением нагрузки подыму.

Posted via ActualForum NNTP Server 1.4

23 ноя 07, 09:36    [4953549]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5019
maXmo
хорошо рюхать в SQL надо лишь в одном случае: если собираешься писать на SQL всю бизнесс-логику: хранимки по тыще строк, триггер на триггере и т.п.

Бред, за такие ХП руки отрывать надо!
А насчет рюхания - каждому свое. Краткость - сестра т. %)
Вот начальник сказал переделать логику в одной ХП, избавиться от пары параметров(были разные параметры для Update, Insert в виде строки для dynamic SQL), но при этом написать кусок кода по парсингу другого, общего для Insert и Update параметра, размером в 2 десятка строк. И смысл? Ну избавились от пары праметров, зато читаемость ухудшилась. И вообще не понимаю, зачем объединять в одной процедуре 2 действия: Insert, Update.
Сам бы так не сделал. Процедура 165 строк меня уже напрягает. Да, универсальность, но предпочитаю разумный подход между унивесальностью и размерами кода!
DocAl
Раз пошла такая пьянка, что у Firebird с масштабируемостью? В плане использования многоядерных систем, количества параллельных соединений и т.п.?

Сам с нуля не поднимал сервер, но работал с уже крутящимся, работающем в реальном масштабе времени. Одновременно работающих пользователей около 60. Кол-во транзакций за единицу времени не большое(сорри, просто не знаю), но постоянно идет нагрузка. Размер БД там был маленький(<1Гб), поэтому приводить в качестве примера не имеет смысла
23 ноя 07, 11:32    [4954187]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
maXmo
Member

Откуда: Моск.
Сообщений: 8541
Кстати, из-за таких адептов опенсорса некоторые деятели тут стали искать способ скрыть исходники хранимок и вроде что-то такое нашли в оракле, так что и на вашей улице будет праздник :)
Хмм… а вам что, лицензия на систему позволяет её дорабатывать? Тогда странно, почему разрабы исходники не дали.
А если захочется подправить именно гуй, второго спеца искать будешь?
23 ноя 07, 12:27    [4954615]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

DocAl
Раз пошла такая пьянка, что у Firebird с масштабируемостью?

За пару килобаксов я тебе на ней даже отказоустойчивый кластер с
распределением нагрузки подыму.
Posted via ActualForum NNTP Server 1.4
На целеронах?
Я спрашиваю, как распределяется нагрузка на многоядерных системах? Благо, нынче это обыденность, даже ноуты двухядерные выпускают.
23 ноя 07, 15:50    [4956349]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Я спрашиваю, как распределяется нагрузка на многоядерных системах?
линейно

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

Posted via ActualForum NNTP Server 1.4

23 ноя 07, 15:53    [4956357]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
DocAl

Я спрашиваю, как распределяется нагрузка на многоядерных системах? Благо, нынче это обыденность, даже ноуты двухядерные выпускают.

чукча писатель ;) ?
23 ноя 07, 15:56    [4956377]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Мимопроходящий

DocAl
Я спрашиваю, как распределяется нагрузка на многоядерных системах?
линейно
А этому есть какие-то подтверждения? Опубликованные результаты тестов?
23 ноя 07, 15:58    [4956386]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl

Я спрашиваю, как распределяется нагрузка на многоядерных системах?

А я тебе отвечаю: как забашляешь интегратору, так она и распределится.
Пожмотишься - вообще распределяться не будет.

Posted via ActualForum NNTP Server 1.4

23 ноя 07, 15:59    [4956391]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

Я спрашиваю, как распределяется нагрузка на многоядерных системах? Благо, нынче это обыденность, даже ноуты двухядерные выпускают.

чукча писатель ;) ?
Нет, мне просто интересно услышать мнение адептов файрбёрда по этой теме. Услышал.
Хотя, если кто-то напишет на эту тему подробно и по делу, с ссылками на результаты тестирования и т.п. это будет многим полезно, думаю.
23 ноя 07, 16:03    [4956421]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Хотя, если кто-то напишет на эту тему подробно и по делу,
D> с ссылками на результаты тестирования и т.п. это
D> будет многим полезно, думаю.
а ты попроси Йоу.
он специалист во многих областях незнания.

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

Posted via ActualForum NNTP Server 1.4

23 ноя 07, 16:19    [4956518]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
maXmo
Джим надеется, что основной движок мускуля перенимет некоторые фичи фалькона как многотабличные полнотекстовые индексы и ролевую систему прав доступа, но пока он просто прикручивает движок.

О! А эт наверно евойный (Джима) начальник.
27 ноя 07, 08:29    [4966512]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
maXmo
Member

Откуда: Моск.
Сообщений: 8541
я эти слова почерпнул с форума фалькона
27 ноя 07, 11:13    [4967296]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
arax83
Member

Откуда: Красноярск
Сообщений: 2
Господа, я прочитал все это обсуждение, но ответа на свой вопрос так и не нашел. Поэтому задам его :)
Итак, мне нужно определиться с выбором СУБД для веб-приложения (система ГИС). Как я представляю, такая система будет делать довольно много выборок данных, причем не элементарных и не для одного пользователя. Записи в базу будут не слишком часты.
Причем Firebird имеет некоторые преимущества, не связанные с вопросом выбора СУБД (база уже есть, она от стороннего поставщика, но написана изначально для локального применения).
Всвязи с переходом на веб, нужно решить: стоит ли оставаться на Firebird или портировать БД в MySQL и использовать его.
21 дек 07, 20:04    [5082986]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить