Estoy viendo algunos videos de Brent Ozar ( como este, por ejemplo ) y sugiere que no prefije las tablas con ‘tbl’o ‘TBL’.

En Internet encontré algunos blogs que dicen que no agrega nada a la documentación, y también que "lleva más tiempo leerlo".

Preguntas y consideraciones

• ¿Es esto realmente un problema? Porque estoy prefijando tablas con 'tbl' desde mi primer trabajo en dba (el DBA senior me dijo que hiciera eso para la organización).
• ¿Es algo de lo que necesito deshacerme? Hice algunas pruebas, copié una tabla realmente grande y le di el prefijo 'tbl', mientras mantenía la otra sin ella, y no noté ningún problema de rendimiento.

Una vez tuve una mesa y era brillante y hermosa. Llevaba a cabo todas las transacciones financieras para una organización. Y luego comenzamos a cargar datos en él.

En el mes actual, pueden establecer y reexpresar los valores tantas veces como lo deseen. En los últimos 10 días de un mes, reexpresarían los números -> ejecutarían el procesamiento ETL -> revisarían los informes varias veces al día. Una vez que se completa el mes, los libros se sellan y no pueden modificar los valores.

Es sorprendente la cantidad de datos financieros que genera una empresa de servicios financieros ... Algo que no sabíamos con nuestro conjunto de datos de prueba era que el volumen de datos haría insostenibles sus procedimientos de fin de mes. Tomó cada vez más tiempo eliminar los "datos del mes actual" antes de reemplazarlos con la nueva ejecución de prueba.

Tuvimos que hacer algo para acelerar el procesamiento sin romper la lista no catalogada de "quién sabe qué", todo eso depende de la tabla de asignación mensual. Decidí jugar al mago y sacar el mantel de debajo de ellos. Fui a la vieja escuela y usé una Vista Particionada . Los datos ya tenían un indicador IsComplete, así que hice dos tablas, cada una con restricciones de verificación contrarias: MonthlyAllocationComplete, MonthlyAllocationInComplete

Luego creé la vista particionada con el mismo nombre que la tabla original: Asignación mensual. Ningún proceso fue más sabio sobre el cambio físico que hicimos en la base de datos. No hubo informes rotos, ninguno de los analistas con acceso directo informó problemas con esa "tabla" antes o después.

Buena historia hermano, pero ¿a dónde vas?

¿Qué pasaría si tuvieran una convención de nomenclatura allí, tbl_MonthlyAllocation? ¿Ahora que? ¿Pasamos muchas horas de trabajo revisando cada ETL, cada informe, cada hoja de cálculo ad-hoc en la organización y actualizándolos para usar vw_MonthlyAllocation? Y luego, por supuesto, todos esos cambios pasan por el tablero de cambios y ese siempre es un proceso rápido e indoloro.

Su jefe podría preguntar: ¿Cuál es la recompensa para la empresa por todo ese trabajo nuevamente?

La otra opción es que dejamos esta vista llamada tbl_ y no pasamos todo ese tiempo probando, actualizando e implementando código. Lo que se convierte en una anécdota divertida que usted explica a todos los nuevos empleados, y aquellos con breves períodos de atención, que tienen que trabajar con la base de datos en cuanto a por qué es inconsistente con la denominación de los objetos.

O no codifica doblemente objetos con metadatos redundantes. La base de datos le dirá qué es una tabla, qué es una vista, qué es una función con valores de tabla, etc.

Las convenciones de nombres son buenas, simplemente no te pintes en una esquina con ellas.

Brent aquí (el tipo al que te refieres en la pregunta).

La razón por la que le digo que no agregue tbl al frente de los nombres de su tabla es la misma razón por la que yo diría que no agregue child al frente del nombre de su hijo. No los llamas childJohn y childJane. No solo no agrega ningún valor, sino que pueden no ser un niño más adelante en la vida, y sus objetos pueden convertirse en vistas.

Este es un argumento muy subjetivo, pero aquí está mi opinión: el prefijo tbl es inútil.

¿En cuántos escenarios está mirando el código y no puede saber si algo es una tabla u otra cosa?

¿Qué valor agrega tbl, excepto que cuando mira una lista de tablas en Object Explorer, tiene que hacer más trabajo para encontrar la (s) que está buscando?

