Recientemente le pregunté a un colega por qué habían incluido _TABLE al final de todos los nombres de tablas de la base de datos. Dijeron que había sido un estándar en otra orgainisation para la que habían trabajado. Otros colegas usan V_ al comienzo de las vistas.
¿Es esta una buena práctica?Nombrar tablas y vistas de bases de datos
La consistencia es el mejor enfoque. Agregar un _TABLE o _VIEW al final del nombre de un objeto es excesivo en mi libro, pero si la base de datos está diseñada de esa manera, no me rompería por convención.
Que su colega traiga su convención de nomenclatura de una organización anterior a una nueva sin verificar los estándares "locales" es una mala práctica.
De http://vyaskn.tripod.com/object_naming.htm:
Existen tantas diferentes convenciones de nombres para objetos de base, ninguno de ellos está mal. Es más una preferencia personal de la persona que diseñó la convención de nomenclatura. Sin embargo, en una organización, una persona (o un grupo) define las convenciones de nomenclatura de la base de datos, la estandariza y otras la seguirán, les guste o no.
Lea el artículo full article para obtener detalles sobre cómo implementarlo/crearlo en su organización.
El uso del prefijo v_ o vw_ puede ser útil si lee consultas SELECT a menudo; puede ver rápidamente si está seleccionando desde una vista o tabla. Prefijo de vistas O tablas de postfijación deberían ser suficientes, sin necesidad de ambas. Usamos prefixing de vista.
Además utilizamos un prefijo de "módulo" para agrupar tablas y vistas en torno a un grupo funcional. Por ejemplo, las tablas relacionadas con la facturación se llaman BIL_ * y las vistas relacionadas con la facturación VW_BIL_ *. La denominación del módulo mantiene juntas las tablas y vistas relacionadas entre sí en SSMS.
El uso de v para ver de forma estándar es particularmente malo para mí porque evita utilizar una de las mejores formas de refactorizar una base de datos que es cambiar el nombre de la tabla y crear una vista con el antiguo que imita el anterior estructura para que nada se rompa mientras realiza el cambio pero puede comenzar a encontrar y arreglar todas las referencias antiguas sin tener que arreglarlas todas antes de que el cambio se ponga en marcha.
También estoy de acuerdo con la idea de que el verdadero problema es tomar convenciones de nomenclatura de otra organización e ignorar las convenciones de nomenclatura de la organización actual. Yo pisaría este rápido e insistiría en que cambie todos los objetos y el código asociado a lo que sea que sea su estándar o esto seguirá siendo un problema.
Creo que akf respondió bien a la pregunta. Y HLGEM hace un buen punto acerca de la refactorización.
Sin embargo, agregaría este argumento en contra a tener convención de prefijo/sufijo. En SQL Server (y probablemente en otras bases de datos) no puede tener una tabla y una vista con el mismo nombre en el mismo esquema con el mismo propietario. Es un patrón común crear una vista desnormalizada para una tabla. Si no ha adoptado una convención de nomenclatura que distinga las vistas de las tablas, puede terminar con nombres divertidos para estas vistas, como EMPLOYEE_DENORM en lugar de EMPLOYEE_V.
Si se presenta la necesidad de una refactorización como HLGEM describe, su convención de nomenclatura podría permitir eso. De esta forma, las vistas sin el prefijo o sufijo se identifican fácilmente como vistas de "refactorización".
Prefiero nombrar mis tablas en todos los camelCase, así como los nombres de los campos. Por ejemplo...
CREATE TABLE [crm].[company]
(
[id] INT NOT NULL PRIMARY KEY,
[companyName] NVARCHAR(255) NOT NULL
)
Y para las vistas, les antepongo la palabra "ver". Por ejemplo ...
CREATE VIEW [crm].[viewFullEmployee]
AS SELECT e.id, e.companyId, e.niceId, e.startDate, e.fullPart, p.firstName, p.middleName, p.lastName, p.active, p.birthDate, p.email, p.alternateEmail, p.phone, p.phoneExt, p.homePhone, p.mobilePhone, p.jobTitle, p.suffix, p.prefix FROM [crm].[Employee] as e FULL JOIN [crm].[person] as p on e.id = p.id
también dividir todo hacia esquemas y yo no utilizan el esquema predeterminado, me obliga a especificar siempre un esquema de las cosas en mis consultas, no hay nada en DBO.
Sé que algo es una tabla por falta de la vista de palabra en frente de ella. Esto también evita tener una tabla y una vista con el mismo nombre.
No me gusta usar caracteres de subrayado como "employee_v" porque genero todo el código de mi capa de datos con las plantillas T4 "PetaPoco" y no me gusta tener que escribir _ en mi código cuando me refiero a un tipo.
me gusta esto mejor
var person = uow.Db.Fetch<Models.viewFullEmployee>("SELECT * FROM [crm].[viewFullEmployee]");
vs
var person = uow.Db.Fetch<Models.fullEmployee_V>("SELECT * FROM [crm].[fullEmployee_V]");
En cuanto a los procedimientos almacenados que siento que no necesitan prefijos como "sp_" que veo tantas personas lo hacen. Usted sabe que es un procedimiento almacenado en uso debido al prefijo de EXEC, o Crear Procedimiento, o Alterar Procedimiento. Como tal, nombro mis procedimientos almacenados como "addUpdatePerson", "getUserPermissions", etc.
Donde uso un prefijo está en funciones, como "fnValidateEmail" ya que pueden entrar en conflicto con los nombres de procedimientos almacenados.
+1 para el comentario sobre tomar convenciones de nomenclatura ... se frustra el propósito si se terminan con convenciones de nomenclatura múltiples en una base de datos – Andomar