Связь Платформы объекта с Не Поля ключа
Я дрожу каждый раз, когда я вижу комментарии, что полные сканирования таблицы плохи и индексируют доступ, хорошо. Полные сканирования таблицы, индексные сканирования диапазона, быстро полные индексные сканирования, вложенные циклы, слияние, хэширования и т.д. являются просто механизмами доступа, которые должны быть поняты под аналитиком и объединены со знанием структуры базы данных и целью запроса, чтобы сделать любой значимый вывод.
полное сканирование А является просто самым эффективным способом считать значительную долю блоков сегмента данных (таблица или таблица (sub) раздел), и, в то время как это часто может указывать на проблему производительности, которая находится только в контексте того, является ли это эффективным механизмом для достижения целей запроса. Говоря как хранилище данных и парень BI, мой флаг предупреждения номер один для производительности является основанным на индексе методом доступа и вложенным циклом.
Так, для механизма того, как прочитать объяснить план, документация Oracle является хорошим руководством: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Имеет хорошее чтение через Руководство по Настройке Производительности также.
Также имеют Google для "обратной связи кардинальности", техники, которую объяснить план может использоваться для сравнения оценок кардинальности на различных этапах в запросе с фактической кардинальностью, испытанной во время выполнения. Wolfgang Breitling является автором метода, я верю.
Так, нижняя строка: поймите механизмы доступа. Поймите базу данных. Поймите намерение запроса. Избегайте эмпирических правил.
2 ответа
Entity Framework позволяет утверждать , что столбцы являются ключами и что ограничения FK существуют там, где их фактически нет в базе данных.
Это потому, что SSDL (StorageModel часть EDMX) вы можете при необходимости манипулировать и лгать о базе данных.
EF затем будет взаимодействовать с базой данных, как если бы ключи и внешние ключи действительно существовали.
Это должно работать, но применяются все обычные предостережения относительно ссылочной целостности.
См. мои Советы по Entity Framework
Надеюсь, это поможет.
The problem with using non-key fields to define relationships is that the keys are not guaranteed to be properly navigatable. That could lead to a situation where you have a one to one relationship between two entities where there are more than one possible rows that fufill the relationship.
...when relating data from a database, the relationships should always be based on keys. The keys enforce the referential integrity.