SQL Server 2008 - запрос дизайна базы данных

Question

Мне нужно загрузить данные, показанные на рисунке ниже, в мою базу данных.

Для конкретной строки, либо поле PartID будет значением NULL или поле GroupID будет нулевым, а другие доступные столбцы относятся к ненулевому сущности. У меня есть три варианта:

1. Чтобы использовать одну таблицу базы данных, в которой будет один идентификатор столбца с идентификатором, который будет иметь данные PartID и GroupID. Но в этом случае я не смогу применить ограничение внешнего ключа, так как этот столбец будет содержать данные обоих сущностей.
2. Чтобы использовать одну таблицу базы данных, в которой будут указаны столбцы для PartID и GroupID, которые будут содержать соответствующие данные. Для каждой строки один из них будет NULL, но в этом случае я смогу применить ограничение внешнего ключа.
3. Чтобы использовать две таблицы базы данных, которые будут иметь схожую структуру, единственной разницей будет столбец PartID и GroupID. В этом случае я смогу применить ограничение внешнего ключа.

Следует отметить, что таблица (-и) будет использоваться в процессах импорта, чтобы импортировать около 30000 строк за один раз, а также будет активно использоваться в операциях извлечения данных. Кроме того, остальные столбцы будут использоваться как столбцы с поворотным знаком.

Может кто-нибудь, пожалуйста, предложите, какой должен быть лучший подход для достижения этого?

Answer 1

Я бы использовал параметр 2 и добавил ограничение, что только один может быть непустым, а другой должен быть нулевым (только для того, чтобы быть в безопасности). Я бы не использовал вариант 1 из-за отсутствия FK и возможности привязки к неправильной таблице, если не подчинялся идентификатору типа в соединении.

Существует 4-й вариант, который должен нормализовать их как «элементы» с другим (суррогатным) ключом и двумя таблицами ссылок, которые связывают элементы с любыми частями или группами. Это устраняет NULL. Есть и другие проблемы с этим подходом (элементы могут быть как снова, так и без каких-либо простых ограничений), поэтому, если это не необходимо по другим причинам, я бы вообще не пошел по этому пути.

Вариант 3 может быть точным - это действительно зависит от того, являются ли эти строки отношением, то есть данными, связанными с первичным ключом. Это одна проблема огромная проблема, которую я вижу с представленными данными, отсутствие ключа кандидата - я думаю, вам нужно обратиться к этому в первую очередь.

Answer 2

ИМО вариант 2 является лучшим - это не вполне нормализуется, но будет проще работать. 30K строк не много строк для импорта.

Answer 3

Я бы изменить таблицу таким образом, она имеет один ID столбец, а затем добавить IDType, который либо «G» для группы или «P» для части.