Я нахожусь в процессе миграции приложения Access на Sharepoint 2010 (Enterprise). Я хотел бы использовать как можно больше функциональных возможностей Sharepoint "из коробки", но я не против создания некоторых веб-частей.
Я борюсь с дизайном "мастер" таблицы в этом приложении. Приложение используется для отслеживания производительности сотрудников. Ежедневно около 50 пользователей получают доступ к приложению и в основном вводят, сколько «виджетов» они выполнили в тот день. Существует около 30 типов этих «виджетов», и они меняются не очень часто.
Таблица разработана с отдельными столбцами для каждого из этих виджетов. Это делает создание отчетов очень простым, поскольку все, что вам нужно сделать, это выбрать все поля из таблицы и вывести набор результатов.
Недостатком этого подхода является тот факт, что схема является "жестко закодированной" (статической). Меня попросили (ради времени) максимально нормализовать таблицу (с помощью идентификаторов клиентов, идентификаторов сотрудников и т. Д.), Но при этом оставить все поля "Виджет" там.
Я предложил создать отношение типа Master Detail, в котором пользователи будут добавлять строку (возможно, в GridView), выбирать «виджеты», которые они создали в тот день (из выпадающего списка), и вводить их количество. Они обычно делают 1 - 3 типа виджетов в день.
Пользователи ненавидят этот дизайн и хотят, чтобы я дал им форму ввода данных со ВСЕМИ отображаемыми виджетами, чтобы они могли просто щелкнуть в поле (рядом с виджетом, который они создали в тот день) и ввести свое количество, а затем нажать кнопку Сохранить.
Я знаю, что все еще мог бы создать этот тип формы ввода данных с типом отношений Master-Detail, но я почти уверен, что не смогу использовать формы SP из коробки. Я, вероятно, должен был бы создать веб-часть с GridView и просто заполнить GridView всеми возможными Wisdgets, а затем позволить пользователю вводить правильные Qty рядом с каждым виджетом, который они создали в тот день. Когда форма будет отправлена обратно, мне нужно будет просмотреть ее, найти Qtys, которые являются действительными числами, и добавить (дочернюю) подробную запись для этой основной записи. (Основная запись будет содержать дату, сотрудника, клиента и т. Д. И т. Д.) Форма редактирования также должна работать аналогичным образом.
Это довольно "уродливое" решение, и я искал альтернативу.
Если я не смогу найти хорошую альтернативу (и убедить моего менеджера, что код не будет слишком сложным для сопровождения, или добавить слишком много времени на разработку проекта, чтобы завершить его вовремя), тогда мне придется перенести эту уродливую существующую схему со всем ее потраченным впустую пространством и иметь «жестко закодированные» вещи во всем приложении. (Например, если я предоставлю им представление SharePoint для просмотра количества созданных виджетов определенного типа, мне придется «жестко закодировать» все эти значения в раскрывающемся списке и «суммировать» правильный / соответствующий столбец базы данных. YUK.
Еще одним соображением является отчетность. Сейчас все отчеты содержат столбец отчета для каждого виджета. Чтобы сохранить внешний вид этих отчетов (если я использую отношение Master / Detail), потребуются «более сложные» запросы (хранимые процедуры) для составления правильного набора результатов в формате «columuar». (И я не уверен, как бы я справился с раскладкой представлений данных SharePoint аналогичным образом.)
Конечно, было бы "проще" просто оставить схему как есть (и иметь всю эту потерянную память в таблице). Я просто ненавижу разрабатывать приложение, потому что в любое время, когда нам нужно добавить новый "виджет" в приложение, мы должны изменить приложение в нескольких местах и перестроить. (Хотя мой менеджер не обеспокоен этим, он просто хочет вытолкнуть это, как можно скорее ... вздох ...)
Будем весьма благодарны за любую помощь / рекомендации по созданию приложений такого типа (в частности, по созданию форм и представлений ввода данных) в SharePoint!
Шэйн