Если таблица очень большая (количество элементов в миллионах), и нет необходимости регистрировать транзакции DELETE, удаление ограничений и TRUNCATEing и воссоздание ограничений, безусловно, является наиболее эффективным способом. Кроме того, если в других таблицах есть внешние ключи (и в этом конкретном дизайне таблицы это может показаться так), все эти строки также должны быть сначала удалены во всех случаях.
Нормализация ничего не говорит о рекурсивных / иерархических / древовидных отношениях, поэтому я считаю, что это красная селедка в вашем ответе на предложение DVK разбить это на свою собственную таблицу - безусловно, жизнеспособным будет сделать вертикальное разбиение этой таблицы и также подумайте, можете ли вы воспользоваться этим, чтобы получить другие преимущества, перечисленные ниже. Как намекает DVK, в этом конкретном проекте я часто видел отдельную таблицу ссылок для записи собственных и других видов отношений. Это имеет многочисленные преимущества:
- есть много ко многим вверх и вниз вместо многих к одному (необычно, но потенциально полезно)
- отслеживание различных типов прямых отношений - менеджер, наставник, помощник, утверждающий заработной платы, утверждающий расходы, технический отчет - со строками в таблицах отношений и типов отношений вместо новых столбцов в таблице сотрудников
- отслеживание изменений иерархий согласованным во времени способом (включая прекращенную историю иерархии сотрудников) путем включения активных индикаторов и дат вступления в силу в строках отношений - это полностью возможно только при нормализации отношения в его собственной таблице
- нет NULL в SeniorID (фактически для любого ID) - это явное преимущество во избежание плохой логики, но NULL обычно появляются в представлениях, когда вам все равно нужно оставить соединение с таблицей отношений
- лучшая специализированная стратегия индексирования - в отличие от добавления SeniorID к выбранным индексам, которые у вас уже есть на Employee (особенно с ростом числа типов отношений)
И, конечно, чем больше информации вы относитесь к этим отношениям, тем сильнее указывается, что само отношение заслуживает таблицы (т. Е. Это «отношение» в истинном смысле этого слова, используемого в реляционных базах данных, связанных с данные хранятся в отношении или таблице (связанной с первичным ключом), и, таким образом, обычная форма отношений может строго указывать, что таблица отношений создается вместо простого отношения внешнего ключа в таблице сотрудника.
Преимущества также включают в себя простой сценарий удаления:
DELETE FROM EmployeeRelationships;
DELETE FROM Employee;
Вы заметите поразительную эквивалентность принятому ответу здесь на SO, так как в вашем случае сотрудники без старших отношений имеют NULL - поэтому в этом ответе плакат сначала устанавливает все в NULL, чтобы устранить отношения, а затем удалить сотрудники.
Возможно, есть подходящее использование TRUNCATE в зависимости от ограничений (EmpployeeRelationships обычно может быть TRUNCATEd, поскольку его первичный ключ обычно является составным, а не внешним ключом в любой другой таблице).