Альтернатива приближается к запросу сложного выхода в плохо разработанной схеме

Я работаю над интеграцией некоторых данных из сторонней системы в одно из моих приложений (ASP прежней версии Основанное на классике веб-приложение / SQL 2000) - они приняли некоторые плохие решения (по моему скромному мнению), когда дело доходит до их подхода и структуры данных, хотя, возможно, мы могли бы получить шанс осуществить рефакторинг в какой-то момент..., но до тех пор, я должен работать с тем, что передо мной.

Основная таблица содержит инспекционные данные с одним из полей, используемых, чтобы записать, если определенные характеристики наблюдались. Характеристики хранятся в названной Таблице Categories, но к сожалению, основная проверочная таблица (Test) ссылки на категории путем конкатенации релевантный CategoryIDs в единственное поле (SelectedCategories). Так, например, если характеристики 01 и 02 наблюдались, SelectedCategories столбец для той строки в Test имел бы значение '01C02C'.

Обрезанный DDL:

CREATE TABLE [dbo].[Test](
[ItemID] [varchar](255) NOT NULL,
[Result] [varchar](255) NULL,
[Comments] [varchar](255) NULL,
[ResultReason] [varchar](255) NULL,
[ImageLocation] [varchar](255) NULL,
[TestDateTime] [smalldatetime] NOT NULL,
[SelectedCategories] [varchar](255) NULL)

Вопрос, учитывая ситуацию, как лучше всего может я соответственно извлекать данные из Test с разбивкой наблюдаемых характеристик?

Вывод на клиенте, который я хочу, является таблицей со следующими столбцами: Тест. PK, Тест. Field2... Тест. Fieldn, Категории. ID1, Категории. ID2, Категории. IDn

Это, вероятно, достаточно не совсем ясно - первые поля были бы обычными подозреваемыми от Test, сопровождаемый галочкой или крестом (или некоторый другой визуальный индикатор) для каждой из категорий в Categories.

Очевидно, если это может быть достигнуто в одном запросе, тем лучше с точки зрения эффективности и производительности. Однако я не уверен, как это было бы достигнуто - как Вы присоединитесь Categories таблица через SelectedCategories?

Я мог, очевидно, просто сообщить SelectedCategories оцените и имейте синтаксический анализ приложения значение. Это могло быть трудно кодировано, или более вероятно мы повторно запросим Categories для каждой строки в Тесте - хотя это имело бы последствия производительности. TBH, производительность, вероятно, не является проблемой в этом случае, но просто потому что можно сойти с рук что-то, не означает, что необходимо сделать привычку к нему.

Аналогичным образом, если у меня есть возможность осуществить рефакторинг приложение сторонних производителей, был бы я удалять SelectedCategories столбец и добавляет в a TestCategories таблица? Или был бы я твердый код каждая категория как серия Bit столбцы. По всей вероятности, Categories не изменится в течение жизни системы, но если они сделали, это означает изменения (хотя очень незначительный) и к DB и к приложению.

Я надеюсь, что объяснил это достаточно ясно. В сущности я говорю, каков лучший подход, если я придерживаюсь существующей системы? И если я должен был осуществить рефакторинг, какой другой подход я мог проявить?

Обновление прогресса:

В основном благодаря Lieven, я имею к настоящему времени:

DML:

SELECT  c.ID, c.Category, t.FilterID, t.OperatorResult, t.SelectedCategories
FROM    dbo.Categories c
        inner JOIN dbo.Test t ON CHARINDEX(Cast(c.ID as varchar), t.SelectedCategories, 1) <> 0
order by FilterID, ID

Вывод:

ID   Category             FilterID   OperatorResult   SelectedCategories
4    Cracked Ceramic      137667     FAILED           04C
4    Cracked Ceramic      284821     FAILED           04C
4    Cracked Ceramic      287617     FAILED           04C05C
5    Damaged Case         287617     FAILED           04C05C
4    Cracked Ceramic      310112     FAILED           04C05C
5    Damaged Case         310112     FAILED           04C05C

Это было бы достаточно, за исключением того, что для достижения моего желаемого экранного вывода...

Filter ID  Operator Result    Cat Matl   Crack    Damage   High Soot   
137667     FAILED             X          X        
178643     FAILED           
284821     FAILED                        X        
287617     FAILED                                 X        X     
310112     FAILED                        X        X    

... Я любая дальнейшая работа потребности над SQL (так, чтобы я мог достигнуть желаемого вывода во всего одном запросе) или я должен сделать некоторую дополнительную работу в самом приложении.

Заключение:

Если мы смотрим на последний пример Lieven (ниже), мы видим, что проблемой можно заняться в TSQL, но что Категории трудно кодируются.

Альтернатива, придерживаются необработанных данных и делают IIS/ASP, действительно больше работают. Это усложнит исходный код наверняка, но удалит потенциал наверху обновления TSQL, если категория будет добавлена или удалена. Я мог, конечно, жить с этой очень случайной потребностью обновить TSQL, но я предполагаю к различным проблемам, где таблица Categories активно изменилась бы регулярно.