Se muestran 3 comentarios sin revisar

Antonio	04/11/05
A veces, sobre todo para tablas cuya especifación acerca de los campos puede variar, como clientes, etc. aporta ventajas crear tablas con datos genericos. Por ejemplo, podemos crear una tabla de valores ENTEROS (integer), con un valor que puede ser un char(2) para identificar grupos de valores y dos campos mas que nos indiquen un valor ajeno de clave primaria y otro de valor de dato. Viola casi todas las normas de diseño, pero personalmente he de deciros que en algunos casos es muy práctico. Por ejemplo. Create table params(param char(3), descrip char(30); insert into params values('ES','Idioma español'); Create table valores(param char(2), valor integer, valor2 integer)
Util | Inutil

Juan Pablo Touron	03/12/07
todo bien, pero ojo, esto solo funciona en ADO 2.8 para arriba o en SQL server 2000. Para usar el LIKE en ADO 2.7 para abajo deben cambiarse los comodines '%' por los comodines '*' (asteriscos). De no hacerlo el LIKE funcionara buscando un STRING que contenga el % Ejemplos: BUSCA TODO LO Q TENGA H EN Mi_Campo en ADO <= 2.7 SELECT * FROM Mi_Tabla WHERE Mi_Campo LIKE '*H*' BUSCA TODO LO Q TENGA H EN Mi_Campo en ADO >= 2.8 y SQL SERVER SELECT * FROM Mi_Tabla WHERE Mi_Campo LIKE '%H%' Espero les sea util, estos cambios estan muy mal documentados en las referencias de MSDN y demas, y realemente rompen mucho la paciencia... NUNCA SUPE POR QUE HACEN ESTAS COSAS...
Util | Inutil

Aptiliux	03/3/08
lo primero, si la consulta que se está haciendo es realmente lenta, es desglosarla para ver en que parte de la consulta se encuentra la mayor lentitud, luego de identificarlo, probar si con un índice optimizas el tiempo de respuesta, si a mejorado pero la diferencia es muy poca, puedes utilizar consultas anidadas para definir el orden en el que el manejador realizaría la consulta, los niveles mas profundos se ejecutan primero, entonces debemos comenzar a limitar el volumen de data en estos niveles, e intentar dejar la consulta mas lenta para el nivel mas alto, pues en teoría debería haber menos data en esos niveles. Un modelo anidado de selects me funcionó en una consulta larga que la base de comparación eran fecha. No me gusta mucho utilizar joins pues la consulta es menos legible, pero es bueno saber que es mas rápido.
Util | Inutil

	Ver el articulo y todos sus comentarios
	Añadir un comentario del artículo

  Ir arriba