И лишний раз напомню, что SQL - это стандартизированный язык запросов, используемый десятками разных СУБД.
А не название единственного в мире сервера баз данных, как полагают адепты микрософт.
Олег, как угодно. Но к связям между таблицами данный вопрос отношения не имеет. Здесь нет никаких связей. Вопрос вообще не имеет отношения к базам данных, а только к тому как Entity Framework формирует запросы.
Соответственно, поменяв тег вы значительно повысите свои шансы на ответ.
Akina, а какая разница? Ему же не связывать, а просто имя достать. Или SQL-сервер может использовать в запросе в качестве имени таблицы значение из ячейки?
ThunderCat, ну как раз наоборот. все нормальные ORM проверяют валидность.
А это не ORM, а какой-то цыганский табор: создашь лишнее поле в объекте - и у тебя уже лишняя колонка в таблице. Опечатаешься в названии таблицы - и уже новая таблица. И всё молча, как будто так и надо.
Я думаю, у пользователей РБ база данных из таких опечаток состоит чуть менее, чем полностью.
Непонятно, какая связь между читаемостью кода и отладкой.
Ну то есть понятно что понты "я пишу код без ошибок", но в реальности читать код - это одно, а отлаживать - другое.
Даже самый читаемый и оттестированный код может содержать логическую ошибку. Или работать неправильно из-за неверных входящих данных. Именно такие ошибки и ищутся с помощью трассировки.
Akina, я имею в виду саму реализацию оконной функции.
Будет ли подсчет при её использовании таким же быстрым, как count() отдельным запросом, или таким же медленным, как подсчет с помощью SQL_CALC_FOUND_ROWS.