Algunas personas dicen que quieren que quede claro en su código cuando se trata de una tabla o una vista. ¿Por qué? Y si esto es importante, ¿por qué no solo nombrar vistas de una manera especial? En la mayoría de los casos, actúan como tablas, por lo que veo poco valor en distinguir.

Es una práctica terrible.

tbl
tbl_
Table_
t_

... los vi a todos en producción.

Uno de los productos con los que estoy trabajando actualmente tiene la mitad de las tablas nombradas tbl_whatever, y la otra mitad llamada "normalmente". Obviamente tienen desarrolladores que están trabajando con diferentes estándares. Otro de sus malos hábitos es prefijar los nombres de las columnas con claves foráneas fk, seguidos del nombre de la tabla, fkluego el nombre de la columna, dando nombres de columna tan horribles como fktbl_AlarmsfkAlarmsID. Esa convención de nomenclatura es solo una extensión lógica de todo el tbl_%mantra, ¡y puedes ver lo ridículo que se vuelve!

Casi me olvido de la otra base de datos que me hace llorar a diario. Tipos de datos con prefijos de nombres de columnas ... dtPaymentDate, porque el nombre realmente necesitaba el dtprefijo?

no verifique escuchar el prepTo adjTose esos adjuntos otros nouPeople. ProYou auxDebe siempre verUse nouPrefixes prepWith proYour adjTable nouNames. PROI AUXILIAR HAY AVISO INCLUSO COMIENZO DEL PROYECTO DE PREPARACIÓN AJUSTE NORMAL NORMAL.

COMPRUEBE AVISO ¿CÓMO VERDADERAS PRUEBAS ADECUADAS? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

El uso de un prefijo como este se conoce como notación húngara . Su premisa es simple: puede determinar qué es algo por su nombre. Esto es particularmente común en los lenguajes de programación, especialmente cuando los desarrolladores escriben funciones monolíticas que abarcan docenas de páginas, ya sea por falta de habilidad o por falta de características del lenguaje. Es una ayuda mnemónica que ayuda a los desarrolladores a mantener los tipos de datos correctos.

En términos generales, es probable que este estilo de nomenclatura se use en códigos muy antiguos, o por desarrolladores que simplemente están aprendiendo (y aprendieron este hábito), o lo han estado haciendo desde que tienen memoria. En mi experiencia, he observado que es relativamente raro ver la notación húngara surgir espontáneamente con desarrolladores inexpertos si no se les presenta en un curso de programación o tutorial; son más propensos a usar nombres de variables como i o x o acct .

Además de pintarte en una esquina, esto es realmente solo relleno. La sintaxis SQL es lo suficientemente precisa como para que un desarrollador siempre sepa si está hablando de un campo, registro o conjunto de datos (que puede ser una tabla, vista, etc.). Si bien puede ser una gran ayuda para la enseñanza, esta sintaxis generalmente no debería existir en las bases de datos de producción. Puede dañar la legibilidad, y hacer que sea más difícil encontrar la tabla que está buscando, sobre todo si varios temas de nomenclatura alternativa pop-up, como TBL vs. mesa frente pestaña , etc.

A la base de datos realmente no le importa lo que llame sus tablas, campos, etc. Son solo bytes de datos que están organizados en un orden particular por sus operadores humanos o scripts. Sin embargo, los humanos que tienen que mantener estos datos apreciarán nombres significativos, como "usuario", "orden" y "cuenta". También es más práctico si está utilizando consultas SQL, como "mostrar tabla como 'a%'". El uso de prefijos y sufijos puede complicar innecesariamente el mantenimiento trivial.

He leído algunas publicaciones de blog como esta o esta (hay bastantes) después de que heredé mi primera instancia de SQL Server y noté que muchos objetos tenían prefijos, quería comenzar a desarrollar otros nuevos con un enfoque menos detallado y una convención de nomenclatura singular ( es mucho más fácil para mí [ y posiblemente otros desarrolladores ] trabajar en el mapeo relacional de objetos).

Uno de los prefijos más utilizados fue Tblo tbl, pero luego tuve TBLe tbl_e incluso*TableName*_Tbl

Al tratar de consultar y trabajar desde Visual Studio, esto es simplemente un infierno, no me importaría tener un conjunto completo de tablas con prefijo, tblpero al menos manténgalo así para toda la base de datos.

