Microsoft SQL Server принимает пустое имя переменных — почему?
Microsoft SQL Server допускает пробелы в именах переменных с помощью квадратных скобок:
CREATE TABLE [dbo].[MyDataTable](
[Compo 1] [nvarchar](50) NULL,
[Compo 2] [nvarchar](50) NULL,
[Compo 3] [nvarchar](50) NULL,
compo1 [nvarchar](50) NULL,
compo2 [nvarchar](50) NULL,
compo3 [nvarchar](50) NULL,
compo_1 [nvarchar](50) NULL,
compo_2 [nvarchar](50) NULL,
compo_3 [nvarchar](50) NULL)
Проблема в том, что происходит, когда такой инструмент, как Entity Framework или NHibernate, или любой другой ORM-инструмент, или даже вручную я пытаюсь создать модель на основе моей базы данных?
При использовании C#, VB.NET, Java и, вероятно, большинства языков разработки невозможно использовать пробелы в имени вашей переменной.
Итак, чтобы исправить этот поставщик LINQPad по умолчанию, игнорирующий и удаляющий пробелы при создании C#, альтернативный поставщик Linq2Db, похоже, заменяет пробелы символом подчеркивания. Все эти правила генерации могут конфликтовать с другой переменной в моей базе данных, если у меня есть переменная, которая уже является альтернативным решением, как в моем примере.
В LINQPad у меня есть это
MyDataTable.Compo1; // With capital letter and mapto [Compo 1] [nvarchar](50) NULL,
MyDataTable.compo2; // with small letter and map to compo2 [nvarchar](50) NULL,
MyDataTable.compo3;
MyDataTable.compo_1;
MyDataTable.compo_2;
MyDataTable.compo_3;
Итак, мои вопросы: как это возможно, что Microsoft приняла это как допустимое имя столбца SQL? Является ли это частью стандарта SQL или специфично для SQL Server? Что может быть правильным положительным использованием пробела в именах моих столбцов?
Вы можете делать гораздо более странные вещи в именах таблиц, пока объект находится в квадратных скобках. Вы можете использовать пробелы, перевод строки или любой другой непечатаемый символ. Он даже примет символ (0). Я думаю, что это скорее случайная функция, чем специально разработанная.
Не по теме. Никто, кроме оригинальных разработчиков tsql (вероятно, из Sybase), не может ответить на этот вопрос. И это не имеет большого значения, не так ли? Это проблема, которую вы создали. Правила для обычные идентификаторы задокументированы и хорошо известны.
Честно говоря, я не ожидаю правильного ответа или людей, которые просят закрыть тему, потому что она считается в основном основанной на мнении, не по теме, неясной или похожей. Я ожидаю, что смогу сказать: «Нет причин, по которым они это сделали, и лучше никогда не использовать пространство пользователя и специальный символ в имени этого столбца»
Начало ответа здесь: связь "Я понимаю необходимость создания столбцов с пробелами в них, особенно для отчетов, с которыми будут взаимодействовать пользователи, не очень удобно иметь заголовок столбца, помеченный как «Client_Response_Status_Code»." Но я хотел бы найти четкий ответ от таких госпож, как вы.