Linq против базы данных

Question

Вот интересный вопрос. Предположим, у нас есть связанные таблицы в базе данных, например, Инструмент и Валюта. В таблице инструментов есть поле currency_id, которое сопоставляется с записью в таблице Currency. В земле Линк, что лучше:

a) Создайте сущности Instrument и Currency в DataContext, а затем создайте связь или просто используйте объединение в запросах Linq или

b) Создать представление в базе данных, которое объединяет инструмент и валюту (таким образом, преобразовывая currency_id в код валюты) и использовать его как сущность в контексте Linq?

Answer 1

Вы когда-нибудь использовали бы их независимо? Если это так, вам понадобятся сущности для каждой из них, которые будут использоваться независимо. Я подозреваю, что вы будете использовать валюту независимо (скажем, для выпадающего списка, который позволяет вам выбрать валюту при создании инструмента). В таком случае, я думаю, было бы легче просто держать их отдельно и иметь ассоциацию.

Answer 2

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

Answer 3

• Если вы загрузите инструмент, а затем используете свойство «Валюты» для загрузки связанных валют, будет два запроса.

• Если вы выполните запрос linq с объединением, linq преобразует его в sql с объединением, и вы получите все данные сразу.

• Если вы настроили DataLoadOptions, вы получите все данные в одном запросе и вам не нужно будет писать соединение.

http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.aspx http://msdn.microsoft.com/en-us/library/system.data.linq.dataloadoptions.loadwith.aspx

DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Instrument>(i => i.Currencies)
myDataContext.LoadOptions = dlo;

Answer 4

Теперь, когда ORM абстрагирует логику доступа к данным, конкретная функция представлений больше не нужна. Было бы лучше оставить это ORM, так как это часть его функции.

Однако представления могут быть полезны для упрощения кода хранимых процедур и даже для создания полезных индексов.