Моя проблема в том, что мне нужна сетка с указанием времени, затраченного на выполнение задач. Дни недели должны быть вверху (желательно, чтобы они были фиксированными, например, вс, пн ... сб), а названия задач внизу в левом столбце. В содержимом таблицы будут указаны часы, потраченные на выполнение этой задачи в течение дня.
Что лучше всего использовать для этого? Первый вариант - попытаться поместить все это в операторы SQL в базе данных. Вариант два - это набор запросов LINQ, которые извлекают необработанные данные из Tasks и TimeEntries и правильно их структурируют. Третий вариант - использовать LINQ и переносить результаты в класс (или коллекцию), который затем привязывается к элементу управления (возможно, к сетке).
Как бы ты это сделал?





Вы, кажется, подразумеваете, что данные в настоящее время находятся в базе данных. Оптимальное решение зависит от объема внутренней обработки данных и существующей инфраструктуры проекта.
Я бы либо использовал большой SQL-запрос, чтобы собрать все данные вместе и напрямую связать ResultSet с сеткой (практически без обработки или инфраструктуры), либо использовать LINQ для заполнения своего рода класса TimeSheetModel, используя существующую инфраструктуру и обеспечивая дальнейшую обработку.
Я сделаю грубый взлом, не зная вашей структуры, но предполагая, что у вас есть таблица задач и таблица времени задач, в которых хранятся фактическое время и даты, которые взимаются с каждой задачи. Это не проверено, но:
выберите t.taskname, sum (случай, когда datepart (d, tt.taskdate) = 1, tt.taskhours) иначе 0 end) как воскресенье, сумма (случай, когда datepart (d, tt.taskdate) = 2, t.taskhours) иначе 0 конец) как понедельник из таблицы задач t присоединиться к Tasktime tt на t.taskid = tt.taskid где tt.taskdate> = @begindate и tt.taskdate <= @enddate
Предложение where важно, потому что вы, вероятно, хотите отображать только неделю (обычно текущую неделю) в своей сетке. Это также предполагает, что вы правильно сохранили даты ваших часов, оплачиваемых как тип данных datetime. (если вы не исправите это сейчас - вы поблагодарите меня позже.) Переменные будут отправлены из пользовательского интерфейса каким-то образом. Я лично сделал бы это как хранимую процедуру. Я оставил вторник по субботу для тебя.
Это определенно лает правильное дерево. Я попробую это сегодня и посмотрю, как я уйду. Голосуйте за помощь в любом случае, спасибо.
Это не совсем то, за чем я гоняюсь, но структура - очень хорошее руководство для меня, чтобы начать. Заявления о случаях - это в основном то, что я ищу, и как только я выясню, как правильно агрегировать результаты, я думаю, что у меня все получится. Спасибо за руководство!
Вы можете использовать LinqToSql для извлечения строк в память, а затем LinqToObjects для агрегирования этих строк в формат вашей таблицы (это агрегирование вращения).
В этом посте показан сводный запрос linq. В вашем случае это будет работать достаточно хорошо, поскольку вы знаете столбцы, которые хотите создать во время разработки. Команда SQL для LINQ (поворот)
Я рекомендую использовать 0 анонимных классов. Должен быть (как минимум) класс, представляющий строку в базе данных, и класс, представляющий значения строки в сетке.
И поскольку я могу говорить здесь все, что хочу, я хотел прокомментировать методику HLGEM SUM (CASE). Я использовал это раньше в отчетах, где мне приходилось писать только на SQL. Работает очень хорошо ... если вы хотите писать на SQL.
Гаа! Столько правильных и полезных ответов. Я предпочитаю LINQ, хотя у меня тоже нет проблем с использованием SQL. Теперь у меня полностью работает Stored Proc, так что это должно обеспечить хорошую основу для перевода в LINQ. Я опубликую еще раз, как только получу результат. Спасибо за чаевые.
Мне нравится идея держать как можно больше данных в руках базы данных. Но я борюсь со структурой запроса. Есть там администраторы баз данных?