¿Por qué prefijo nombres de funciones sql?

Question

¿Cuál es un escenario que ejemplifica una buena razón para usar prefijos, como fn_GetName, en nombres de funciones en SQL Server? Parecería que sería innecesario ya que generalmente el contexto de su uso dejaría en claro que es una función. No he utilizado ningún otro lenguaje que haya necesitado prefijos en las funciones, y no puedo pensar en un buen escenario que muestre por qué SQL es diferente.

Mi único pensamiento es que quizás en IDE anteriores era útil para agrupar funciones juntas cuando los objetos de la base de datos estaban todos juntos, pero los IDE modernos ya dejan en claro qué es una función.

Answer 1

estás en lo correcto acerca de los IDE de más edad

Como DBA, tratando de corregir los permisos utilizando Administrador corporativo de SQL Server (SQL Server 2000 y 7.0), que era completa cabrón tratando de ver los permisos. Si tenía ufn o usp o vw, era más fácil agrupar elementos debido a la forma en que la GUI presentaba los datos.

Diciendo eso, si tiene SELECT * FROM Thing, ¿qué es Thing? Una vista o una mesa? Puede funcionar para usted como desarrollador, pero se bloqueará cuando se implemente porque no otorga permisos en la tabla en sí: solo vistas o procesos. Seguramente un vwThing mantendrá su presión arterial baja ...?

Si usa esquemas, se vuelve irrelevante. Puedes "espacios de nombres" para tus objetos.Por ejemplo, las tablas de "Datos" y otros objetos por cliente en otros esquemas, por ejemplo, WebGUI

Editar:

función. Tiene funciones escalares y de valores de tabla. Si te apegas al concepto de código "VerbNoun", ¿cómo sabes cuál es cuál sin otra pista? (Por supuesto, esto no puede suceder porque los nombres de objetos son únicos)

SELECT dbo.GetName() FROM MyTable 
SELECT * FROM dbo.GetName() 

Si utiliza un espacio plural para significar una función con valores de tabla, podría decirse que es peor

SELECT dbo.GetName() FROM MyTable 
SELECT * FROM dbo.GetNames() 

Mientras que esto es menos ambigua , aunque ofensivo para algunas personas ;-)

SELECT dbo.sfnGetName() FROM MyTable 
SELECT * FROM dbo.tfnGetName() 

Con esquemas. Y no hay ambigüedad de nombre.

SELECT ScalarFN.GetName() FROM MyTable 
SELECT * FROM TableFN.GetName() 

Su comentario de "cualquier otro idioma" no se aplica. SQL no está estructurado como C#, Java, f #, Ada (OK, PL/SQL podría ser), VBA, lo que sea: no hay ningún objeto o jerarquía de espacio de nombres. No Object.DoStuff cosas de método.

Un prefijo puede ser justo lo que mantendrá sano ...

Answer 2

No hay necesidad de prefijar los nombres de las funciones con fn_ más de lo que hay una necesidad de prefijar los nombres de las tablas con t_ (una convención que he visto). Este tipo de prefijo sistemático tiende a ser utilizado por personas que todavía no se sienten cómodas con el idioma y que necesitan la convención como una ayuda adicional para comprender el código.

Answer 3

No soy partidario de los prefijos, pero quizás una ventaja podría ser que estos prefijos fn_ podrían facilitar la identificación de que una función en particular está definida por el usuario, en lugar de incorporada.

Answer 4

¿Qué es un escenario que ejemplifica una buena razón para usar prefijos

no hay ninguno. La gente hace todo tipo de cosas porque siempre lo hacen, y un buen número de malos hábitos se explican con el conocimiento antiguo que está mal durante muchos años.

Answer 5

Tuvimos muchas reuniones dolorosas en nuestra empresa sobre esto. IMO, no necesitamos prefijos en ningún nombre de objeto. Sin embargo, podría hacer un argumento para ponerlos en las vistas, si el nombre de la vista pudiera entrar en conflicto con el nombre de la tabla subyacente.

En cualquier caso, no hay requisitos de SQL para usar prefijos, y francamente, IMO, no tienen ningún valor real.

Answer 6

Una (y la única) ventaja que se me ocurre es que un esquema de prefijo aplicado en consecuencia podría facilitar el uso de intellisense/autocompletar ya que la funcionalidad relacionada se agrupa automáticamente.

Answer 7

Como han notado otros, cualquier escenario que defina puede ser desafiado fácilmente, por lo que no hay ninguna regla que lo defina como necesario; sin embargo, tampoco hay ninguna regla que diga que sea innecesaria. Al igual que todas las convenciones de nombres, es más importante tener un uso constante en lugar de justificación.

Answer 8

Como todas las convenciones de nombres, poco importa lo que la convención es en realidad. Lo que realmente importa es ser consistente. Entonces, incluso si la convención es incorrecta, sigue siendo importante mantenerla por coherencia. Sí, se puede argumentar que si la convención de nomenclatura es incorrecta, entonces debe cambiarse, pero el esfuerzo implica mucho: renombre todos los objetos, cambie el código fuente, todos los procedimientos de mantenimiento, haga que el equipo de desarrollo se comprometa a seguir la nueva convención , haga que todo el personal de soporte y operaciones siga las nuevas reglas, etc. En una organización grande, el esfuerzo por cambiar una convención de nombres bien establecida es sencillamente abrumador.

No sé cuál es su situación, pero debe considerar cuidadosamente antes de proponer una convención de nomenclatura cambiar solo por el bien 'bonito'. No importa cuán mala sea la convención de nomenclatura existente en su organización, es mucho mejor seguirla y mantener la coherencia de los nombres que ignorarla e iniciar la suya propia.

Por supuesto, la mayoría de las veces, la convención de nomenclatura no solo es mala, tampoco se sigue y los nombres son inconsistentes. En ese caso, es una mierda ...

Answer 9

Como recientemente me encontré con esta pregunta, me gustaría añadir el siguiente punto a favor de los prefijos: Imagínese, tiene algún identificador de objeto de alguna tabla del sistema y usted desea determinar si es una función, proceso, vista, etc. Por supuesto, puede ejecutar una prueba para cada tipo, pero es mucho más fácil extraer el prefijo del nombre del objeto y luego actuar sobre eso. Esto se vuelve aún más fácil cuando usa un guión bajo para separar el prefijo del nombre, p. usp_Foo en lugar de uspFoo. En mi humilde opinión no se trata solo de estúpidos IDEs.