На предприятии ведется учет определенных сумм по каждому сотруднику за день.
Сотрудник может выполнять те или иные операции, и для каждого типа операции для данного сотрудника хранится количество обработанных единиц этой операции на определенное число. Грубо говоря, для этого используется таблица с полями ID_сотрудника, ID_операции, Дата, Количество. Соответственно, информация о сотрудниках и об операциях хранится в отдельных, связанных с этой, таблицах (если не углубляться).
На клиенте это должно выглядеть так: пользователь выбирает сотрудника и месяц и видит таблицу, в которой представлено число единиц каждой операции за каждое число месяца. То есть, после столбцов, описывающих операцию, следуют столбцы, связанные с числами месяца (31 столбец для простоты). При этом, пользователь также и вводит данные о выполненных единицах операций через эту таблицу.
Вопрос заключается в том, в каком виде лучше получать информацию непосредственно из БД.
1. Полагаю, можно написать хранимую процедуру, которая сама сформирует таблицу в нужном виде, и мне останется только привязать к этой таблице элемент управления, что-то подредактировав при необходимости. Мне этот вариант нравится тем, что не потребуется особо сложной прослойки между клиентом и SQL сервером.
2. Можно загрузить нужные записи из таблицы о совершенных операциях, а потом программно создать таблицу с требуемой структурой и заполнить ее самостоятельно. При этом, потребуется подгрузить и две другие таблицы (можно, конечно, выбрать все одной таблицей, но тогда передаваемые данные о сотрудниках и операциях будут повторяться, что мне не очень нравится). Этот вариант для меня выглядит более каноничЪным, ибо, все-таки, оформлением данных нужно заниматься на уровне, внешнем по отношению к БД.
Может быть, есть еще какие-то варианты?
Как же именно продумать схему взаимодействия, чтобы не допустить грубых нарушений стандартов разработки и обеспечить возможность гибкой работы с данными и их представлением?
В данный момент я разрабатываю клиент-серверное предложение, и в процессе проектирования возник такой вопрос. Но он интересен для меня и безотносительно к конкретной системе.
MS SQL SERVER + ADO.NET(C#).

WarAnt, эту тему могут туда перенести или мне нужно ее там создать заново?

Модератор: Тема перенесена из форума "Microsoft SQL Server".

koJIo6ok,

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

SERG1257,

таблица на форме имеет следующие поля:
[Код операции][Наименование операции][Единица измерения][Расценка][1][2]...[31]
Вводит он наверное не через таблицу а через форму заполняя ID_сотрудника, ID_операции, Дата, Количество
Для ввода данных нужна именно таблица на весь месяц, т.к. люди привыкли работать в Excel с подобными таблицами. Сотрудник и месяц выбираются из списков, а все операции, которые есть на данный месяц, висят в таблице. Нужно только ввести количество каждой операции за каждое число.
Это вы на сервере программно табличку создаете?
Ну, на том приложении, которое будет принимать сообщения от клиента, отправлять запросы на SQL сервер и передавать данные клиенту. Возможно, реально это будет реализовано внутри клиентского приложения.
Экономим копейки сетевого трафика.
В любой ситуации есть самое лучшее решение. И вряд ли оно приведет к нерациональному использованию ресурсов, даже незначительно.
Буду, наверное, программно реализовывать, все-таки, с MS SQL server не очень много работал.

Программист-Любитель,

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

Программист-Любитель,

авторПолучить такое ПРЕДСТАВЛЕНИЕ для удобства отображения на клиенте можно, легко и разными способами
Я не особо сомневаюсь, что такую таблицу можно получить средствами SQL сервера. Меня волнует, насколько легко потом будет с ней работать, чтобы привести в нужный вид на клиенте. Я имею в виду оформление, контроль ввода данных и т.д. Если я буду создавать таблицу программно, я точно знаю, что я смогу с ней сделать. Но если есть более правильный путь, я готов его освоить.

iljy,

да я все понимаю) не надо думать, что у меня в БД такие вот таблицы с кучей полей. У меня там сейчас 10 таблиц, максимум 5 полей в таблице