Así que al final definitivamente diría que es una cuestión de preferencia personal, pero también tiene mucho que ver con la coherencia y si sigues ese camino, mucha gente estará feliz de que al menos lo mantengas igual a lo largo de tu desarrollo.

... Por otro lado, solo quería decir, si adoptas otro enfoque y buscas una tabla de nombre singular sin prefijo, harás feliz a un desarrollador en el futuro, y ¿qué es más importante que la felicidad?

Sí, agregar un prefijo que denote el tipo de objeto es un problema e innecesario . Porque,

1. A veces, los objetos comienzan la vida como algo, pero terminan convirtiéndose en otra cosa . (por ejemplo, la tabla tblXxxse dividió en tblXxxYy tblXxxZpor alguna razón y se reemplazó con una vista que une las dos tablas nuevas. Ahora tiene una vista llamada tblXxx).
2. Cuando escribe tblen el editor, su función Autocompletar se bloquea durante 45 segundos y luego le muestra una lista de 4000 entradas.

Pero...

Voy a hacer de abogado del diablo y decir algo que otros han desaconsejado. Hay algunos casos raros en que un sufijo / prefijo podría ser útil, y aquí hay un ejemplo de la organización para la que trabajo.

Tenemos un sistema ERP basado en entidades, donde la lógica de negocios está escrita en Oracle PL / SQL. Tiene casi dos décadas de antigüedad, pero es un sistema muy estable (este no es un sistema heredado. Lo estamos desarrollando continuamente).

El sistema está basado en entidades, y cada entidad asocia una tabla, múltiples vistas, múltiples paquetes PL / SQL y una gran cantidad de otros objetos de base de datos.

Ahora, queremos que los objetos que pertenecen a la misma entidad tengan el mismo nombre pero que sean distinguibles de su propósito y tipo. Entonces, si tenemos dos entidades que se nombran CustomerOrdery CustomerInvoice, tendremos los siguientes objetos:

1. Tablas para almacenar datos [ TABsufijo]:
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. Vistas que utilizan los clientes [Sin sufijo]:
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. Interfaz para operaciones básicas; (Paquetes PL / SQL) [ APIsufijo]:
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. Generadores de informes; (Paquetes PL / SQL) [ RPIsufijo]:
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. Índices para claves primarias [ PKsufijo]:
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. Índices secundarios [ IXsufijo]:
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(donde XXXdescribe el uso del índice).
7. ... y así.

De hecho, esta es una forma de aplicaciones húngaras (tenga en cuenta que el mismo tipo de objetos puede tener sufijos diferentes según el propósito). Pero, con un sufijo en lugar de un prefijo. No puedo decirte lo suficiente cómo este sistema es tan fácil de leer. IntelliSense realmente funciona porque en lugar de escribir TBLy obtener 4000 resultados, puedo escribir Customery obtener todos los objetos que pertenecen a las entidades nombradas Customer*.

Entonces, aquí te he mostrado cómo los metadatos pueden ser útiles. El propósito es tener un conjunto relacionado de objetos de base de datos identificables por un solo nombre, pero diferenciarlos según su propósito .

Una vez dicho esto, si no tienes este tipo de sistema, no hay uso de prefijos o sufijos para el tipo de objeto .

Tenga en cuenta que no hemos utilizado sufijos como _table, _package, o _view(es decir, el tipo del objeto). Por ejemplo, ambos (3) y (4) son paquetes PL / SQL, pero usan un sufijo diferente. Es lo mismo para (5) y (6), los cuales son índices. Por lo tanto, el sufijo se basa en el propósito en lugar del tipo .

tl; dr It (muy probablemente) agrega información redundante, lo que lleva a una sobrecarga cognitiva y, por lo tanto, debe eliminarse.

El contexto es algo maravilloso, especialmente en los sistemas informáticos. Fuera de contexto, no podría saber si algo llamado userses una tabla, una vista, un procedimiento almacenado o algo completamente diferente. Los sistemas y lenguajes heredados (o simplemente mal escritos) a menudo dificultan la elaboración del contexto mientras se lee el código. Por ejemplo, en Bash, no se puede saber qué function usershace sin al menos leer el contenido de la función. En Java, Map<Uid,UserDetails> users()es bastante transparente, y puede profundizar en los detalles fácilmente.

