tolemaC decia:
> Mi opinión es que si partimos del hecho de que las palabras reservadas
> son "reservadas" y no hay que usarlas, entiendo que el comportamiento
> por defecto debería ser el que es.

Hola tolemaC: Has dado en el clavo, es justamente la asunción de esa
premisa la que pretendo cuestionar.

Desde mi punto de vista, esa premisa es innecesaria, y hasta
contraproducente. Me explico:

Cuando diseñamos un modelo conceptual o un modelo de objetos, los
nombres de las cosas deberían ser aquellos que más significativos nos
resulten para lo que vamos a describir. Estoy asumiendo que primero
diseño mi sistema y después selecciono la mejor tecnología disponible
para persistirlo.

En este contexto, si tenemos la suerte de que el atributo (finalmente
columna) que queremos diseñar se llama azarosamente "Clave" no
tendremos problemas, pero si se llama "Key" es posible que plantee
problemas en aquellos motores de SQL que hayan decidido que Key es
para ellos una palabra reservada. Dado que no todos los dialectos de
SQL consideran las mismas palabras como reservadas, razonar de este
modo nos lleva a cohibirnos a priori y no poder usar nombres
significativos a los conceptos antes de ver si fallarán o no por estar
reservados (una forma de auto-censura, llamemosla así).

El asunto se agrava si diseñamos un modelo de objetos que pueda ser
persisitido en diversos motores de bases de datos. No solo hay que
protegerse contra las palabras reservadas de un motor de persistencia,
sino de todos aquellos imaginables posibles o futuros, y eso es muy
dificil.

En definitiva, ¿si NH nos proporciona independicia del motor de
persistencia, porque quedarnos a mitad camino y no independizarnos de
sus keywords?

Un saludo,
Pedro J.

-- 
Para escribir al Grupo, hágalo a esta dirección: 
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano

Responder a