Ресурс с одним атрибутом. Признак того, что что-то пахнет? - PullRequest
0 голосов
/ 12 апреля 2011

У меня есть модель книги и модель заметок.В каждой книге может быть много заметок.

# note.rb
id | book_id | content | page_number | author_id |

Я хочу выполнить много запросов, таких как

  1. Получить все заметки для страницы 43 определенной книги
  2. Показать все отмеченные страницы определенной книги

Похоже, что эти типы запросов предпочитают создавать отдельную модель notes_pages, чтобы в книге могло быть много отмеченных страниц, а на каждой отмеченной странице может быть много заметок.Это нормально, но в моей таблице notes_pages фактически есть столбец id и столбец page_number, который мне не подходит.

Есть ли более стандартный способ реализации такого рода настройки или мое мышление нормально

Ответы [ 5 ]

1 голос
/ 13 апреля 2011

Таблица notes_page будет связывать заметки со страницами, но нужна ли вам таблица страниц?

Если вам нужна таблица страниц, тогда да, беспокойтесь о связи <-> страница многие-ко-многим.и создайте таблицу ссылок.Если вам не нужно хранить book_pages в виде строк таблицы, не надо.

Ваш дизайн: id |book_id |содержание |номер страницы |author_id |

Даст вам ответы на ваши вопросы, запросив их следующим образом:

  1. Получить все заметки для страницы 43 определенной книги

    выберите* из заметки, где book_id = 123 и page_number = 43;

  2. Показать все отмеченные страницы определенной книги

    выбрать номер страницы, количество (id) из заметки, где book_id= 123 сгруппировать по номеру страницы;

Если производительность является проблемой, поместите индекс на номер страницы.Вы также можете превратить (id, book_id, page_number) в составной ключ, чтобы ваши данные сохранялись (примечание 3, книга 123, стр. 43).

0 голосов
/ 13 апреля 2011

Ваш дизайн в порядке.Не переусердствуйте.Возможно, вы просто захотите поместить индекс на book_id, page_number в таблицу заметок, чтобы вы могли эффективно выполнять поиск.

0 голосов
/ 12 апреля 2011

Нет плохого дизайна ... это просто нужно обосновать.

Я вижу разные решения:

  1. A BOOK {title, author, edited_date ...} имеет много PAGE {content} has_many NOTES {note_content}
  2. A BOOK { content , название, автор, edited_date ...} has_many NOTES {note_content, page_number}

Это зависит от того, как вы работаете с книгой. Планируете ли вы сохранять содержание книги по страницам или нет? Если нет, то можете ли вы найти страницу и, следовательно, заметки?

По поводу ваших вопросов:

  • Модель с одним атрибутом не является признаком того, что она "пахнет". Вы можете даже иметь отношение 1 к 1, если это оправдано.
  • Нет "стандартного" способа реализации вещей. Как я уже сказал, это зависит от того, как вы работаете, от того, как вы планируете использовать его (с точки зрения пользовательского интерфейса), как вы будете хранить и т. Д. ...
  • Вам определенно не понадобится «многие ко многим» в вашем случае ... рельсы предоставляют достаточно инструментов для извлечения модели из ее ассоциаций, без условий и т. Д.

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

0 голосов
/ 12 апреля 2011

Оба эти запроса могут быть простыми ARel-запросами, область действия не требуется

Последний - простая проверка существования коллекции заметок:

@book.notes.empty? #if there are no notes, it'll return true and vice versa

Чтобы получить заметки к книге для определенной страницы:

@book.notes.where(["page_number = ?", page_number]) #where page_number is a variable, possibly a parameter

Однако я думаю, что вам нужно продумать, как вы собираетесь моделировать свои данные. У Марселя есть хорошая точка.

0 голосов
/ 12 апреля 2011

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

Это будет выглядеть так:

noted_page
--------------
id   book_id note_id

Это обычная практика, когда у вас есть отношение «многие ко многим», вы ДОЛЖНЫ иметь таблицу соединений.

(Некоторые рамки / правила не требуют, чтобы вы имелиid столбец, но, насколько мне известно, Rails / ActiveRecord действительно требует этого.)

...