Какую базу данных nosql идеально использовать для хранения кода / фрагментов?

Question

Я хочу сохранить код, аналогичный тому, как jsfiddle хранит код.В настоящее время я использую Postgres для своей основной базы данных, но мне интересно, будет ли более идеальным использование базы данных NoSQL?

У фрагментов кода на данный момент будет только один автор, но в будущем их может быть несколькои авторам, и мне нужна возможность возврата.

Я знаю, что существуют базы данных ключей / значений и базы данных, ориентированные на документы.Какой конкретный DB NoSQL будет соответствовать моим потребностям?Или я все еще должен придерживаться своей базы данных Postgres?

К вашему сведению:

1. Я использую django
2. Пользователи будут постоянно храниться в postgres (яиспользуя openID)

Answer 1

Нельзя выбрать стратегию нереляционных данных без определения того, что вы хотите делать с вашими данными.

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

Но, не зная ничего о вашем приложении, моей первой рекомендацией будет придерживаться PostgreSQL.Сохраняйте фрагменты кода в текстовых BLOB-объектах, а метаданные о коде (авторство, дата, язык, проект и т. Д.) В дополнительных столбцах рядом с текстовым BLOB-объектом.Также вы можете рассмотреть возможность использования индексов GIST для обеспечения гибкого поиска.

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

Answer 2

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

Однако, если вы храните информацию о пользовательской базе в PostgreSQL, это будет простопридерживаться этого как единого метода хранения.Используя базы данных SQL и , NoSQL добавляет сложность, затрудняет объединение наборов данных (например, вы не можете сделать запрос, чтобы сделать что-то вроде «перечислить пользователей вместе с их самым последним документом»),и делает невозможным обеспечение согласованности между двумя наборами данных.

Что вы получаете за эту проблему?Вы хотите версии.CouchDB предоставит вам контроль версий, но сомнительно, следует ли использовать его для управления версиями на уровне пользовательского интерфейса (например, из-за сжатия базы данных ваши старые версии будут потеряны).

Answer 3

Что касается баз данных NoSQL, я знаком только с XML (он плохо масштабируется и имеет плохой параллелизм) и локальными базами данных, такими как Paradox, dBase, FoxProx и Access. Я бы не рекомендовал ничего из этого.

Я думаю, что идея о том, что это база данных NoSQL, должна быть меньшим фактором в вашем решении. Рассмотрим эти вещи вместо этого.

• Избыточность. Можете ли вы запустить его на двух серверах одновременно или он поддерживает аварийное переключение? (SQL Server, Interbase, Firebird)

• параллелизм. Вы разместите это приложение в Интернете? Как он будет обрабатывать 10 одновременных операций? (PostGres, MySql, Interbase, Firebird)

• Скорость. Как долго это приемлемо для поиска или сообщения?

• Вложимость. Это настольное приложение? Встроенная база данных может сделать вещи проще. (Локальные базы данных, такие как Paradox, dBase, FoxPro, Access, Interbase, Firebird или SQLite)

• Портативность. Настольные приложения могут работать на Mac, Linux, Windows. (SQLite)