Можно ли назвать мои таблицы базы данных, которые уже являются ключевыми словами? В моем случае я пытаюсь назвать таблицу, в которой будут храниться мои пользователи. Я назвал его User, но он отображается как розовый в SQL Server Management Studio, поэтому я предполагаю его существующую Системную таблицу или ключевое слово. Спасибо за ваш совет.
Официальный список зарезервированных ключевых слов: Зарезервированные ключевые слова (Transact-SQL)
повторите это три раза:
НЕ ДЕЛАЙТЕ ЭТО, Я НЕ ИСПОЛЬЗУЮТ ЗАПРЕЩЕННЫЕ СЛОВА!
вы поблагодарите меня!
Вы можете создавать таблицы с тем же именем, что и ключевые слова. Если вы "укажете" имя таблицы, она должна работать. Котировки по умолчанию на SQL-сервере заключаются в квадратные скобки: []
CREATE TABLE [dbo].[user](
[id] [bigint] NOT NULL,
[name] [varchar](20) NOT NULL
) ON [PRIMARY]
Да, все в порядке. В ваших запросах вы можете поместить [и] вокруг имени вашей таблицы, чтобы SQL Server знал, что вы ссылаетесь на таблицу - т.е.
CREATE TABLE [User] ...
SELECT * FROM [User]
Вы можете использовать [Пользователь] для этого. Если возможно, используйте имя таблицы, которое не конфликтует с ключевым словом, чтобы избежать путаницы и ошибок.
Используйте для столбцов 'одиночную кавычку для строк и "двойную кавычку для имен столбцов.
Пример:
INSERT INTO AccountMovement
("Date", Info)
VALUES
('2012/03/17', 'aa'),
('2012/03/17', 'bb'),
('2012/03/17', 'cc'),
('2012/03/17', 'dd')
Я сижу в лагере, который говорит, что имена таблиц должны быть множественными, поэтому в вашем случае это будут пользователи.
Мне нравится это соглашение, поскольку оно имеет смысл для меня. У вас есть коллекция пользователей, поэтому позвоните в свою таблицу. Дальше вниз по потоку, если вы вытащите отдельную строку, которая затем может заполнить объект с именем "Пользователь".
Если ваша конвенция диктует использование единственного числа для имен таблиц, используйте что-то другое, например: Member, Client и т.д.
Также см. ответ RacerX!
Как уже упоминалось ранее, это технически нормально, если вы [Бранд] назвали.
В MS Query я обнаружил, что двойные кавычки отлично работают в запросе.
select T1."Reference"
from MyTable T1
Как уже упоминалось, вы можете сделать это, указав имя. Конечно, вам также придется процитировать это имя в любое время, когда вы обратитесь к нему - поверьте мне, он быстро станет старым.
В стороне, просто потому, что цвета синтаксиса SSMS, это слово не обязательно означает зарезервированное слово. Sql может быть так раздражающим.;)
Основное правило для имен таблиц и столбцов (или, лучше, имена объектов):
Не используйте что-либо такое же, что и зарезервированное слово или даже подобное. Используйте только A-Za-z0-9 и подчеркивание. Особенно не используйте пробелы. Используйте только имена, которые не требуют экранирования, а затем не используйте экранирование как вечный тест.
Вы, и каждый, кто работает с вами или когда-либо будет работать над вашим кодом, не нуждается в обострении.
Как сказали все остальные, не делайте этого; однако я был в одной лодке. У меня есть правило, в котором говорится, что все мои таблицы хранятся в единственной форме. Организация, а не организации, Asset not Assets a PartsCatalog имеет много частей и т.д.
Ну, у меня есть таблица User, так что я называю ее? Я закончил тем, что убежал от него [Пользователь]. Теперь я сожалею об этом решении, потому что я всегда забываю избежать стола; однако, я еще не придумал лучшего имени: член является ведущим кандидатом.
Не очень хорошая идея - по разным причинам.
БОЛЬШЕ ПРИЧИН, ПОЧЕМУ НЕ 1) Очевидный возможный конфликт с зарезервированными именами 2) Если через два года вы захотите сделать глобальную замену в своем коде слова "пользователь" в поле формы или в любом месте, где вы были привинчены при использовании общих имен 3) Если вам нужно искать случаи, которые используют "пользователь" в вашем коде, вы знаете, где это происходит (у нас есть более миллиона строк кода, это убьет нас).
ЧТО МЫ 1) каждое имя таблицы имеет уникальный старт, такой как O_nnn для объектов F_nnn для финансовых данных... мы применили то же самое к таким полям, как opp_created для возможности, созданной на дату, SUSR_RID для ссылки на идентификатор пользователя в рамках функции продажи по сравнению с OPUSR_RID оперативной ссылка на пользователя... 2) Помимо префикса мы используем как можно более очевидные имена, такие как O_FlightArrivalTime, а не O_FltAT. Сегодня базы данных не показывают ухудшения производительности с более длинными именами. 3) Теперь, когда вы используете OF_FlightArrivalTime в качестве имени формы, вы легко найдете ассоциацию, но глобальный поиск O_F... будет искать только поле БД, поиск OF_F... поля формы и _F.... оба,
Я бы определенно советовал не использовать зарезервированное ключевое слово, как вы делаете. Способ, которым была разработана наша база данных, - это префикс имен объектов базы данных, чтобы предотвратить подобное событие. Например, вот краткое определение того, как я создаю таблицу "Пользователь":
CREATE TABLE tblUser
(
intUserId INT
,vchUsername VARCHAR(255)
,vchEmailAddress VARCHAR(255)
,bitIsAccountEnabled BIT
,dteUpdated DATETIME
,dteCreated DATETIME
,intUpdateUserId INT
)
Таким образом, когда я пишу запросы. У меня нет проблемы с пониманием того, с какими типами данных я сталкиваюсь. Мне также не нужно беспокоиться о зарезервированных ключевых словах в именах таблиц.