Блог

Мне любопытно, как я должен организовать хранение изображений в моем приложении. Они будут храниться где-нибудь на диске с путем / URL, сохраненным в базе данных, но мое приложение стало сложным, и организация изображений ставит меня в тупик. Технология, которую я использую, является ASP.NET Сначала код MVC 3 EF 4.1 (что оказывается затруднительным из-за сложных взаимосвязей).

Это приложение на основе семейства, поэтому есть таблица семейства, таблица членов и таблица FamilyMember, с которыми можно связать две. Существует также FamilyEvent и таблица MemberEvent для отслеживания событий в жизни семьи или члена.

Варианты использования

Участник может загружать несколько изображений профиля (возможно, для размещения в альбоме «профиль»?)

Участник может загружать «семейные» фотографии, которые будут прикреплены к семейному объекту и помещены в какой-либо семейный альбом.

Участник может добавить событие member и прикрепить несколько изображений к событию members.

Участник может добавить семейное событие и прикрепить несколько изображений к семейному событию.

Это базовые варианты использования.

Мои мысли

Базовая таблица «Изображение» с идентификатором, описанием и, возможно, идентификатором пользователя загрузчика.

Таблица MemberProfilePicture с идентификатором, PictureID, MemberID и т.д…

Таблица MemberEventPicture с идентификатором, PictureID, [идентификатор участника?], membereventid и т.д…

Таблица FamilyEventPicture с идентификатором, PictureID, [FamilyID ?], familyeventid и т.д…

Это позволило бы семье или члену по существу «связать» изображение позже с другой фотографией профиля / событием участника / или семейным событием.

Мой вопрос

Это правильно, или я слишком усложняю это? Я не вижу другого способа представления изображений для разных объектов, кроме нескольких таблиц, которые все ссылаются на базовую таблицу изображений. Кто-нибудь может дать какие-либо предложения относительно того, как я могу улучшить эту модель? Хотя я понимаю, что может быть много определений, требующих исправления, я ищу решения относительно того, как организовать аспект визуализации моего приложения, или улучшения того, что у меня уже есть.

Сначала вы используете EF-код, поэтому давайте поговорим о коде, а не о таблицах. Вы можете реализовать свои варианты использования, имея только один класс Picture и связывая множество изображений с участником, семейством и так далее.

Берем этот код

 public class Family
{
    public int Id { get; set; }
    public virtual ICollection<Picture> Pictures { get; set; }
    public virtual ICollection<Member> Members { get; set; }
}

public class Member
{
    public int Id { get; set; }
    public virtual ICollection<Picture> Pictures { get; set; }
}

public class Picture
{
    public int Id { get; set; }
    public String Location { get; set; }
}
  

Сгенерирует 3 таблицы, семейства, члены, изображения, причем таблица Pictures будет иметь два внешних ключа Family_Id и Member_Id. Эта модель позволяет связать одно изображение с членом, семьей или обоими.

С точки зрения масштабируемости я бы не стал хранить двоичный файл изображения в базе данных и использовать ORM для доступа к двоичному файлу. Лучшие идеи — хранить изображение в файловой системе или на «специализированном» сервере, таком как MongoDBs GridFS.

Что бы я хотел сделать, так это иметь три таблицы.

Таблица ‘picture’, в которой хранится уникальный идентификатор для каждого изображения и местоположения. Таблица «профиль», в которой содержатся ваши сведения о профиле. Третья «связующая» таблица, состоящая из PictureID и ProfileID

Если я хочу связать изображение A с профилем X, я просто добавляю «A, X» в таблицу ссылок. То же самое для событий или чего-то еще. Если предполагается взаимосвязь «многие ко многим», это самый простой способ (я предполагаю, что одно и то же изображение может быть в нескольких профилях).

Надеюсь, я правильно понял вашу проблему.