LINUX.ORG.RU

Ответ на: комментарий от anonymous

Ну, скажем так, что есть параметры, по которым MySQL превосходит оракел.

Например, с точки зрения вебдевелопера.

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

>Ну, скажем так, что есть параметры, по которым MySQL превосходит оракел.

ну как бы чёб тогда не включить в обзор какой-нить foxbase? он их всех сделает по параметру работы под DOS:)

anonymous
()

Бля Ну как можно так сранивать :
Вот у Постгреса есть ...... , а у Мускуля в "TODO" !!!!
Они хоть на "TODO" у Постгреса смотрели ?

А где сравнение "Тяжёлых" запросов ?
А где сравнение "Нагрузочной способности" ?

Тогда нахрена (вырвалось) там было писать ORACLE,DB2 ....

Этож чистая менеджеровская реклама !!!


ЗЫ ТОДО Постгреса : http://developer.postgresql.org/todo.php
MfG
Konstantin

kred
()

Both databases also support partial rollbacks of transactions...

Может я что-то не так понял, но "partial rollbacks of transactions" это _неполный/частичный_ откат транзакций. Savepoints и вложенные транзакции в PostgreSQL отсутствуют (пока). Насчет My SQL не знаю.

kaaos
()

Ламерская статейка

kelyar ★★★★★
()
Ответ на: комментарий от kred

Действительно, как-то напоминает махание руками в воздухе, сопровождаемоы выкрикиванием знакомых слов. Где хотя бы прикидочные цифры производительности? Где хотя бы примерные таблички с доступной/планируемой фунциональностью? Где рекомендации по использованию (их можно составить, если покопаться в тексте - но в явном, цельном виде я этого не увидел). Короче, текстик очень водянистый. К48 за такой "скришот" поставил бы 1.:)

svu ★★★★★
()

Где сравнительные таблицы?

anonymous
()

Что-то забега то конкретно я там так и не увидел. :\

OpenStorm ★★★
()
Ответ на: комментарий от Sun-ch

>Ну, скажем так, что есть параметры, по которым MySQL превосходит оракел.
>
>Например, с точки зрения вебдевелопера.
Ну, скажем так, что есть параметры, по которым DOS превосходит виндовс NT.

Например, с точки зрения игрока в диггер.

anonymous
()

Там по существу пара обзацеф, остальное - водичка. Так что поставлю этому товарищу 1.

anonymous
()
Ответ на: комментарий от svu

0. K48 по части СУБД сасет, это не шрифтики критиковать

1. Статью я не читал.

Sun-ch
() автор топика

Глуповатая статейка.

Меньше 100Gb - я знаю пользователей имеющих более 5TB данных в MySQL.

И пользователей - "слона то я и не приметил" - Google, Yahoo, LifeJournal используют MySQL.

anonymous
()
Ответ на: комментарий от anonymous

Статья ламерская. А сравнивать нужно, причем именно MySQL с Oracle и прочими. Чтобы знать, когда что лучше ставить и не соваться с Oracle делать базу с одной таблицей в пару десятков записей.

anonymous
()

Глуповатая статейка.

Меньше 100Gb - я знаю пользователей имеющих более 5TB данных в MySQL.

И пользователей - "слона то я и не приметил" - Google, Yahoo, LifeJournal используют MySQL.

anonymous
()
Ответ на: комментарий от anonymous

>я знаю пользователей имеющих более 5TB данных в MySQL

и чёж они с этими 5Тб делають? Хотел бы я посмотреть на тех идиотов которые такой объём доверяю MySQL приходит в голову только одно на х... эти данные никому не нужны. А вооще объём базы сам по себе мало о чём говорит. Хотя я не верю что Мускуль нормально справится с таким объёмом данных даже на очень простых запросах. Ну а на сложной выборке из множества связаных таблиц не дай бог с внешними объединениями Мускуль вооще умрёт.

anonymous
()
Ответ на: комментарий от anonymous

> Ну а на сложной выборке из множества связаных таблиц не дай бог > с внешними объединениями Мускуль вооще умрёт.

Нихера он не умрёт. Попробывал бы сначала что ли :-\ Хотя мускуль я тоже не люблю, но тем не менее, есть задачи, на которых он оптимален.

rk
()
Ответ на: комментарий от rk

>Нихера он не умрёт. Попробывал бы сначала что ли :-\

Да видел я как народ маялся с Мускулем. В результате поставили Соляру и Оракле 8i и как-то всё устаканилось работает себе:)