Llevando este argumento a las tablas SQL, ¿ cuándo sería útil para los consumidores userssaber si es una tabla o una vista? En otras palabras, ¿un tblprefijo le dirá a alguno de los consumidores algo que no saben y necesitan saber?Esperemos que la gran mayoría de los consumidores escriban consultas DML y DQL en su contra. Para ellos, debería ser solo otra fuente de datos, y si es una vista o una tabla, debería ser tan relevante como si está particionada, almacenada en HDD o SSD, o cualquier otro detalle técnico. El DBA, por supuesto, necesita conocer estos detalles para ejecutar algunas consultas DDL / DCL raras, pero parece contraproducente contaminar el espacio de nombres por el bien de la minoría que realmente sabe cómo navegar por el esquema y obtener todos los detalles técnicos.

Una de las características de un sistema de gestión de bases de datos relacionales es que separa la presentación lógica de la información a los clientes del almacenamiento físico. El primero es columnas en un conjunto de filas. Este último es como archivos en un volumen de almacenamiento. Es el trabajo del DBMS mapear uno a otro. Solo preocupa al DBA o al administrador del sistema qué hardware admite la necesidad de información. El consumidor no necesita, de hecho no debería, ser consciente de esas preocupaciones.

El cliente tampoco debe preocuparse por cómo se construye un conjunto de filas. Una tabla base, una vista o una función son todas, a este respecto, idénticas. Cada uno simplemente produce un conjunto de filas y columnas que el cliente consume. Incluso un escalar simple puede considerarse una tabla de una fila y una columna. El modelo de fila / columna es el contrato entre el cliente y el servidor.

Al prefijar los nombres de los artefactos con su tipo de implementación, esta separación de preocupaciones se rompe. El cliente ahora conoce y depende de los componentes internos del servidor. El cambio en la codificación del servidor puede requerir que el cliente vuelva a trabajar.

Hay muchas respuestas aquí con las que estoy de acuerdo que le dicen que esta no es una convención de nomenclatura muy valiosa. Para aquellas personas que no están convencidas por las otras respuestas, voy a tratar de demostrar lo que dicen muchas otras respuestas.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

En la declaración anterior, estoy seleccionando tres columnas de algo llamado dbo.foo. Una de las principales quejas de los prefijos es que no saben si dbo.fooes una tabla o una vista. Por supuesto, esa es una de las fortalezas de una visión como abstracción, pero estoy divagando. Dicen que debemos prefijar el objeto así dbo.tblFoo. Ahora pueden ver que el objeto es una tabla (probablemente) en la consulta anterior. Sin embargo, si escribimos el equivalente funcional de ese objetivo, se vería así.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

Sospecho que el comentario parece menos útil, aunque eso es lo que los prefijos argumentan efectivamente. Para resaltar el ruido inútil que este comentario de metadatos inyecta considera una consulta más complicada.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

¿Los comentarios adicionales hacen que esa consulta sea más fácil de razonar o simplemente agregan ruido adicional? En mi opinión, solo agregan ruido adicional y agregan valor cero. Eso es lo que los anti-prefijos están tratando de decir. Además, el uso de prefijos es en realidad peor que esos comentarios porque el costo de actualizar un comentario es mucho más bajo que actualizar el nombre de una tabla con prefijo si su modelo de datos necesita ser adaptado. Como estos prefijos tienen un costo y no imparten información valiosa, deben evitarse.

Otra ventaja de los prefijos que algunas personas citan es que puede impartir algún tipo de agrupación u ordenamiento en su entorno de desarrollo. Dado que pasamos una gran cantidad de tiempo editando código, esto puede ser un argumento seductor para algunos. Sin embargo, en mi experiencia, los entornos de desarrollo modernos ofrecen opciones equivalentes o superiores que no ensucian su código con metadatos inútiles y limitan su flexibilidad.

Esto ha sido cubierto muchas veces, pero probablemente el más famoso por Joe Celko , un experto estadounidense en SQL y bases de datos relacionales. Personalmente he estado en el lado receptor de uno de sus comentarios en línea (me sentí honrado), y él habla de estos prefijos como "tibbling", o más exactamente descrito como " skeuomorphism ".

