Creazione di nomi tabella che sono parole/parole chiave riservate in MS SQL Server

Question

È giusto denominare le tabelle del mio database che sono già parole chiave? Per il mio caso, sto cercando di dare un nome al tavolo che terrà i miei utenti. L'ho chiamato l'utente ma si presenta come rosa in SQL Server Management Studio, quindi presumo che sia una tabella di sistema o una parola chiave esistente. Grazie per il tuo consiglio.

Elenco ufficiale delle parole chiave riservate: Reserved Keywords (Transact-SQL)

Answer 1

ripetere tre volte:

non lo faccio, lo farò NON USARE LE PAROLE RISERVATE!

mi ringrazierai!

Answer 2

È possibile usare [utente] per fare questo. Se possibile, utilizzare un nome di tabella che non sia in conflitto con una parola chiave, per evitare confusione e bug.

Answer 3

È possibile creare tabelle con lo stesso nome delle parole chiave. Se si "cita" il nome della tabella dovrebbe funzionare. Le virgolette predefinite nel server SQL sono parentesi quadre: []

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

Answer 4

Sì, è ok. Nelle query, si può mettere [e] attorno al nome della tabella in modo che SQL Server sa si fa riferimento a una tabella - cioè

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

Answer 5

Come già detto, puoi farlo citando il nome. Naturalmente, dovrai anche citare il nome ogni volta che lo fai riferimento: fidati, diventa molto veloce.

Per inciso, solo perché la sintassi SSMS colora la parola non significa necessariamente che sia una reserved word. Sql può essere fastidioso in questo modo. ;)

Answer 6

regola di base per i nomi di tabella e di colonna (o nomi degli oggetti migliori in generale):

Non utilizzare nulla lo stesso, o anche simile, una parola riservata. Utilizzare solo A-Za-z0-9 e carattere di sottolineatura. Soprattutto non usare spazi. Utilizza solo nomi che non richiedono l'escaping e quindi non utilizzare l'escaping come test perpetuo.

Tu e chiunque lavori con voi o lavorerete mai al vostro codice, non è necessario il peggioramento.

Answer 7

Mi siedo nel campo che dice che i nomi delle tabelle dovrebbero essere plurali, quindi nel tuo caso sarebbe Utenti.

Mi piace questa convenzione perché ha senso per me. Hai una collezione di utenti quindi chiama la tua tabella. Ulteriore downstream se si estrae una riga indiduale che potrebbe quindi popolare un oggetto denominato User.

Se la convenzione impone l'uso di singolare per i nomi delle tabelle utilizzare qualcosa di diverso ad es .: Utente, Cliente ecc

vedere anche la risposta di RacerX!

Come accennato in precedenza è tecnicamente OK se si [Braket] il nome.

Answer 8

Come tutti gli altri hanno detto non farlo; tuttavia, ero nella stessa barca. Ho una regola che dice che tutte le mie tabelle sono archiviate in forma singolare. Organizzazione non organizzazione, asset non beni un PartsCatalog ha molte parti ecc.

Bene, ho una tabella utenti, quindi come la chiamo? Ho finito per sfuggirgli [utente]. Ora rimpiango questa decisione perché mi dimentico sempre di scappare dal tavolo; tuttavia, non ho ancora trovato un nome migliore: il membro è il candidato principale.

Answer 9

Per MS Query, ho trovato che le virgolette funzionano perfettamente nella Query.

select T1."Reference" 
from MyTable T1 

Answer 10

Utilizzare il 'apice singolo' per Archi e "virgolette" per i nomi delle colonne.

Esempio:

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

Answer 11

Non è una buona idea - per varie buone ragioni

più motivi per cui NON 1) Il possibile conflitto evidente con nomi riservati 2) Se in due anni che si desidera fai un rimpiazzo globale nel tuo codice di "utente" in un campo modulo o ovunque ti trovi fregato quando usi nomi generici 3) Se hai bisogno di cercare occasioni che usano "utente" nel tuo codice - sai dove va (abbiamo oltre un milione di righe di codice, ci ucciderebbe).

quello che abbiamo fatto 1) ogni nome tabella ha un inizio unico come O_nnn per gli oggetti F_nnn per i dati di finanza ... abbiamo applicato lo stesso a campi come opp_created per l'occasione è stato creato alla data, SUSR_RID per fare riferimento a un ID utente all'interno di una funzione di vendita rispetto a OPUSR_RID un riferimento operativo a un utente ... 2) Oltre al prefisso usiamo nomi ovvi come possibili come O_FlightArrivalTime e non O_FltAT. I database di oggi non mostrano degrado delle prestazioni con nomi più lunghi. 3) Ora, quando si usa OF_FlightArrivalTime come nome campo, si trova facilmente l'associazione ma una ricerca globale per O_F ... troverà solo il campo DB, una ricerca per OF_F ... il campo modulo e _F .... entrambi.

Answer 12

Vorrei assolutamente evitare di utilizzare una parola chiave riservata come stai facendo. Il modo in cui il nostro database è stato progettato è il prefisso dei nomi degli oggetti del database per evitare che si verifichi qualcosa di simile. Ad esempio, ecco una definizione rapida per come mi piacerebbe creare un tavolo 'utente':

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

In questo modo quando sto scrivendo query. Non ho alcun problema a capire quali sono i tipi di dati con cui ho a che fare. Non devo nemmeno preoccuparmi delle parole chiave riservate nei nomi delle tabelle.