Показывать числовое значение дня недели в строке сетки для всей недели - PullRequest
Новая
       42

Показывать числовое значение дня недели в строке сетки для всей недели

2 голосов
/ 14 сентября 2011

У меня есть нормализованная таблица, в которой указаны дни поставки для разных поставок. Таблица нормализована в соответствии с рекомендациями БД и показывает день недели в виде числового значения (1,2,3 и т. Д.). Я использую Entity Framework и сетку Telerik, и мне нужно отображать дни недели в сетке, показывая каждый день недели и минимальное / максимальное количество единиц, которые могут быть доставлены в этот день. Эта таблица (поставки) связана с таблицей продуктов. Я показал дизайн таблицы и желаемый формат в сетке ниже.

Я не уверен, как отобразить эти данные в сетке. Мне сказали, что я могу использовать модель презентации, чтобы отобразить это? У меня нет примеров того, как это сделать. Если кто-то может показать мне пример кода, желательно о том, как лучше всего сделать это с Entity Framework и C #, так что это может занять день и знать, где связать в сетке, что было бы здорово. Спасибо заранее!

Таблица: Продукция 

product_id  (PK, INT, not null)      
ProductName (varchar(150), not null) 
Cost (decimal(18,2), not null)

Таблица: SupplyDeliveries 

schedule_id (PK, INT, not null)    
product_id (FK, INT, not null)     
DayOfTheWeek (smallint, not null)  //(Day of the week stored in number for ex 1,2,3 )   
MinNo (int, not null)         
MaxNo (int, not null)

* ПРИМЕЧАНИЕ. Поэтому, если бы я хотел показать график поставок бумаги в таблице SupplyDeliveries, то вот как должна выглядеть эта запись для product_id = 1 (Paper), DayofWeek = 1 (Monday), MinNo = 4, MaxNo = 5

поэтому в сетке вы увидите Dayoftheweek = 1 (понедельник) минимальные / максимальные единицы (4/5), которые я могу получить, и будет еще одна запись для product_id = 1 (бумага), DayOftheWeek = 2 (вторник) чтобы показать минимальные / максимальные единицы измерения, которые я могу получить. Для каждого продукта будет отдельная запись для каждого дня недели ..... надеюсь, это поможет

Вот что я хочу показать в сетке: 

Product Name Cost   Mon  Tue  Wed  Thu  Fri  Sat  Sun

Paper          $5   4/5  4/5                            
Stationery    $20   4/5       8/10      8/10
Printers     $100   4/5       5/6  5/6

Ответы [ 2 ]

0 голосов
/ 23 сентября 2011

Спасибо за вашу помощь, Майкл, ваше предложение заставило меня задуматься в правильном направлении. В итоге я создал сводную таблицу и использовал класс DTO для привязки к результату.Я смог получить все значения так, как я хотел.Надеюсь, это поможет кому-то еще. Я посмотрел следующий пример создания сводной таблицы

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=110576

0 голосов
/ 14 сентября 2011

Прежде всего, относительно вашей модели, почему у вас есть столбец schedule_id в таблице «Продукты»? Вы храните взаимосвязь между продуктом и расписанием в таблице SupplyDeliveries, поэтому кажется, что столбец schedule_id в таблице «Продукты» не нужен.

То, что вы пытаетесь сделать, называется опорой. Вы берете данные, смоделированные как строки, и отображаете их как столбцы. Насколько я знаю, в LINQ нет явного механизма для выражения сводки.

Есть несколько подходов, которые вы можете использовать здесь:

  1. Вы можете создать представление в своей базе данных, которое поворачивает данные и выражает их так же, как вы показали в своих результатах. Используйте EF для запроса представления и отображения результатов в сетке. Отображение должно быть простым, поскольку сущности, материализованные EF, будут именно тем, что вы пытаетесь отобразить.

  2. Вы можете использовать EF и запросы к выражению группировки, чтобы выполнить сводку. Скорее всего, это будет не так быстро, как выполнение разворота в представлении в БД, но должно привести к тому же результату. Ниже приведен пример.

  3. Вы также можете изменить модель БД, чтобы она уже была основана на столбцах. Одна вещь, которую следует отметить в вашей существующей модели, это то, что без второго уникального индекса на SupplyDeliveries (product_id, DayOfTheWeek) у вас может быть несколько записей «понедельник» для одного и того же продукта. Может быть, все в порядке ... Однако, если вы не хотите этого в первую очередь, другая модель, которую вы могли бы рассмотреть для своих данных, будет иметь столбцы: (product_id, mon_min, mon_max, tue_min, ...). Это полностью устраняет опору.

Вот пример для # 2: 

from s in SupplyDeliveries
group s by s.product_id into g
select new 
{
    ProductId = g.Key, 
    MondayMin = (from x in g where x.DayOfTheWeek == 1 select x.MinNo).FirstOrDefault(),
    MondayMax = (from x in g where x.DayOfTheWeek == 1 select x.MaxNo).FirstOrDefault(),
    TuesdayMin = ...
}

Edit:

Итак, подытожим, что в подходе № 1 вы строите сводный запрос в SQL и выставляете его в EF как представление, в то время как # 2 делает это в EF как выражение LINQ над базовой таблицей. Преимущество # 1 (в зависимости от вашей базовой базы данных) заключается в том, что вы можете использовать операторы SQL, такие как PIVOT, и более эффективно преобразовывать свои данные, прежде чем они попадут на прикладной уровень. Преимущество # 2 заключается в том, что вы можете сохранить это преобразование на уровне приложения, что может быть проще для вас, особенно если ваша база данных до этого момента строго состоит из таблиц.

Что касается # 3, это всего лишь предложение и представитель того, что вы могли бы сделать. Я не знаю деталей вашей модели и вашего приложения, поэтому сложно сделать полные предложения. Тем не менее, я не буду беспокоиться о том, что в этом случае данные будут редкими - столбцы задействованы относительно немного, особенно если у вас есть только одна минута / максимум в день недели для каждого продукта. С точки зрения эффективности использования пространства, за исключением product_id, у вас есть 56 байтов в подходе столбца и 14 байтов в подходе строки (в подходе строки вы также должны хранить день недели и отдельный столбец schedule_id). Таким образом, если у вас есть 4 дня недели, указанные в среднем по продукту, вы безубыточны. Это исключает дополнительное пространство, которое вам понадобится в подходе строк для соответствующей индексации. Кроме того, при строковом подходе ваши запросы всегда будут более сложными (т.е. медленнее) из-за дополнительных объединений и фильтрации.

...