Выбор правильной базы данных: MySQL против всего остального

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

Спасибо, Бен

EDIT: Должно быть упомянуто, я ищу оптимальную производительность, интеграцию с рубинами + рельсы, работающие на debian 5, и деньги жесткие, хотя, если это сэкономит деньги в долгосрочной перспективе, я бы подумал о том, чтобы инвестировать в нечто более дорогое.

Ответ 1

Я опубликовал это раньше, но у меня нет причин менять этот совет:

MySQL легче начать использовать.

Дополнительные инструменты пользовательского интерфейса. Быстрее, если вы не используете ACID. Более терпимо к недействительным данным. Столбцы автоинкремента также просты, как ввод автоинкремента. Разрешения не привязаны к файловым системам и пользователям ОС. Установка разделителя проще, чем использование PG "знак доллара" при записи хранимой процедуры. В MySQL вы подключаетесь ко всем базам данных, а не по одному за раз.

Postgres (PG) гораздо более совместим со стандартами, но он уродливее и сложнее, особенно с точки зрения пользовательского интерфейса. Он требовал ручного вакуумирования и фактически обеспечивал ссылочную целостность (что является большой вещью, которая может быть болью в заднице). Автоинкремент гораздо более гибкий, но для него требуются последовательности (которые можно замаскировать с помощью последовательного интерфейса) и ждать, что такое OID?

Итак, если вы действительно не знаете или не заботитесь о базах данных, действительности данных, соблюдении ACID и т.д., но вы заботитесь о легкости и скорости, вы, как правило, работаете с MySQL.

Слишком много (не все, но многие) "веб-программисты" много знают о "веб-2.0" или PHP или Java, но мало знают о теории или практике базы данных ( "индекс? что это?" ), Они, как правило, видят базу данных как просто причудливую хэш-таблицу или мешок данных, и даже тот, который нигде не является динамически изменчивым или прощающим как хэш-таблица.

Для этих людей MySQL - потому что до 5.0 он не был действительно РСУБД, а во многих отношениях все еще не является - это находка. Это "быстрее", чем конкуренция, и не "тратит время" на "эзотерическую" базу данных, которую веб-программист не хочет, не понимает и не видит значение.

Для кого-то с фоном базы данных, с другой стороны, MySQL - это минное поле: работа, которая должна работать (сложные представления, групповые байты, порядковые байты в групповых байтах), может работать или может, если вам повезет сбой сервера, или если вам не повезло, просто дайте результаты с неправильными данными.

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

И MySQL на самом деле не быстрее. Если вы используете таблицы InnoDb для ACID (или просто потому, что в более чем 30 миллионах строк таблицы MyISAM имеют тенденцию становиться дрянным), да, прямой выбор из одной таблицы, вероятно, быстрее, чем в PG. Но добавьте соединения, и PG внезапно значительно быстрее. (MySQL особенно плох при внешних соединениях.)

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

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

"Веб-программист", который решил, что все его структуры таблиц могут быть автоматически сгенерированы Hibernate (или какой-то другой ORM), смотрит на это и говорит "слишком сложно" и "я ставлю сложный, означает большую стоимость и более медленную скорость", и поэтому он идет с MySQL.

Как я уже сказал, PG намного превосходит, и я ненавижу запугивание ошибок MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.

Но MySQL делает вещи выглядящими (обманчиво) простыми, поэтому вы получаете много людей, которые действительно не понимают дизайн базы данных, полагая, что MySQL - отличный выбор.

Используйте PG. Он последовательный, надежный, он соответствует стандартам, он быстрее (даже умеренно) сложных запросов, он не полностью отбрасывает ваше расписание с необычными ошибками.

Ответ 2

Я думаю, PostgreSQL - очень жизнеспособная альтернатива MySQL. Это гораздо больше похоже на Oracle.

Ответ 3

Лично я стараюсь избегать MySQL каждый раз, когда могу, по следующим причинам:

Механизм хранения по умолчанию MyISAM не имеет поддержки Foreign Key. Innodb, однако по очевидным причинам он не поддерживает внешние ключи для таблиц MyISAM.
Если я попытаюсь вставить недопустимые данные, MySQL с радостью изменит его для меня.
- Недопустимые значения DateTime, Date или Timestamp преобразуются в "ноль": http://dev.mysql.com/doc/refman/5.1/en/datetime.html
- столбцы типа Varchar и Char: http://dev.mysql.com/doc/refman/5.1/en/char.html
- Числовые типы данных в зависимости от строкового режима SQL: http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html

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

Ответ 4

Ну, могут быть различия между РСУБД мира. Взгляните на http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems#Fundamental_features

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

Несколько вещей, которые нужно иметь в виду:

SQL Server 2005 Express ограничен размером файла 4 ГБ, но имеет отличную поддержку на языках .NET и Java.

MySQL будет работать как на Windows, так и на Linux, а многие языки поддерживают его (включая .NET и Java) с внешними библиотеками.

SQLite поддерживается эффективно каждой операционной системой и может быть распространен как интегрированная часть вашего приложения.

Ответ 5

Firebird открытая версия Borland Interbase с открытой и разветвленной версией довольно хороша, она работает с радостью на большинстве (всех?) вкусов Linux и очень впечатляет. Я не парень RoR, поэтому я не знаю подробностей, но у меня есть друг в Новой Зеландии, который использует Firebird со всеми его проектами RoR, он определенно работает с RoR и хорошо работает.

Изменить:
Найдена ссылка на адаптер Rails Firebird здесь

Ответ 6

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

Популярность MySQL частично самогенерируется: многие хостинг-провайдеры предоставляют ее, поэтому многие люди ее используют.

Ответ 7

Mysql отлично, и mssql отлично. Я больше ничего не использовал. Я бы сказал, если вы полностью на заборе, пойдите с технологическим стеком, в котором вы сильнейший. У меня есть хорошее количество С#, asp.net и другого опыта работы с Microsoft, поэтому для меня довольно естественно специализироваться на mssql. Если вы более знакомы с * nix, php и т.д., Вы можете быть дома, придерживаясь стека с открытым исходным кодом. Вы можете смешать и сопоставить два стека, но придерживаться одного мира или другого может избежать некоторой боли для вас.

Ответ 8

Как и duffymo, я также рекомендую PostgreSQL. Это очень приятно с точки зрения разработчика: работа на многих платформах (как на основе unix, так и на Windows), имеет стабильные интерфейсы для любого laguage/environment, который я работал (Windows, Linux, Delphi, Java, Perl, Python). Язык хранимых процедур: PLPGSQL также прост и эффективен. Поддержка пользователей (группы новостей, списки, SO) является приятной и полезной.

Ответ 9

"Казалось бы, в эти дни все просто идут с MySQL, потому что это то, с чем все идут". Если MySQL - это единственное, что люди используют, то почему Oracle и MSSQL все еще существуют?

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

Если вы можете оправдать расходы XXX в базе данных, вы, вероятно, знаете причины, по которым он уже выбрал.