>но тем не менее, есть задачи, на которых он оптимален

да яж разве спорю? Но не 5Тб базами же ворочать.

anonymous
()
Ответ на: комментарий от ananymous

>зачем линуксу на десктопе СУБДА?

Во-во. Может кто знает вариант Personal DB (типа MS Access) для Х?

anonymous
()
Ответ на: комментарий от anonymous

5TB - Warehouse.

Прекрасно работает. Касаемо данные не нужны - похоже кто-то про Innodb не знает ?

anonymous
()

Пустая статейка, общие рассуждения без тестов.

что касается мускула - он во многих случаях рулит и ораклу там делать нехер

NiKel
()
Ответ на: комментарий от rk

Некоторые присутствующие похоже совсем не понимают о чем говорят, В последний раз когда я колупал этот НеМойSQL (с год назад) он даже вложенные запросы не поддерживал. Никакими внешними объединениями там даже и не пахло, даже в Оракле внешние объединения не реализованы полностью, согласно стандарту SQL. Какие 5ТВ базы? Где вы берете эти цифры? В Oracle 9iR2 максимальный размер файла БД - 64Гб, хотя таких файлов м.б. 64К. Может 5ТВ это суммарный размер всех мускульных баз какого-нибудь крупного провайдера, гы... это больше похоже.

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

anonymous
()
Ответ на: комментарий от anonymous

ОДНОГО файла - может бюыть.... а что мешает сделать ДВА файла или ЧЕТЫРЕ файла или даже 10 файлов... по моему объем базы дам орагничен что-то порядка 200 - 300 терафайт для 9-ки (не факт - лень смотреть), а вот в 10=ке так там макмимальный объем 10 ПЕТАбайт мксмальная база данных пож ораклом в какой-то французской компании - порядка 150 терабайт (вчерась на конференции корпоративные СУБД был там преставительно оракла байки травил :-) ) А если вы считаете что база в оракл - это всегда ОДИН файл - мне вас жалко :-) Хотя может я чего не понял - тогда прошу извинить :-\

anonymous
()

Ну, давайте опять сравнивать скутер, ролики, Жигули, Кадиллак, Субару.. Каждый - для своей задачи и в своей области может быть оптимален. Тот же MySQL - да, хорош в силу легкости освоения и использования для вебдевелоперов, но только для очень небольших (по количеству таблиц и логике) проектов. Отсутствие ряда важных фичей типа тех же встроенных процедур вообще имхо не позволяет его сравнивать с нормальными СУБД типа Oracle. Ссылки на TODO и недавно появившиеся фичи в 4-ой версии типа подзапросов - в _серьезном_ проекте не принимаются категорически - нельзя там рисковать. PostgresSQL - в большинстве случаев отличная база, но иногда поддержка и гарантированная стаблильность важнее денег, тогда уже Oracle. Тем более последний имеет массу дополнительного софта.

anonymous
()
Ответ на: комментарий от anonymous

Ну что за тяга к узкому мышлению :) Кроме вебдизайна никаких вариантов.

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

NiKel
()
Ответ на: комментарий от anonymous

Я ж написал 64К файлов * 64Gb = считать лень. Я это к тому, что не верю в существование MySQL баз в 5Тб.

anonymous
()
Ответ на: комментарий от NiKel

Perl создан для сисадминов, для вебдизайнеров создан PHP - такого бардачного языка я в жизни не видел, бэйсик отдыхает.

anonymous
()

Идиотская статья, кретин автор похоже вообще не понимает, о чём пишет:

> MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method.

Как в PostgreSQL, так и в MySQL с InnoDB движки версионные. А новую версию PostgreSQL с блокировкой на уровне записи можно было придумать только по большой обкурке.

Таблица с фичами вообще п@#дец. Сравниваются стабильные и работающие версии не то, что с альфой, а вообще с vaporware (покажите мне мыскль 5.1, ась?)

sad_spirit
()
Ответ на: комментарий от NiKel

Я вообще и писал что MySQL - для людей которым образование или отсутствие времени не позволяет разобраться в том для чего им вообще СУБД нужна. Именно такие люди радостно запихивают в мусклю буквально все - вплоть до вордовских файлов и jpegов по 5Мб (игнорируя все рекомендации разработчиков самого мускля), вместо того чтобы хранить эти вещи в файловой системе, а в мускле только ссылки на них. Тот же Постгрес справляется со всем этим гораздо лучше, а ресурсов жрет ненамного больше. Вообще не понимаю чего тут сравнивать.

