Как я могу описать коллекцию в Монго?

Question

Итак, это третий день изучения Mongo Db.Я из вселенной MySql ...

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

Как бы я это сделал для БД Монго?Я знаю, я знаю ... Я ищу схему в базе данных без схемы.=) Но как еще пользователи будут знать, какие поля использовать в своих запросах?

Я поступаю неправильно?Очевидно, я пытаюсь использовать MySql способ делать вещи в моноблоке.Что такое монго?

Answer 1

Введите следующий запрос в редактор / mongoshell

var col_list= db.emp.findOne();
for (var col in col_list) { print (col) ; }

вывод даст вам имя столбца в коллекции:

_id
name
salary

Answer 2

Здесь нет хорошего ответа.Поскольку схемы нет, вы не можете «описать» коллекцию.Однако во многих (большинстве?) Приложениях MongoDb схема определяется структурой иерархии объектов, используемой в приложении для записи (java или c # или чем-либо еще), поэтому вы можете иметь возможность отразить объектную библиотеку, чтобы получить эту информацию,В противном случае есть немного проб и ошибок.

Answer 3

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

Конечно, при работе с базами данных без схемы, такими как MongoDB, используется схема, но схема определяется приложением, а не базой данных. База данных будет пихать во все, что ей дают. До тех пор, пока вы знаете, что администраторы не осуществляют тайный вход в Mongo и не вносят изменения, а весь доступ к базе данных осуществляется через некоторую оболочку , единственное место, на которое вы должны обратить внимание на схему, - это классы вашей модели. Например, в нашем приложении Rails это две модели, которые есть в Mongo,

class Consumer
    include MongoMapper::Document

    key :name, String
    key :phone_number, String
    one :address
end

class Address
    include MongoMapper::EmbeddedDocument

    key :street, String
    key :city, String
    key :state, String
    key :zip, String
    key :state, String
    key :country, String
end

Теперь после перехода на MySQL наши классы выглядят так:

class Consumer < ActiveRecord::Base
    has_one :address
end

class Address < ActiveRecord::Base
    belongs_to :consumer
end

Не обманывайтесь краткостью занятий. В последней версии с MySQL поля извлекаются из базы данных напрямую. В первом примере поля находятся прямо перед нашими глазами.

В MongoDB, если нам нужно было изменить конкретную модель, мы просто добавляем, удаляем или модифицируем поля в самом классе, и это работает сразу же. Нам не нужно беспокоиться о синхронизации таблиц / столбцов базы данных со структурой класса. Поэтому, если вы ищете схему в MongoDB, ищите ответы в своем приложении, а не в базе данных.

По сути, я говорю то же самое, что и @Chris Shain:)

Answer 4

Мне тоже это нужно, Кавачон. Поэтому я создал инструмент с открытым исходным кодом под названием Variety, который делает именно это: ссылка

Надеюсь, вы найдете это полезным. Дайте мне знать, если у вас есть вопросы или какие-либо проблемы с их использованием.

Удачи!

Answer 5

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

db.collectionName.findOne()

Это покажет один документ (он же запись) в базе данных в хорошем формате.

Answer 6

print('\n--->', Object.getOwnPropertyNames(db.users.findOne())
  .toString()
  .replace(/,/g, '\n---> ') + '\n');

---

---> _id
---> firstName
---> lastName
---> email
---> password
---> terms
---> confirmed
---> userAgent
---> createdAt

Answer 7

AFAIK, пути нет, и логично, что так оно и есть.

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

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

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

Например (на оболочке монго):

Если это образец документа в вашей коллекции people и все документы следуют одной и той же схеме:

{
  name : "My Name"
  place : "My Place"
  city : "My City"
}

Следующие запросы являются абсолютно действительными:

Эти два вернут вышеуказанный документ:

db.people.find({name : "My Name"})
db.people.find({name : "My Name"}, {name : 1, place :1})

Это ничего не вернет, но и не вызовет ошибку:

db.people.find({first_name : "My Name"})

Это будет соответствовать вышеуказанному документу, но у вас будет только свойство "_id" по умолчанию в возвращаемом документе.

db.people.find({name : "My Name"}, {first_name : 1, location :1})

Answer 8

Я написал небольшой скрипт оболочки монго, который может вам помочь.https://gist.github.com/hkasera/9386709

Дайте мне знать, если это поможет.

Answer 9

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

Начните с этой записи .

Единственная проблема здесь в том, что вы используете Map / Reduce, что может быть ресурсоемким. Вместо этого, как и предлагали другие, вы захотите взглянуть на код, который записывает фактические данные.

Тот факт, что база данных не имеет схемы, не означает, что не является схемой. Вообще говоря, информация о схеме будет в коде.

Answer 10

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

const doc = db.collectionName.findOne();
for (x in doc) {
  print(`${x}: ${typeof doc[x]}`)
};