Хрен & Палец. Сравнительный анализ

Fixed

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

Там автор похоже курит не качественную траву - первые слова о Pg и тут же полная чушь:

История постгрес началась в 1977 г. с базы данных Ingress.

Кроме похожего названия Ingress никоим боком не связан с Pg

В 1986 г. в университете Беркли, Калифорния, она была переименована в PostgreSQL.

Postgres и PostQL, SQL там не было.

В 1995 г. постгрес стала открытой базой данных. Появился интерактивный psql.

OSS с первой версии

про mysql тоже ерунда.

Давайте забаним статью :)

спасибо, хорошая, годная статья.

> Давайте забаним статью :)

Я за то, чтобы забанить IBM_dw. Формальная причина - это бот. Причем, плохой.

ни о чём

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

Это не бот. Это Оля

> Хрен & Палец

Первое - это растение, да?

Весьма гурман'ный вброс

Баян вспомнился:

гражданином Непала считается каждый, зачатый Непалкой и Непальцем...

Очень косвенно упомянуто про массивы в постгресе. А они рулят, они могут индексироваться, у них может быть переменная длина, и вообще во многих ситуациях спасают от кучи дополнительных таблиц. Мускуль так не могёт.

автор - К.О.

А Postgres'е таки сделали автоматическое партиционирование (наподобие оракловоко create table ... partition by ... ).

Когда последний раз с ним сталкивался, не нашел такого функционала и был очень расстроен. А в целом - хорошая СУБД.

>Кроме похожего названия Ingress никоим боком не связан с Pg

К разработке Postgres, начавшейся в 1986-ом году, имел непосредственное отношение Майкл Стоунбрейкер, руководитель более раннего проекта Ingres, на тот момент уже приобретённого компанией Computer Associates. Само название «Postgres» расшифровывалось как «Post Ingres», соответственно, при создании Postgres были применены многие уже ранее сделанные наработки. http://ru.wikipedia.org/wiki/PostgreSQL#.D0.98.D1.81.D1.82.D0.BE.D1.80.D0.B8....

Вот эта фраза очень понравилась:

MySQL – это open-source продукт. Postgres – это open-source проект.

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

>спасибо, хорошая, годная статья.
Да никуда не годный вброс.

---
Автоинкремент

MySQL: в таблице может быть только один такой столбец, который должен быть проиндексирован. PostgreSQL: SERIAL data type.

Вот для кого сие напейсано? Для будущего админа, али для будущего программизда?

И еще в догонку... Хоть бы придерживались реализма, а то ушанов много, разрыв мозга им обеспечен:

Цитата:

Следующая запись разрешает пользователю serg с определенного ip-шника работать с базой test:

host test serg 123.321.123.321 trust

Я вижу IBM_dW и иду в комменты чтобы убедиться, что статья - чушь, не читая самой статьи. И я снова оправдал свои ожидания.

Что то всё больше стало появляться материалов из разряда IMHO, подаваемых с игнорированием HUMBLE.

Сплошные менеджеры по перемещению текстовых блоков.

язабан ibm_dw

Сторонники бана ibm_dw видимо готовы компенсировать финансово его отсутсвие для сервера лора?

> Это не бот. Это Оля

«Полное имя: IBM developerWorks»

:-)

Очень многое переврано, особенно про MySQL. Одни рудиментарные триггеры чего стоят.. Тип SERIAL может быть использован и в PG, и в MySQL, правда в MySQL он транслируется в integer 8bytes auto increment..

Также нет большого смысла рассматривать любые engines в MySQL, кроме InnoDB. Только InnoDB имеет хоть какое-то отношение к реальной базе данных. Ни слова не сказано про то, как тормозит MySQL на больших базах.

Мне также показалось прикольным фраза про то, что PG придерживается стандарта PL/SQL. Это каким же боком?

Сравнивать MySQL и PG бесполезно. Про хрен и палец было верно сказано. Если вам нужна СУБД - это PG или Oracle. А если просто небольшое хранилище не слишком ценной информации - тут можно и MySQL применить. Но, с другой стороны, применять MySQL в любом проекте - это просто потеря времени. Чему бы вы при этом не научились - малоприменимо к реальным базам.

>Да что тут сравнивать-то, все и так знают, что мускуль говно, а постгрес - круто.

Вы в детском садике в субд-шки играетесь? Тогда понятно.

IBM_dW, в этот раз Вы похоже побили рекорд. В третьей части про параметры настройки PostgreSQL переврано практически всё, практически все параметры описаны неверно.

Не, в детском саду я голых баб на асфальте мелом рисовал.

>Но, с другой стороны, применять MySQL в любом проекте - это просто потеря времени.

Твои б слова да разработчикам KDE4 в уши.

Тема ада репликации (BLACKHOLE) mysql не раскрыта.

>Твои б слова да разработчикам KDE4 в уши.

Как раз для кде то оно сгодится - там mysql используется по назначению - хранилище данных с языком SQL, т.е. записная книжка. Ничего более серьёзного не требуют.

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

А Postgres'е таки сделали автоматическое партиционирование (наподобие оракловоко create table ... partition by ... ).

есть inherit таблиц и партишены (причём интереснее чем оракале), выходи из анабиоза и читай доки ;)

Учитывая, что они внезапно захотели повесить на него все и вся, то уж лучше бы заранее так, чем потом «ой, опять переделывать».

Это ещё что :)