anonymous
()
Ответ на: комментарий от anonymous

> PostgresSQL - в большинстве случаев отличная база

это так, но есть у него такая гадостная фенька -- необходимость периодического vacuum, на время которого все курят.

anonymous
()
Ответ на: комментарий от anonymous

anonymous (*) (23.04.2004 10:27:11):

> необходимость периодического vacuum, на время которого все курят.

необходимость "курить" пропала ещё в версии 7.2, новый vacuum таблицу полностью не блокирует.

так что в сад, мысклежуи

sad_spirit
()
Ответ на: комментарий от anonymous

> Я вообще и писал что MySQL - для людей которым образование или отсутствие времени не позволяет разобраться в том для чего им вообще СУБД нужна.

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

NiKel
()
Ответ на: комментарий от anonymous

Сдается мне, что когда пару месяцев назад был трид про Oracle vs. PostgreSQL, тогда были одни крики, а теперь как-то более-менее цивилизовано. Или еще ортодоксальные постгрящиеся не проснулись? :)
p.s. как там дела с online бекапом в постгресе? продвинулось? :)


Ernesto

anonymous
()
Ответ на: комментарий от NiKel

глупость номер 1:

"Мускль создан для всяких вебдизайнеров"

глупость номер 2:

"MySQL - для людей которым образование или отсутствие времени не позволяет разобраться в том для чего им вообще СУБД нужна"

NiKel
()

> An axiom of open-source software is that developers write it to "scratch an itch."

Какое глубокое представление сути Open Source - пишут, потому что "чешется" ;-)

vashik
()
Ответ на: комментарий от anonymous

Ernesto:

> p.s. как там дела с online бекапом в постгресе? продвинулось? :)

С online бекапом там всё хорошо, pg_dump вполне себе онлайн. И в отличие от утилиты для мыскль + иннодб бесплатен. ;)

А над incremental backup работа идёт, идёт. Вроде бы даже некая крупная компания под это дело денег дала. ;)

sad_spirit
()
Ответ на: комментарий от sad_spirit

Ну да, дампами бекапить это, конечно, круто. Круче наверное только вручную переписывать на бумажку. Настоящее решение для настоящих АБД. :)
p.s. про время восстановления из дампа я промолчу.

anonymous
()
Ответ на: комментарий от anonymous

Тут, по-моему, никто не утверждает, что PostrgeSQL _лучшая_ СУБД. А вот что касается соотношения цена/возможности - то тут как раз PostgreSQL делает многих. А работа в backup направлении, как уже сказали, ведется. В TODO, помимо инкрементального бэкапа, есть еще и point-in-time recovery, причем в разделе "безотлагательных" задач.

kaaos
()
Ответ на: комментарий от anonymous

>Так и надо говорить, что кроме цены - никаких преимуществ. И точка.

Подчас цена - определяющее преимущество, но я все же говорил о соотношении цена/возможности, а этих возможностей у PostgreSQL не так уж и мало.

kaaos
()

Такая вот задачка например - в системе идут мегабайты логов, но чтобы не делать монструозные текстовые файлы перенаправляем все это в базу. Или непрерывно идут вычисления, или снимаются показания с приборов, или берется какая то статистика, того же трафика например. Данные простые но их очень много, впроследствии они обрабатываются перловой или сишной прогой. Ну и что лучше мускула подойдет для этого?

NiKel
()
Ответ на: комментарий от anonymous

>это так, но есть у него такая гадостная фенька -- необходимость периодического vacuum, на время которого все курят.

Зато он BSD, а не GPL.

r ★★★★★
()
Ответ на: комментарий от NiKel

Ну смотри если идут данные по трафику (например нетфлоу) то пихать это все в SQL полное изврат. Я пробовал как то так делать ... и что ты думаеш за 1 час у меня набежало ~500 тыс строк. Ты знаеш скока потом делался простейший селект для выборки общего объема трафика для определенного IP? Поэтому такие данные лучше хранить в BerkeleyDB!

anonymous
()
Ответ на: комментарий от NiKel

Мускул в данном случае работает как еще один слой прослойки до данных ... из SQL преобразовывается в формат хранения (InnoDB or BDB) и потом пишется ... тык зачем нам еще одна прослойка в такой определенной задаче как напр считать и обрабатывать трафик SQL хорош когда изначально неизвестно какие запрсы будут выполняться ...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.