Как реализовать БД на основе подписки, например basecamp - PullRequest
Новая
       70

Как реализовать БД на основе подписки, например basecamp

4 голосов
/ 08 февраля 2010

Я разработал полнофункциональное приложение ruby-on-rails, которое использует множество таблиц mysql. Я хотел бы превратить это в сервис на основе подписки, но у меня есть некоторые общие, возможно, основные, концептуальные вопросы:

  1. В таких установках, как Basecamp, каждый пользователь имеет доступ к своим собственным (как в уникальных) таблицам БД или эти таблицы используются миллионами пользователей и идентифицируются по некоторой переменной?

  2. Если это так, то насколько хорошо оно масштабируется? Какую базу данных лучше всего использовать (mysql, oracle и т. Д.)?

  3. Если каждому пользователю предоставляются свои уникальные таблицы БД; как это достигается? Это через грабли?

  4. Есть ли у вас какие-либо ресурсы (книги, СМИ и т. Д.), В которых объясняется, как выполнить любой из этих методов?

Спасибо!

Ответы [ 2 ]

2 голосов
/ 08 февраля 2010

Я считаю, что это достигается с помощью общего аккаунта. При этом ресурсы вашей текущей системы будут ограничены этой учетной записью. т.е. в ваших действиях с индексом что-то вроде @projects = @ account.projects. Глядя на базовый лагерь, я бы сказал, что он очень хорошо масштабируется! Если вы столкнулись с этой проблемой, значит, вам нужно решить хорошую проблему, до тех пор не беспокойтесь об этом. Я должен представить, что база данных - это кластер, но очень сомневаюсь, что у каждого пользователя есть свой собственный набор таблиц, который стал бы кошмаром для управления!

Быстрый Google, и я нашел это: http://www.robbyonrails.com/articles/2009/01/11/subdomain-accounts-with-ruby-on-rails-explained, который также ссылается на сообщение DHH, которое, похоже, объясняет, как они это сделали.

Возможно, есть более новые статьи, но я думаю, они будут отличным началом.

Удачи!

0 голосов
/ 08 февраля 2010
  1. Таблицы совместно используются и идентифицируются для «родителя» с использованием значения внешнего ключа. Наличие отдельных таблиц для каждого пользователя было бы кошмаром. Скорее всего, хорошая нормализация базы данных устраняет большинство этих проблем. Задания связаны с проектами, проекты связаны с учетной записью, и тогда у каждой учетной записи много пользователей.
  2. Лучший БД для использования будет полностью за вами. Если вы используете миграцию rails и db, вы ограничены только тем, что может использовать этот интерфейс. Для начала выберите MySQL или PostgreSQL (мои предпочтения). Они бесплатны, и для хобби-проектов доступно множество знаний.
  3. Лично я бы не создавал отдельные таблицы для пользователя
  4. Чтение записей в Википедии по нормализация базы данных и дизайн базы данных было бы хорошим началом. После этого вы должны прочитать как можно больше о хорошем проектировании баз данных, возможно, даже начиная с распространенных ошибок, которые разработчики делают , когда дело доходит до проектирования баз данных.
...