Лучшие практики NoSQL

Каковы наилучшие методы работы с базами данных NoSQL, OODB или любыми другими аббревиатурами для них?

Например, я часто видел, что поле "тип" используется для определения того, каким образом документ БД (в терминах couchDB/mongoDB) должен интерпретироваться клиентом, приложением.

Где применимо, используйте PHP в качестве эталонного языка. Читайте: меня также интересует, как такие данные лучше всего обрабатывать на стороне клиента, а не только строго структуру БД. Это означает, что я также ищу шаблоны, подобные "ORM" для SQL DB (активная запись, dataperper и т.д.).

Не стесняйтесь делать заявления о том, как такая БД и новые возможности PHP 5.3 могли бы наилучшим образом работать вместе.

Ответ 1

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

В этот момент мы знаем, что правила хранения ваших данных внутри say CouchDB (или любой другой базы данных документов) довольно отличаются от правил для реляционного. Например, это почти факт, что нормализация и нацеленность на 3NF - это не то, к чему нужно стремиться. Один из распространенных примеров - простой блог.

В реляционном магазине у вас будет таблица для "Сообщений", "Комментарии" и "Авторы". У каждого автора будет много сообщений, и каждый пост будет иметь много комментариев. Это модель, которая работает достаточно хорошо и хорошо отображает любую реляционную БД. Однако сохранение одних и тех же данных в docDB, скорее всего, будет весьма иным. Вероятно, у вас есть что-то вроде коллекции Post-документов, каждая из которых будет иметь свой собственный Author и сборник комментариев, встроенных в нее. Конечно, это, вероятно, не единственный способ сделать это, и это скорее компромисс (теперь запрос на одно сообщение выполняется быстро - вы выполняете только одну операцию и все возвращаете), но у вас нет способа поддерживать отношения между авторами и сообщениями (поскольку все это становится частью почтового документа).

Я тоже видел примеры с использованием атрибута "type" (в примере CouchDB). Конечно, это звучит как жизнеспособный подход. Это лучший? У меня нет подсказки. Разумеется, в MongoDB вы должны использовать отдельные коллекции в базе данных, что делает атрибут типа полным бессмысленным. В CouchDB, хотя... возможно, это лучше всего. Другие альтернативы? Отдельные базы данных для каждого типа документа? Это кажется немного зацикленным, поэтому я склоняюсь к "типу" самостоятельно. Но это только я. Возможно, там что-то лучше.

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

Ответ 2

"NoSQL" должен быть больше связан с построением хранилища данных, чтобы он соответствовал вашим требованиям к приложениям, а не по поводу того, как приложение должно следовать определенной структуре - это больше похоже на традиционный подход SQL.

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