Использовать дополнительные ключи или универсальный ключ в MongoMapper?

Question

Предположим, я работаю над классом MongoMapper, который выглядит следующим образом:

class Animal
    include MongoMapper::Document

    key :type, String, :required => true
    key :color, String
    key :feet, Integer
end

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

    key :wingspan, Float

Или это, несмотря на то, что это неописуемое всеохватывающее чувство, похожее на взлом:

    key :metadata, Hash

Похоже, что подход метаданных (для которого есть прецедент в коде, который я наследую) почти избыточен для документа Mongo в целом: они оба предназначены для использования в качестве схем без пар ключей-значений. 1010 *

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

Есть ли альтернативы (создать подкласс Bird)?

Answer 1

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

Answer 2

MongoMapper не хранит ключи nil, поэтому, если вы определили key :wingspan, то только документы, которые фактически задают этот ключ, сохранят его.

Если вы решите не определять ключ,Вы все еще можете установить / получить его с помощью my_bird[:wingspan] = 23.(Вызов [] фактически автоматически определит для вас ключ; аналогично, если документ возвращается из MongoDB с ключом, который явно не определен, для него и для всех документов этого класса будет определен ключ - это своего рода ошибкаопределить его для всего класса, но поскольку ключи nil не хранятся, это не такая большая проблема.)

Если у птицы тоже есть свое поведение (вероятно, оно есть), то подкласс делаетсмысл.Для птиц и животных я бы выбрал этот путь, так как каждая птица - животное.MongoDB намного лучше, чем ActiveRecord для Одиночная таблица / Одиночная коллекция Наследование, потому что вам не нужен миллиард миграций и , ваш код проясняет, какие атрибуты идутс какими классами.