Тут как то в одном из списков рассылки проходила информация, что на какой то кадэешной конференции разработчикам понравилась презентация GNU Smalltalk, и они задумались о его использовании с веб-сервером Swazoo где-то плазмоидах.

mongoDB (couchDB... добавить по вкусу) против всех ;)

Сервер с плазмоидами? Ну а что, не впервой изобретать монстра: kde-plasma-desktop -> kdebase-workspace -> plasma-widgets-workspace -> plasma-dataengines-workspace -> kdepim-runtime -> akonadi-server -> mysql-server-core. MySQL что б часики показывали дни рождения (может какие ещё события) из адресной книги (или откуда там?), которая может быть и не установлена. БД что б показывать дни рождения… :) Почему бы не ставить такую зависимость куда-то в приложения история умалчивает.

Интересно, это там гвоздями поработали или Дебиан такой добрый стал?

>применять MySQL в любом проекте - это просто потеря времени. Чему бы вы при этом не научились - малоприменимо к реальным базам
Как-то странно мне слышать такое.
Я - не теоретик, MySQL использую в своих задачах уже 10 лет. Сначала начинал с «записной книжки» - 3.22, потихоньку учился, объем базы рос, а MySQL развивался. Уже с версии 3.23.34a (март 2001-го) появились транзакции - я перевел базу на InnoDB и вздохнул с облегчением - под нагрузкой (несколько десятков запросов в секунду) наблюдались проблемы с MyISAM, в InnoDB они прекратились...
Сейчас использую в продакшн MySQL 5.0 - ничего плохого сказать не могу - нагрузку держит сервер отлично, сбоев не наблюдается. До использования триггеров пока не дорос(с удивлением прочитал в статье, что их поддержка - рудиментарна), функционал 5-ки полнсотью устраивает - активно используются stored procedures, внешние ключи, все данные - в UTF-8, движок - InnoDB. Нагрузка сейчас такая:
$ mysqladmin -p status
Uptime: 1864208 Threads: 1 Questions: 199093302 Slow queries: 4 Opens: 286 Flush tables: 1 Open tables: 64 Queries per second avg: 106.798
Главные транзакционные таблицы содержат по нескольку миллионов записей (раз в год «зачищаю» базу от устаревших данных), при этом INSERT'ы, UPDATE и SELECT обрабатываются достаточно (для меня, по крайней мере) быстро - IMHO в вопросе скорости работы базы больше зависит от железа, админа базы и проектировщика таблиц, нежели от названия СУБД.
Вообще, IBM'овская статья новости - ни о чем. Вроде как помогает сделать правильный выбор иструментария для решения стоящей задачи. А где ж он правильный? Новичок, засевший за изучение MySQL, по прочтении «творчества» Сергея Яковлева, схватится за голову и решит, что взялся не за ту СУБД и начнет с нуля изучать постгрес. А должен (на мой взгляд) вместо того, чтобы жаловаться на недостатки СУБД, постепенно изучать его возможности - это позволит решить практически все задачи. В качестве иллюстрации - помню, не хватало мне поддержки вложенных запросов в 3.23 - ничего, засел на пару часов за manual к MySQL и «выкрутился» с помощью LEFT JOIN'ов...
P.S. выбирал 10 лет назад между mysql и postgres'ом и остановился на 1-м только лишь из-за того, что mysql входил в стандартую поставку Red Hat Linux 5.0. С тех пор ни разу не пожалел.

такое ощущение что автор очень спешил с релизом статьи. галопом по европах

Прочитал статью, если не считать явных фактических ляпов, то в ней подтверждается то, что все знали уже давно - MySQL суть рудиментарная база данных непонятного назначения, а PostgreSQL суть полноценная база даных.

Включаем насос по перекачке поноса...

>А должен (на мой взгляд) вместо того, чтобы жаловаться на недостатки СУБД, постепенно изучать его возможности

ага-ага, я тоже так думал, пока не попробовал PostgreSQL. попробуй

- помню, не хватало мне поддержки вложенных запросов в 3.23

хроники кактусоеда прям, без обид

Хы, каждый второй считает себя спецом по базам данных, всё как обычно :)

Лучше сравнили халявные реализации ракеля, дб2 и мсскуль ( хз про последних ) ну тама по количеству процев и тд и скорости работы ...

MySQL плоха для ниосиляторов - её единственный минус

Полностью с вами согласен, MySQL - отличная СУБД и прекрасно масштабируется. И тригеры там вполне удовлетворительны и встроенный шедулер порадовал

>Мне также показалось прикольным фраза про то, что PG придерживается стандарта PL/SQL. Это каким же боком?

ну сходства синтаксиса хранимок налицо, притом есть же комерческий вариант постгре где на чистом PL и пишется?разве нет?

Похоже на вброс.

Сравнение языков,<СУБД>, ...., ..... и т.д. редко бывает осмысленным, еще реже честным.( Слова не мои )

Ну скажите же уже кто-нибудь, postgres уже научился нормально жить без периодического vacuum? Или этот маразм до сих пор там есть?
Когда-то именно этот долбаный ваккум и стал причиной отказа от postgres в пользу mysql.

Давно мучает вопрос: почему в такие сравнительные обзоры открытых СУБД Firebird не попадает? Интересно было бы почитать: MySQL vs. PostgreSQL vs. Firebird.

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

Юзаю Oracle и ниипет.