Дизайн: лучший способ вернуть массив дочерних объектов из SQL

Question

У меня есть объект в C #

class Products {
    public int ProductId {get; private set;}
    public string DisplayName { get; set; }
    public int DisplayOrder { get; set; }
    public List<ProductImages> Images {get; set;}
}

class ProductImages{
    public string Channel { get; set; }
    public string ImageType { get; set; }
    public byte[] Image {get; set;}
}

Теперь уже есть процедура для GetProducts, которая возвращает все, кроме изображений, в противном случае я бы, вероятно, превратил весь запрос в объект XML и выполнил бы сериализацию, хотяМеня попросили не делать этого.

Принято решение:

• Создать новый столбец в этом запросе, и только этот столбец является XML (или JSON), а затем просто десериализовать массив ProductImages

• Сделайте отдельный вызов в базу данных, чтобы получить дочерний объект. То есть передайте Product Id, верните таблицу ProductImages и на стороне сервера переберите таблицу и создайте дочерние объекты.

Сравнивает ли стоимость десериализации объекта стоимостьснова установить соединение с базой данных и просмотреть таблицу рекордов?

Answer 1

Это решение должно основываться на соображениях проектирования модели, а не на вопросах реализации.

Если все следующее верно, используйте один большой двоичный объект для всех изображений в таблице Product:

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

В противном случае создайте отдельную таблицу, прикрепленную к Product вотношение «многие к одному» для не общих изображений или с дополнительной таблицей «многие ко многим» для общих изображений.

В некоторых случаяхЕсли будет полезно удалить Images из Product и выбрать вместо него API, аналогичный GetProductImages(productId, additionalCriteria), с additionalCriteria, представляющим контекст, в котором вы хотите использовать изображения (например, рынок).

Наконец, вы можете выбрать ленивую загрузку изображений в ситуациях, когда некоторые варианты использования не показывают изображения вообще - например, раскрывающиеся списки могут включать только DisplayName, тогда как более подробный вид можетвключить изображения. Это соображение относится как к нормализованным, так и к денормализованным (все изображения в BLOB) решениям.

Answer 2

Я думаю, что первое решение лучше. Обычно лучше избегать повторного попадания в базу данных. В любом случае легко настроить небольшой тест, измерить время и использование памяти для обоих вариантов и выбрать, какой из них подходит лучше