PostgreSQL MySQL Различия оракула

Question

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

Кто-нибудь может объяснить, в чем плюсы и минусы каждого из этих трех двигателей? Нам придется выбрать один из них, и единственное, что я на самом деле знаю о них, это:

• Mysql & Postgres:
  • Свободны, но не так хороши, как оракул
  • Mysql как проблемы безопасности (это правда?)
• Oracle:
  • Лучший в мире движок базы данных
  • Дорогие

Может кто-нибудь прояснить другие различия между ними? Это средний / большой (около 100-200 таблиц) проект с небольшим бюджетом, что бы вы выбрали? И с более высоким бюджетом?

Answer 1

Несколько лет назад мне пришлось написать движок перевода; вы кормите его одним набором sql, и он переводится на диалект текущего подключенного движка. Мой движок работает на Postgres (AKA PostgreSql), Ingres, DB2, Informix, Sybase и Oracle - о, и ANTS. Честно говоря, Oracle - мой наименее любимый (подробнее об этом ниже) ... К сожалению для вас, mySql и SQL Server нет в списке (в то время ни одна из них не считалась серьезной СУБД, но времена меняются).

Безотносительно к качеству или производительности двигателя - а также к простоте создания и восстановления резервных копий - вот основные отличия:

• * 1006 типов данных *
• Пределы
• 1010 * инвалиды *
• зарезервированные слова
• нулевая семантика (см. Ниже)
• семантика кавычек (одинарная кавычка, двойная кавычка "или любая из них)
• Семантика завершения оператора
• семантика функции
• обработка даты (включая постоянные ключевые слова, такие как «сейчас» и форматы функций ввода / вывода)
• разрешены ли встроенные комментарии
• максимальная длина атрибута
• максимальное количество атрибутов
• семантика соединения / парадигма безопасности.

Не скучая по всем данным конвертации, вот пример для одного типа данных, lvarchar:

oracle = varchar (% x) sybase = text db2 = "long varchar" informix = lvarchar postgres = varchar (% x) ants = varchar (% x) ingres = varchar (% x,% y)

Самая большая сделка, на мой взгляд, это нулевая обработка; Oracle SILENTLY преобразует пустые строки ввода в нулевые значения. ... Где-то, давным-давно, я читал рецензию, написанную кем-то о "Семнадцати значениях нуля", или что-то подобное, и реальная точка зрения в том, что нули очень ценны, и различие между пустой строкой и пустой строкой полезно и нетривиально! Я думаю, что Oracle допустил огромную ошибку в этом; ни у кого другого нет такого поведения (которое я когда-либо видел).

Моим вторым наименее любимым был ANTS, потому что, в отличие от всех остальных, они ПОДТВЕРЖДАЛИ глупые правила идеального синтаксиса, которых абсолютно никто не делает, и, хотя они могут быть единственной компанией БД, которая обеспечивает идеальное соблюдение стандарта, они также являются королевская боль в заднице, чтобы написать код.

Безусловно, мой любимый - Postgres; это очень быстро в ситуациях _real_world_, имеет отличную поддержку и с открытым исходным кодом / бесплатно.

Answer 2

Различия между различными реализациями SQL велики, по крайней мере, под капотом. Этих досок не хватит, чтобы сосчитать их все.

Если вам нужно спросить, вы также должны спросить себя, имеете ли вы право принимать обоснованное и обоснованное решение по этому вопросу.

Сравнение MYSQL и Postgres можно найти здесь

Обратите внимание, что Oracle также предлагает Express (XE) издание , ограниченное в функциях, но бесплатное для использования. Кроме того, если у вас мало знаний для начала, вам придется учиться самостоятельно, я бы просто выбрал любой и начал учиться, используя его.

Answer 3

См. Сравнительные таблицы в Википедии: http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems && http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

Oracle может быть или не быть лучшим. Это дорого, но это не значит лучше.

Вы смотрели на DB2? Sybase? Teradata? MS SQL?

Answer 4

Я думаю, что для малобюджетных сценариев Oracle не может быть и речи. 100-200 таблиц невелики и, как правило, количество таблиц в схеме не является мерой масштаба. Набор данных и пропускная способность.

Вы можете взглянуть на http://www.mysqlperformanceblog.com/ (и их превосходную книгу), чтобы увидеть, как MySQL может обрабатывать огромные развертывания.

Как правило, в настоящее время большинство СУБД могут выполнять практически все, что вам нужно в очень серьезных приложениях.