Хранение произвольной контактной информации в Ruby on Rails - PullRequest
1 голос
/ 06 июня 2010

В настоящее время я работаю над приложением Ruby on Rails, которое будет работать в некотором роде как сайт социальной сети для конкретного сайта. Как часть этого, у каждого пользователя на сайте будет свой профиль, где он может заполнить свою контактную информацию (номера телефонов, адреса, адреса электронной почты, работодателя и т. Д.).

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

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

В идеале я хотел бы использовать vCard в качестве формата сериализации. vCards - это стандартное решение для хранения контактной информации в Интернете, и повторное использование проверенных решений - это хорошо. Альтернативные форматы сериализации могут включать в себя просто маршалинг хэша ruby ​​или YAML. Независимо от формата сериализации, поддержка чтения и обновления этой информации в виде рельсов, похоже, является серьезной проблемой при реализации.

Итак, вот вопрос: кто-нибудь видел, чтобы этот подход использовался в приложении rails? Существуют ли какие-либо плагины или гемы для рельсов, которые делают такую ​​систему простой в реализации? В идеале, я хотел бы добавить карту activ_as_vcard к объекту моей модели, которая бы отредактировала для меня vcard и сохранила его обратно в базу данных.

Ответы [ 2 ]

1 голос
/ 06 июня 2010

vCard хорош для API, но для реальной базы данных я бы использовал дизайн 1-много. Каждый человек может иметь много телефонных номеров, адресов, адресов электронной почты, прошлых работодателей. Для текущего работодателя вы могли бы сделать 1-1 отношения. Я думаю, что ваше отвращение к объединениям неуместно. При правильных показателях производительность должна быть в порядке. Реализация будет намного проще, чем если бы вы постоянно сериализовали и десериализовали денормализованное строковое представление. Вам не придется изобретать велосипед, пока вы размышляете.

0 голосов
/ 06 июня 2010

1) если вы хотите перейти на рельсы сериализации, встроенная поддержка хранения хеша

от http://api.rubyonrails.org/classes/ActiveRecord/Base.html

class User < ActiveRecord::Base
    serialize :preferences
end

user = User.create(:preferences => { "background" => "black", "display" => large })
User.find(user.id).preferences # => { "background" => "black", "display" => large }

если вы используете эту технику, я бы поместил сериализованное поле в его собственный объект модели / таблицы, в противном случае оно будет включено в каждый пользовательский вызов find, что не идеально, возможно,

class User < ActiveRecord::Base
    has_one :contact_info
end

class ContactInfo < ActiveRecord::Base
    has_many :users
    serialize :data
end

# ...
user.contact_info.data[:phone_numbers] # => ['999 999-9999', '000 000-0000']

2) или если вы хотите отправиться по маршрутным маршрутам noSql с поддержкой mongodb, вы в основном вставили бы контактную информацию в пользовательскую модель / документ

3) или просто воспользуйтесь дополнительными таблицами, это не так плохо, как кажется, миграция рельсов может здесь сильно помочь с изменением требований

...