Я работаю в биллинговой службе, которая использует несколько сложных программ для выставления счетов на мэйнфреймах для своих основных сервисов. У нас есть все виды кодов, которые мы настроили, которые используются для отслеживания вещей: коды платежей, коды провайдеров, коды списания и т. Д. ... Каждый тип кода имеет совершенно другой набор элементов данных, которые контролируют, что код делает и как оно себя ведет
Мне поручено создать новую систему для отслеживания изменений, внесенных в эти коды. Мы хотим знать, кто запрашивал какой код, кто / когда его просматривал, утверждал и реализовывал, и как выглядела точная настройка для этого кода. Текущий процесс отслеживает только два различных типа кода. Этот проект добавит немедленную поддержку третьего, с целью облегчить добавление дополнительных типов кода в тот же процесс на более позднем этапе. Моя загадка проектирования заключается в том, что каждый тип кода имеет свой набор данных, который должен быть настроен с ним, различной сложности. Итак, у меня есть несколько вариантов:
Я мог бы дать каждому типу кода свои таблицы и построить их независимо. Учитывая, что у нас есть только три кода, которые меня сейчас беспокоят, это будет проще всего. Однако эта концепция уже провалилась, иначе я бы не стал создавать новую систему. Он также слаб в том, что код, используемый при написании общего исходного кода на уровне представления для отображения данных запроса для любого типа кода (даже тех, которые еще не реализованы), не является тривиальным.
Создайте схему БД, способную хранить точки данных, связанные с каждым типом кода: не только значения, но и какой они тип и как они должны отображаться (выпадающий список из какого-либо перечисления). У меня есть приличная схема БД для этого, но она кажется неправильной: слишком сложен в запросе и обслуживании, и в конечном итоге он требует пользовательского запроса для просмотра полных данных в удобной табличной форме для каждого типа кода.
Сохранение точек данных для каждого запроса кода в формате XML. Это значительно упрощает проектирование базы данных и, будем надеяться, облегчит построение интерфейса: просто настройте схему для каждого типа кода. Затем получите код, который проверяет запросы к их схеме, преобразует схему в виджеты дисплея и отображает фактический элемент запроса на дисплее. Чего не хватает этому пункту, так это как обрабатывать изменения в схеме.
Мои вопросы: как бы вы это сделали? Я пропускаю какие-либо большие варианты дизайна? Есть ли другие плюсы / минусы в этом выборе?
В настоящее время я склоняюсь к использованию опции xml. Учитывая, что обновления схемы ожидаются, но крайне редки (вероятно, менее одного на кодовый тип в течение 18 месяцев), должен ли я просто создать его, чтобы предположить, что схема никогда не изменится, но чтобы я мог легко добавить поддержку для изменения схемы позже? Как бы это выглядело в SQL Server 2000 (мы переходим на SQL Server 2005, но он не будет готов до тех пор, пока этот проект не будет завершен)?
[Update]:
Одна из причин, по которой я думаю, что xml - это то, что некоторые данные будут сложными: вложенные / условные данные, нумерованные выпадающие списки и т. Д. Но мне действительно не нужно запрашивать какие-либо из них. Поэтому я подумал, что будет проще определить эти данные в XML-схемах.
Тем не менее, идея Ле Дорфье о внедрении совершенно новой технологии ударила совсем рядом с домом. В настоящее время мы используем очень мало xml везде. Это медленно меняется, но в данный момент это выглядит немного неуместно.
Я также не совсем уверен, как построить форму ввода из схемы, а затем объединить запись, которая соответствует этой схеме, в форму элегантным способом. Будет очень распространено хранить только частично заполненную запись, поэтому я не хочу создавать форму из самой записи. Это тема для другого вопроса.
Судя по всем комментариям, до сих пор Xml остается ведущим кандидатом. Отдельные таблицы могут быть как хорошими, так и лучшими, но у меня есть ощущение, что мой менеджер посчитает, что он не отличается или достаточно универсален по сравнению с тем, что мы делаем в настоящее время.