Выбор правильной базы данных: MySQL против всего остального
Мне было легче:
1) создать функцию, которая будет проверять, находится ли элемент где-либо в родительской иерархии другого. Что-то вроде этого (я не буду писать функцию, сделаю ее с WHILE DO):
is_related(id, parent_id);
в вашем примере
is_related(21, 19) == 1;
is_related(20, 19) == 1;
is_related(21, 18) == 0;
2) используйте подвыбор, что-то например:
select ...
from table t
join table pt on pt.id in (select i.id from table i where is_related(t.id,i.id));
9 ответов
Я публиковал это раньше, но у меня нет причин менять этот совет:
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.
A " кто решил, что все его структуры таблиц могут быть автоматически сгенерированы Hibernate (или каким-либо другим ORM), смотрит на это и говорит: «слишком сложно» и «держу пари, что сложный означает больше затрат и медленнее скорость», и поэтому он идет с MySQL.
Как я уже сказал, PG намного превосходит другие, и я ненавижу возиться с причудливыми ошибками MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.
Но MySQL заставляет вещи выглядеть (обманчиво) просто, так что многие люди, которые действительно не разбираются в конструкции баз данных, полагают, что MySQL - отличный выбор.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
кто решил, что все его структуры таблиц могут быть автоматически сгенерированы Hibernate (или каким-либо другим ORM), смотрит на это и говорит: «слишком сложно» и «держу пари, что сложный означает больше затрат и медленнее скорость», и поэтому он идет с MySQL.Как я уже сказал, PG намного превосходит другие, и я ненавижу возиться с причудливыми ошибками MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.
Но MySQL заставляет вещи выглядеть (обманчиво) просто, так что многие люди, которые действительно не разбираются в конструкции баз данных, полагают, что MySQL - отличный выбор.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
и я ненавижу возиться с причудливыми ошибками MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.Но MySQL заставляет вещи выглядеть (обманчиво) простыми, поэтому вы получаете много людей, которые не Я действительно не разбираюсь в дизайне баз данных, полагая, что MySQL - отличный выбор.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
и я ненавижу возиться с причудливыми ошибками MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.Но MySQL заставляет вещи выглядеть (обманчиво) простыми, поэтому вы получаете много людей, которые не Я действительно не разбираюсь в дизайне баз данных, полагая, что MySQL - отличный выбор.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
Используйте PG. Он согласован, надежен, соответствует стандартам, быстрее (даже умеренно) по сложным запросам, он не нарушает ваш график странными ошибками.
Лично я стараюсь избегать MySQL всякий раз, когда могу, по следующим причинам:
- Механизму хранения по умолчанию MyISAM не хватает поддержки внешнего ключа . Innodb поддерживает, однако по понятным причинам не поддерживает внешние ключи к таблицам MyISAM.
- Если я попытаюсь вставить недопустимые данные, MySQL с радостью изменит их для меня.
- Illegal DateTime, Date, or Timestamp values are convert to "zero": http://dev.mysql.com/doc/refman/5.1/en/datetime.html
- Varchar and Char type columns: http://dev.mysql.com/doc/refman/5.1/en/char.html
- Numeric Datatypes depending on SQL Strict Mode: http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html
These things may not be of any importance to some people, but when it comes to quality of data, I would rather use something else.
Firebird открытая и разветвленная версия Borland Interbase довольно хороша, хорошо работает на большинстве (всех?) Разновидностей Linux и очень производительна. Я не RoR парень, поэтому я не знаю деталей, но у меня есть друг в Новой Зеландии, который использует Firebird со всеми своими проектами RoR, он определенно работает с RoR и работает хорошо.
Редактировать:
Нашел ссылку на Firebird Rails Adapter здесь
Как и duffymo, я также рекомендую PostgreSQL. Это очень приятно с точки зрения разработчика: работает на многих платформах (как на основе Unix, так и на Windows), имеет различные стабильные интерфейсы для любых языков / сред, в которых я работал (Windows, Linux, Delphi, Java, Perl, Python). Язык хранимых процедур: PLPGSQL также прост и эффективен. Поддержка пользователей (группы новостей, списки, SO) приятна и полезна.
Я думаю PostgreSQL - очень жизнеспособная альтернатива MySQL. Это больше похоже на Oracle.
Что ж, между РСУБД в мире могут быть различия. Взгляните на 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 поддерживается практически каждой операционной системой и может распространяться как интегрированная часть вашего приложения.
Пожалуйста, будьте осторожны с идеалистическими точками зрения, высказываемыми людьми, которым, возможно, нужно заточить топоры. MySQL - способное, надежное и масштабируемое решение для многих проблем, но обычно это не так уж и сразу, поскольку его значения по умолчанию крайне консервативны. Как и любой другой продукт для баз данных, вам нужно будет потратить время на настройку его установки для достижения желаемой производительности. Вам также нужно будет потратить некоторое время на то, чтобы приспособиться к его ограничениям, что также верно для любой базы данных, которую вы выберете.
Популярность MySQL частично обусловлена самими собой: многие хостинг-провайдеры предоставляют ее, поэтому многие люди ее используют.
1116871]
Mysql великолепен, а mssql великолепен. Больше я ничего не использовал. Я бы сказал, что если вы полностью на заборе, используйте стек технологий, в котором вы сильны. У меня хороший опыт работы с C #, asp.net и другими стеками Microsoft, поэтому для меня вполне естественно специализироваться на mssql. Если вы более знакомы с * nix, php и т. Д., Возможно, вам будет удобнее придерживаться стека с открытым исходным кодом. Вы, конечно, можете смешивать и сочетать два стека, но придерживаясь одного или другого мира, вы можете избежать некоторой боли.
«В наши дни может показаться, что все просто используют MySQL, потому что это именно то, что все используют». Если MySQL - единственное, что люди используют, то почему Oracle и MSSQL все еще существуют?
Споры о том, какой движок базы данных выбрать, могут вестись до тех пор, пока коровы не вернутся домой. Лично я всегда находил одну постоянную при выборе движка базы данных. Тот, который вы можете себе позволить, обычно тот, который вы выбираете.
Если вы можете оправдать трату XXX на базу данных, то вы, вероятно, уже знаете причины, по которым выбрали эту базу данных.