La idea general es que estos prefijos son una práctica de codificación de hace mucho tiempo (probablemente debido a limitaciones de nomenclatura, como un límite de 8 bytes para los nombres de objetos), transmitidos a generaciones de programadores sin una razón aparentemente útil, aparte de que es "la forma se hace".

Las empresas, los blogueros y los programadores transmiten información con su propio estilo de codificación, y algunos estilos pueden ser un poco más "Frankenstein" que otros. Una empresa puede tener un "estilo de casa", y el programador se ve obligado a aprender esta práctica.

Con el tiempo, las cosas se mantienen, incluso si la razón por la que se usaron originalmente ahora está en desuso. "Tibbling" es uno de los ejemplos más conocidos de esto en la gestión de bases de datos relacionales.

Para redondear: no agrega ningún valor, agrega exactamente 4 bytes de espacio de almacenamiento en cada nombre de tabla sin más razón que porque está allí. No ofrece nada a los sistemas modernos de SQL Server, pero si te hace sentir mejor tenerlo allí, adelante, úsalo.

Mi sugerencia sería que dejes de hacer esto de inmediato. Si esto le incomoda en el futuro, agregue "_tbl" al final de los nombres de las tablas. Por supuesto, por las razones ya mencionadas, tampoco hay necesidad de hacerlo. La persona que originalmente te dijo que hicieras eso te dio algunos malos consejos. Puede haber sido malo "esto tiene sentido en términos del consejo del sistema mal configurado de nuestra organización", pero en ese caso era su trabajo arreglarlo. Sigue siendo un mal consejo.

¿Es “No prefijar sus tablas con tbl” realmente un problema?

En cuanto al sistema? No. ¿Con respecto a otras personas? Tal vez. Puedes generar mucho odio.

Yo personalmente no prefijo tablas, pero lo hago en otros objetos como vistas, procedimientos almacenados, funciones, etc.

Tendría que decir que por favor dejen de hacer esto. Ha sucedido en el pasado, pero al continuar haciendo esto, usted alienta a las personas nuevas que vienen a su entorno a pensar que es una convención local y continuar. Pero no solo continuarán, lo harán de manera ligeramente diferente

Al rastrear una base de datos para un elemento específico, y no soy el único que abrirá el explorador de objetos y solo pensaré que me desplazaré hacia él, ya sabes que es alfabético. Eso es hasta que los prefijos comienzan a enturbiar las aguas, y tengo tblname, tbl_name, tbname, t_name y mil otras variaciones, se vuelve realmente difícil encontrar esa tabla que ya sabes que es una tabla

Asimismo, anteponiendo todo vw_ o sp_, alguien entrará y obtendrá SPname, spname, s_p_name. Elimine todos los prefijos, el software sabe cuál es el elemento, si realmente necesita saber, utilice un sufijo en su lugar. NameOfMyView_v, NameOfMyProc_sp. mucho más fácil de buscar visualmente

Pero, ¿qué pasa si estás navegando a través de un proceso almacenado durante mucho tiempo y no puedes decir fácilmente qué es una vista de un proceso o una tabla? Bueno, lo más probable es que estos tengan un alias de todos modos, e incluso si no, el sufijo viene a su rescate

No tengas miedo de cambiar lo que haces, y si entras en un entorno en el que las convenciones de nombres ya se han disparado, no tengas miedo de implementar las tuyas y comenzar a cambiar las cosas para mejor. Al hacer coincidir el caos existente, no hay posibilidad de hacerlo menos confuso, solo hacerlo aún más

Si tengo que pensar en una ventaja de tener el prefijo 'tbl', es que en el SSMS actual, con intellisense, puedo escribir

select * from tbl

y luego encuentre el nombre de la tabla que necesito (suponiendo que no tengo idea sobre el nombre exacto de la tabla). Este es un trabajo de un solo paso. Por supuesto, siempre podemos encontrar el nombre de la tabla a través de pasos adicionales, pero yo diría que con el prefijo 'tbl', este es el trabajo de UN paso, y es por eso que siempre prefiero un prefijo (no necesariamente 'tbl') en mi propio proyecto de tarea.

