Настройка таблицы в MSSQL

Question

Я ищу лучший способ настроить мои таблицы SQL в следующем сценарии.

Я сделаю все возможное, чтобы объяснить свою ситуацию.

Например, у меня есть 10 тестов, Test1, Test2, Test3, ...., Test10. Все они используют аналогичную область, но некоторые тесты будут использовать разные поля в зависимости от теста.

Предположим, что Test1 использует Field1, Field2, Field3. Test2 использует Field1, Field2, Field4, Field5. Мне нужно сохранить нужную информацию о поле в таблицу, но мне также нужно сохранить те поля, которые используются в каждом тесте. Я буду получать доступ к этой информации с помощью VB.net.

Я ищу лучший способ установить это. Он должен быть несколько прост в обслуживании, но также иметь довольно хорошую производительность.

Моя первоначальная мысль состояла в том, чтобы установить две таблицы. В одной таблице будут храниться результаты каждого теста и та, которая хранит поля, используемые для каждого теста. Тот, который хранит результаты каждого теста, будет иметь все возможные столбцы, которые могут использовать любые из тестов. Таблица, для каких полей будет использоваться каждый тест, также будет иметь все возможные столбцы. В этом случае каждая строка будет тестом, и каждый столбец будет тем, какие поля используются для этого теста. Итак, Test1 будет иметь 1 в столбцах 1, столбце2 и столбце3. Test2 будет иметь 1 в столбцах 1, столбце2, столбце4 и столбце5. Это сообщит нам, какие поля необходимо использовать при выборе, обновлении или вставке в нашу таблицу результатов.

Надеюсь, это имеет смысл в отношении того, что я пытаюсь выполнить. Я не уверен, что это лучший способ выполнить мои требования или нет.

Любые указания здесь были бы очень признательны.

Спасибо, Тони

UPDATE Я просто хочу уточнить, что я с помощью MS SQL.

UPDATE Я также хотел бы уточнить, что мои имена полей на самом деле не поле 1, Field2 и т.д. Я просто использовать это, чтобы попытаться объяснить, что я пытаюсь сделать.

Answer 1

Я думаю, что лучший способ заключается в использовании пользовательского символа в качестве разделителя, например | полукокса как этого

somthing|another field|another filed data

, когда вы хотите прочитать данные, разделенные |

, а также вы можете сохранить выбранный по данному сценарию

1|3|5|2|0|4|1|2

вам нужно только 2 строки для хранения вопросов и ответов :)

Answer 2

То, о чем вы просите, я считаю, это таблица переменных столбцов. Особенно, если учесть долгосрочные последствия добавления дополнительных тестов.

Одна вещь наверняка, способ НЕ решить проблему состоит в том, чтобы добавить кучу столбцов с родовыми именами (field1, 2, 3 .... 40) и использовать их так, как вам нужно, в надежде, что вам никогда не понадобится 40.Это создает конструкцию, которая очень проблематична для разработки и поддержки.

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

Лучшее решение, использующее современные базы данных, заключается в том, чтобы хранить объекты (тесты) в режиме без схемы. В реляционной базе данных, которая ее поддерживает, вы можете использовать собственное поле XML (или json в некоторых базах данных). В этом случае вы сохраняете метаданные об объекте в обычных полях и сохраняете XML-сериализованные объекты в поле xml. Таким образом, ваш объект может измениться по мере необходимости без изменения схемы базы данных, и вы можете продолжать использовать значащие имена и типы данных.

В сценарии реляционных db важно выбрать db, который имеет собственный тип данных xml или json, а также просто использовать varchar или blob. Причина в том, что собственный тип будет включать в себя возможность запрашивать данные способами, которые обычно более эффективны, чем регулярное выражение.

Конечно, это то, что нет в SQL-базах данных, таких как MongoDB. У меня был хороший успех с обоими подходами. Для простых решений я обычно выбираю Монго. Для решений, в которых мне нужна реляционная база данных, я буду использовать MS-SQL и SQLXml.

SteveJ

Answer 3

Вам нужны четыре стола. Тесты и поля имеют отношения «многие ко многим», поэтому вам нужны эти две таблицы плюс таблица соединений TestsFields. Наконец, вам нужна таблица результатов с полями TestNumber, Fieldnumber и Result. Это соответствует информации, указанной в вашем вопросе, хотя это немного неоднозначно. Возможно, вам потребуется расширить эту схему, чтобы разместить несколько тестов/экзаменов или что-то еще - вы не задали этот контекст, поэтому я не могу сказать.

EDIT:

Например, давайте приложение обслуживания автомобиля в качестве примера. (К сожалению, вы выбрали «Поля» для одной из своих таблиц, и я хочу использовать «поля» в дальнейшем, поэтому я выделил их с помощью капитализации). В этом сценарии таблица тестов будет иметь поля TestID и Description , с такими значениями, как 1, «Инспекция предварительной доставки», 2, «5000-мильная услуга» и т. д. и таблица «Поля» будут иметь поле ID и описание со значениями 1, «Проверить давление в шинах», 2 «Проверить кабель ручного тормоза» и т. д. Тогда таблица соединений TestsFields будет состоять из двух первичных ключей.

В этом случае вам также понадобится другой стол или два для покрытия отдельных автомобилей, служебных встреч и т. Д., Но давайте не будем увлекаться!

Таблица результатов будет включать ServiceApptID, TestID, FieldID и Result. Результат может быть свободным текстом, где механик может записывать результаты или другой поиск в набор консервированных ответов - 1 «Скорректирован», 2, «Заменять детали» и т. Д.

Должно быть достаточно, чтобы перевести идею.