Модели + Разработка базы данных

Question

Чего я хочу достичь:

• Изображения, которые должны быть либо одиночными, либо в альбомах
• Просмотр списка альбомов и отдельных картинок с нумерацией страниц
• Не показывать изображения внутри альбомов при просмотре, только обложка альбома

Мой подход до сих пор был:

• Модели, представляющие одно изображение и один альбом
• Содержимое одной таблицы базы данных, содержащее id, title, thumbnailFile, imageFile и т. Д.
• Один альбом таблиц базы данных с идентификатором альбома, названием альбома и т. Д.
• Одна таблица базы данных album_content, отображающая, какой контент находится внутри какого альбома
• Одна таблица базы данных с идентификаторами для альбомов и идентификаторами для содержимого, не входящего в альбом + скопированные атрибуты, используемые для предварительного просмотра и сортировки миниатюр (имена файлов, заголовки, представления, даты и т. Д.)
• Paginator использует только последнюю таблицу, в то время как view использует модель, указывающую на таблицу содержимого

Я не думаю, что вышеупомянутое слишком плохо в отношении скорости, но я не нахожу это особенно элегантным, и я ищу лучший способ сделать это, и, надеюсь, уменьшить количество элементов для кэширования / аннулирования , До сих пор я думал о чем-то вроде:

1. Наличие только одной копии данных в базе данных (каким-либо образом объединить содержимое, альбом и просмотреть и при этом иметь возможность быстро подсчитывать и сортировать набор данных по дате, просмотрам и т. Д.)
2. Держитесь подальше от объединений при сортировке / заказе по столбцу
3. Рассматривать все изображения как один экземпляр модели, а также внутри альбомов

Моя главная проблема в том, что у альбомов есть даты, просмотры и т. Д., Независимо от содержимого внутри него, и я хочу упорядочить по дате содержимого, не входящей в альбомы + по дате альбомов, которые должны иметь уникальный идентификатор. В альбомах также есть столбцы, не относящиеся к содержанию.

Есть хороший способ решить эту проблему?

* Редактировать : Для скорости, я думаю, я застрял в отдельной таблице просмотра. Есть ли способ, чтобы Zend dbTable ссылался на столбец представления альбома и содержимого browse <->, чтобы onUpdate в альбоме или содержимом использовал логику CASCADE в Zend для обновления обеих таблиц?

Answer 1

Я бы написал код за кулисами: 1 одно изображение = 1 альбом, напечатанный как один. Таким образом, просмотр отдельных изображений аналогичен просмотру альбомов. Разница лишь в том, что вы отображаете альбом «с одним изображением» или «обычный» альбом. Это имеет смысл, поскольку как альбомы, так и одно изображение имеют одно изображение, представляющее содержимое (изображение или обложку).

Таблицы могут выглядеть так:

t_album (id, type, title, cover_id, ...)
t_image (id, link, thumbnail_id, ...)
t_album_contents (id_album, id_image, comments)

Обратите внимание, что таблица [t_album_contents] необходима, только если изображение может быть в нескольких альбомах или может быть несколько раз в одном альбоме. В противном случае эта таблица может исчезнуть и быть заменена внешним ключом для [t_album] в таблице [t_image].

Answer 2

всегда неплохо сначала придерживаться нормализованной базы данных (3NF), а также выполнять оптимизацию во время выполнения на основе используемой СУБД (нарушать 3NF только в случае необходимости) ...

Опять же, я не могу прояснить этот момент: избегать нарушений 3NF при любой приемлемой стоимости

если вы добавляете что-то, что нарушает 3NF, убедитесь, что часть 3NF вашей базы данных остается неповрежденной в любой возможной ситуации ... ваши избыточные «скопированные атрибуты» могут привести к несогласованным данным, поэтому убедитесь, что данные в избыточности бесплатная 3NF часть вашей модели имеет приоритет ... например. Регулярное восстановление избыточных частей из частей 3NF, когда загрузка сервера позволяет это, или предоставление проверенной схемы обновления, которая гарантирует, что обновления применяются ТОЛЬКО к части 3NF, а каждое обновление в части 3NF вызывает перестройку соответствующих избыточных данных ... Подобные подходы пытаются минимизировать риск повреждения данных, когда вам нужны избыточные данные по причинам, таким как производительность при чтении из db

также неплохо отделить часть 3NF БД от другой части (по пространству имен / префиксу / и т. Д.)

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

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

почему контентная сущность не может представлять альбом? альбом похож на каталог ... в нем могут быть подкаталоги, которые будут содержимым с точки зрения каталогов ... если он моделируется таким образом, вы сравниваете контент с контентом ... дополнительные атрибуты, в зависимости от конкретного типа контента, могут находиться в другой таблице с отношением 1: 0-1, в то время как «общие» сопоставимые атрибуты находятся в таблице содержимого

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

надеюсь, это немного поможет