Tworzenie nazw tabel, które są zarezerwowanymi słowami/słowami kluczowymi w MS SQL Server

Question

Czy można nazwać moje tabele bazy danych, które są już słowami kluczowymi? W moim przypadku próbuję nazwać tabelę, która będzie trzymać moich użytkowników. Nazwa ta została nazwana Użytkownik, ale jest wyświetlana jako różowy w SQL Server Management Studio, więc zakładam, że jest to istniejąca tabela systemowa lub słowo kluczowe. Dzięki za radę.

Oficjalna lista zarezerwowanych słów kluczowych: Reserved Keywords (Transact-SQL)

Answer 1

powtórzyć ten trzykrotnie:

nie rób tego, nie będę NIE UŻYWAĆ REZERWOWANYCH SŁÓW!

podziękujesz mi!

Answer 2

Można użyć [USER], aby to zrobić. Jeśli to możliwe, użyj nazwy tabeli, która nie jest sprzeczna ze słowem kluczowym, aby uniknąć pomyłek i błędów.

Answer 3

Możesz tworzyć tabele o takiej samej nazwie jak słowa kluczowe. Jeśli "zacytujesz" nazwę tabeli, powinna ona działać. Domyślne cytaty w serwerze SQL są nawiasy kwadratowe []

CREATE TABLE [dbo].[user](
    [id] [bigint] NOT NULL, 
    [name] [varchar](20) NOT NULL 
) ON [PRIMARY] 

Answer 4

Tak, to jest w porządku. W zapytaniach, które można umieścić [i] wokół nazwy tabeli tak, że SQL Server wie, że odnosimy się do stołu - tj

CREATE TABLE [User] ... 
SELECT * FROM [User] 

Answer 5

Jak wspomniano, można to zrobić, cytując nazwisko. Oczywiście powinieneś także zacytować to nazwisko za każdym razem, gdy go przywołasz - uwierz mi, szybko się starzeje.

Na marginesie, tylko dlatego, że kolory syntaktyczne SSMS słowo nie musi oznaczać, że jest to reserved word. Sql może być denerwujące w ten sposób. ;)

Answer 6

Podstawowa zasada dla nazw tabel i kolumn (lub lepszych nazw obiektów w ogóle):

Nie używaj niczego taki sam, lub nawet podobny do, zarezerwowanego słowa. Używaj tylko A-Za-z0-9 i podkreślenia. Zwłaszcza nie używaj spacji. Używaj tylko nazw, które nie wymagają ucieczki, a następnie nie używaj funkcji escaping jako testu ciągłego.

Ty i każdy, kto pracuje z tobą, lub kiedykolwiek będzie pracował nad twoim kodem, nie potrzebujesz żadnego zaostrzenia.

Answer 7

Siedzę w obozie, który mówi, że nazwy stołów powinny być w liczbie mnogiej, więc w twoim przypadku będą to Użytkownicy.

Podoba mi się ta konwencja, ponieważ ma dla mnie sens. Masz kolekcję użytkowników, więc zadzwoń do tego stołu. Dalej w dół, jeśli wyciągniesz pojedynczy wiersz, który może następnie wypełnić obiekt o nazwie Użytkownik.

Jeśli konwencja nakazuje użycie liczby pojedynczej dla nazw tabel używać czegoś innego np .: użytkownika, klienta itp

Zobacz także odpowiedź RacerX głównej!

Jak wcześniej wspomniano, jest całkiem OK, jeśli [Braket] nazwę.

Answer 8

Jak wszyscy inni powiedzieli, nie rób tego; jednak byłem w tej samej łodzi. Mam regułę, która mówi, że wszystkie moje tabele są przechowywane w liczbie pojedynczej. Organizacja nie Organizacje, Aktywa nie są aktywami a PartsCatalog ma wiele części itp.

Cóż, mam tabelę użytkowników, więc jak ją nazwać? Uciekłem z tego [Użytkownik]. Teraz żałuję tej decyzji, ponieważ zawsze zapominam o ucieczce od stołu; jednak nie wymyśliłem jeszcze lepszego imienia: Członek jest czołowym kandydatem.

Answer 9

Dla MS Query, znalazłem podwójne cytaty działa doskonale w kwerendzie.

select T1."Reference" 
from MyTable T1 

Answer 10

Użyj 'apostrof' dla Strings i "cudzysłów" dla nazw kolumn.

Przykład:

INSERT INTO AccountMovement 
("Date", Info) 
VALUES 
('2012/03/17', 'aa'), 
('2012/03/17', 'bb'), 
('2012/03/17', 'cc'), 
('2012/03/17', 'dd') 

Answer 11

nie jest dobry pomysł - z różnych powodów

więcej powodów DLACZEGO NIE 1) Oczywistym możliwy konflikt z nazwami zastrzeżonymi 2) jeżeli w ciągu dwóch lat, które mają być wykonaj globalną zamianę w swoim kodzie, powiedzmy "użytkownik" w polu formularza lub w dowolnym miejscu, w którym jest przykręcany przy użyciu ogólnych nazw 3) Jeśli musisz szukać okazji, które używają "użytkownika" w kodzie - wiesz gdzie to działa (mamy ponad milion linii kodu, zabiłoby nas).

CO ZROBILIŚMY 1) każda nazwa tabeli ma unikalny początek, taki jak O_nnn dla obiektów F_nnn dla danych finansowych ... zastosowaliśmy to samo dla pól takich jak opp_created dla okazji utworzono wcześniej, SUSR_RID dla odniesienia do ID użytkownika w ramach funkcji sprzedaży w porównaniu z OPUSR_RID operacyjne odniesienie do użytkownika ... 2) Oprócz prefiksu używamy tak oczywistych, jak to możliwe nazw, takich jak O_FlightArrivalTime, a nie O_FltAT. Dzisiejsze bazy danych nie wykazują obniżenia wydajności przy dłuższych nazwach. 3) Teraz, gdy używasz OF_FlightArrivalTime jako nazwy Formfield, łatwo znajdziesz to skojarzenie, ale globalne wyszukiwanie O_F ... może znaleźć tylko pole DB, wyszukiwanie OF_F ... pola formularza i _F .... obie.

Answer 12

Zdecydowanie odradzam używanie zastrzeżonego słowa kluczowego, tak jak robisz. Sposób, w jaki została zaprojektowana nasza baza danych, polega na prefiksowaniu nazw obiektów bazy danych, aby zapobiec występowaniu takich zjawisk. Oto na przykład szybka definicja tego, jak utworzyć tabelę "Użytkownik":

CREATE TABLE tblUser 
(
    intUserId INT 
    ,vchUsername VARCHAR(255) 
    ,vchEmailAddress VARCHAR(255) 
    ,bitIsAccountEnabled BIT 
    ,dteUpdated DATETIME 
    ,dteCreated DATETIME 
    ,intUpdateUserId INT 
) 

W ten sposób, gdy piszę zapytania. Nie mam problemu ze zrozumieniem, z jakimi typami danych mam do czynienia. Nie muszę też martwić się zastrzeżonymi słowami kluczowymi w nazwach tabel.