Creación de nombres de tabla que son palabras reservadas/palabras clave en MS SQL Server

Question

¿Está bien nombrar las tablas de mi base de datos que ya son palabras clave? Para mi caso, estoy tratando de nombrar la tabla que mantendrá a mis usuarios. Lo llamé Usuario pero aparece en color rosa en SQL Server Management Studio, por lo que supongo que es una tabla del sistema o palabra clave existente. Gracias por su consejo.

Lista oficial de palabras clave reservadas: Reserved Keywords (Transact-SQL)

Answer 1

repetir esto tres veces:

NO LO HAGA, YO ¡NO UTILICE LAS PALABRAS RESERVADAS!

¡me lo agradecerás!

Answer 2

Puede utilizar [usuario] para hacer esto. Si es posible, use un nombre de tabla que no entre en conflicto con una palabra clave, para evitar confusiones y errores.

Answer 3

Puede crear tablas con el mismo nombre que las palabras clave. Si "cita" el nombre de la tabla, debería funcionar. Las comillas predeterminadas en el servidor SQL son corchetes: []

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

Answer 4

Sí, está bien. En sus consultas, puede poner [y] alrededor de su nombre de la tabla de manera que SQL Server sabe que usted se refiere a una mesa - es decir,

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

Answer 5

Como se mencionó, puede hacerlo citando el nombre. Por supuesto, también tendrá que citar el nombre en cualquier momento que lo haga referencia; créame, se vuelve realmente rápido.

Como nota aparte, el hecho de que la sintaxis de SSMS coloree la palabra no significa necesariamente que sea reserved word. Sql puede ser molesto así. ;)

Answer 6

regla básica para la tabla y columna nombres (o mejores nombres de objetos en general):

no use nada el mismo que, o incluso similar a una palabra reservada. Solo use A-Za-z0-9 y guión bajo. Especialmente no use espacios. Solo use nombres que no requieran escaparse, y luego no use el escape como una prueba perpetua.

Usted, y todas las personas que trabajan con usted, o que alguna vez trabajarán en su código, no necesitan el agravante.

Answer 7

Me siento en el campamento que dice que los nombres de las tablas deben ser plurales, por lo que en su caso serían los Usuarios.

Me gusta esta convención, ya que tiene sentido para mí. Tienes una colección de usuarios, así que llama a tu mesa. Más adelante, si saca una fila individual que podría llenar un objeto llamado Usuario.

Si su convención dicta el uso del singular para los nombres de tabla utilizan algo diferente ej .: miembros, etc. cliente

Véase también la respuesta de racerx!

Como se mencionó anteriormente, está técnicamente bien si [Braket] el nombre.

Answer 8

Como todos los demás han dicho, no hagas esto; sin embargo, yo estaba en el mismo bote. Tengo una regla que dice que todas mis tablas están almacenadas en forma singular. Organización no organizaciones, activos no activos, un catálogo de piezas tiene muchas partes, etc.

Bueno, tengo una tabla de usuario, ¿cómo la llamo? Terminé escapándome [Usuario]. Ahora lamento esa decisión porque siempre me olvido de escapar de la mesa; sin embargo, todavía no he encontrado un nombre mejor: el miembro es el principal candidato.

Answer 9

Para MS Query, he encontrado que las comillas dobles funcionan perfectamente en la consulta.

select T1."Reference" 
from MyTable T1 

Answer 10

Usar la 'comilla simple' para Cuerdas y "doble cita" nombres de columna.

Ejemplo:

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

Answer 11

No

una buena idea - por diversas razones

más razones por NO 1) El posible conflicto obvio con nombres reservados 2) Si en dos años que desea hacer un reemplazo global en su código de decir "usuario" en un campo de formulario o en cualquier lugar que esté atornillado al usar nombres genéricos 3) Si necesita buscar ocasiones que usan "usuario" en su código, ya sabe a dónde va (tenemos más de un millón de líneas de código, nos mataría).

lo que hicimos 1) el nombre de cada tabla tiene un comienzo único como O_nnn para objetos F_nnn de datos de las finanzas ... se aplicó la misma a campos como opp_created para la oportunidad se creó en la fecha, SUSR_RID para hacer referencia a un identificador de usuario dentro de una función de ventas versus OPUSR_RID una referencia operativa para un usuario ... 2) Además del prefijo, utilizamos nombres tan obvios como posibles, como O_FlightArrivalTime y no O_FltAT. Las bases de datos actuales no muestran degradación del rendimiento con nombres más largos. 3) Ahora, cuando se usa OF_FlightArrivalTime como nombre de Formfield, se encuentra fácilmente la asociación, pero una búsqueda global de O_F ... solo encontraría el campo DB, una búsqueda de OF_F ... el campo de formulario y _F .... ambos.

Answer 12

Definitivamente desaconsejaría utilizar una palabra clave reservada como lo está haciendo. La forma en que se ha diseñado nuestra base de datos es prefijando los nombres de los objetos de la base de datos para evitar que ocurra algo como esto. Por ejemplo, aquí está una definición rápida de cómo me gustaría crear una tabla 'Usuario':

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

De esta manera cuando estoy escribiendo consultas. No tengo problemas para entender qué tipos de datos estoy tratando. Tampoco tengo que preocuparme por las palabras clave reservadas en los nombres de tablas.