Editar : (después de tantos votos negativos, todavía creo que vale la pena señalar algunas ventajas de nicho de dar un prefijo específico a una categoría específica de objetos en el servidor SQL). Parece que nadie se queja de tener un prefijo para procedimientos almacenados / funciones / vistas, pero siempre hay argumentos sobre hacerlo con tablas. (Para mí, en el mundo real no me importa si le damos un prefijo o no a las tablas).

Recuerdo que en los días de servidor SQL 2005 había un requisito para encontrar qué tablas se usan en qué procedimientos / vistas almacenados, con los nombres de las tablas prefijados, fue un trabajo tan fácil con Expresión regular / C #. (Sí, sé que había otras formas, no hay discusión aquí).

Mi carrera crece con la lectura de muchos artículos / artículos de "mejores prácticas", pero también he visto suficientes excepciones para casi todas las "mejores prácticas" de una forma u otra en diferentes escenarios. Por lo tanto, siempre me digo a mí mismo y a mis compañeros de DBA, hagamos el juicio de acuerdo con los requisitos del negocio, la "mejor práctica" tiene su lugar seguro, pero solo puede considerarse en el contexto de nuestro propio entorno.

Considere dbo.Uservs dbo.tUser. Ahora imagine que desea encontrar todos los lugares en el código en los que se usa esta tabla. ¿Qué versión hace esto más fácil (o incluso posible?) Es probable que la palabra "usuario" tenga muchos falsos positivos, como nombres de variables, en comentarios, etc.

Eso es algo que no he visto en ninguna de las otras respuestas, pero soy un desarrollador-DBA, por lo que tal vez otros no hayan tenido que trabajar en código heredado, donde las consultas se pueden incrustar en la aplicación, y no todas las consultas califican completamente las referencias con el esquema, y ​​cosas así. (Incluso si todo está totalmente calificado, es necesario encontrar dbo.Usery [dbo].[User]y dbo.[User]y así sucesivamente). O versiones de bases de datos donde la "información de dependencia" se vuelve obsoleta y es inexacta (por ejemplo, versiones anteriores de MS-SQL)

Entonces, en algunos proyectos en los que he trabajado, que se mezclan así, solicité un prefijo to v(tbl_ se vuelve tonto), simplemente para que sea un término de búsqueda más selectivo.

En proyectos posteriores, con cosas como las Herramientas de datos de SQL Server (hola, Buscar todas las referencias) y el acceso a la base de datos exclusivamente a través de una capa ORM, no hay utilidad, porque encontrar todos los usos de la tabla es trivial (¡como cambiarle el nombre!)

Cada lado tiene sus ventajas y sus desventajas. Depende del liderazgo de su equipo o compañía decidir las convenciones a seguir.

Nosotros, por ejemplo, usamos la tblconvención. La razón principal es que sabemos en los scripts lo que podemos y no debemos hacer. Tenemos proyectos variados y personas que se lanzan sin saber el esquema de memoria. Nuestras tablas tienen nombres lógicos, por lo que es fácil encontrar el camino al escribir scripts. Al hacerlo, cuando encontramos una tabla, sabemos de inmediato (a través de IntelliSense) que es una tabla. Se puede argumentar que agregar el prefijo no agrega mucho contexto. Sin embargo, eliminarlo significa que no hay contexto.

La única ventaja real de no usar el prefijo es la intercambiabilidad. Sin embargo, diría que esta es una situación potencialmente peligrosa. Claro, sus scripts y consultas no se romperán, pero tal vez comience a confiar demasiado en ese hecho, mientras que algunas cosas simplemente no funcionan con vistas o son desaconsejadas.

Al final, todo se reduce a lo que su equipo prefiere y cómo escribe código / scripts.

Solía ​​tener una razón para prefijar los nombres de las tablas con "tbl". Si está mirando una lista de objetos de la base de datos, puede ejecutar esta consulta:

select * from sysobjects

Si desea obtener solo tablas, puede hacer esto:

select * from sysobjects where type = 'U'

¿Quién puede recordar eso? Si todos los nombres de la tabla comienzan con "tbl", puede usar esta consulta que no requiere que memorice los valores de la columna de tipo:

select * from sysobjects where name like 'tbl%'

Dado que etiquetó SQL Server 2014, esto no se aplica a usted porque a partir de SQL Server 2005, puede hacer esto en su lugar:

select * from sys.tables

No se me ocurre otra razón para prefijar los nombres de las tablas.