19 replies to this topic

[Yentin]

no soy un gran amante de las UNION pero me las hacen usar para resolver este problema. Yo lo hubiera hecho de otra forma pero bueno. Tengo esta consulta.

SELECT	 RTRIM(dbo.infopdi_PDI.Cognom1) + ' ' + RTRIM(dbo.infopdi_PDI.Cognom2) + ', ' + RTRIM(dbo.infopdi_PDI.Nom) AS NomComplert,
		   dbo.infopdi_PDI.Cip,dbo.Sid_Codis_Nomenclatures_UPC.CodiUnitat, dbo.Sid_Codis_Nomenclatures_UPC.NomUnitat,
		   dbo.infopdi_PDI.Categoria, dbo.infopdi_PDI.DescripcioCategoria,dbo.infopdi_PDI.Periode,
		   dbo.Sid_Codis_Nomenclatures_UPC.CodiTipusUnitat
FROM	   (dbo.infopdi_PDI INNER JOIN dbo.Sid_Codis_Nomenclatures_UPC 
		   ON dbo.infopdi_PDI.CodiDepartament = dbo.Sid_Codis_Nomenclatures_UPC.CodiUnitat)
UNION
SELECT	 Distinct RTRIM(dbo.infopdi_PDI.Cognom1) + ' ' + RTRIM(dbo.infopdi_PDI.Cognom2) + ', ' + RTRIM(dbo.infopdi_PDI.Nom) AS NomComplert,
		   dbo.infopdi_PDI.Cip,B.cen as CodiUnitat, dbo.Sid_Codis_Nomenclatures_UPC.NomUnitat,
		   dbo.infopdi_PDI.Categoria, dbo.infopdi_PDI.DescripcioCategoria,dbo.infopdi_PDI.Periode,
		   dbo.Sid_Codis_Nomenclatures_UPC.CodiTipusUnitat
FROM	   (dbo.infopdi_PDI JOIN pdiCentres B
	   ON dbo.infopdi_PDI.Cip=B.strCip)JOIN dbo.Sid_Codis_Nomenclatures_UPC 
		   ON B.Cen = dbo.Sid_Codis_Nomenclatures_UPC.CodiUnitat

el problema en si es ke la consulta de arriba que es la que existe como vista me relaciona profes con departamentos, pero ahora me piden que la aplicación tb se pueda acceder filtrando por centros, y hay que tocar la vista. La relación de profes con centros está en la vista pdiCentres (bastante tocha), y la idea es que tanto codigos de centro como de departamento esten en la misma columna de nombre CodiUnitat que se saca de la tabla Codis_nomenclaturas.
A priori este Union lo hace pero tarda casi 3 minutos y eso es muuucho pa una web askerosa. Entonces cualquier idea que tengais para optimizar esta tocho consulta fijo que me ayuda, tengo un día mazo de espeso y como siempre que necesito ayuda alguien acaba dandomela aqui la pongo antes de comentarselo al jefe y ke me deje mal XD.
Joer yo con un puto Join relacioné las 3 tablas y añadi una columna de centros, y solo me tardaba 7 segundos (que ya me parecia bastante xD)
Lo dicho que soleis usar pa optimizar en un caso similar a este.

[Frikjan]

Básicamente, no usar unions, las odio. Porque te obligan a usar una union?

[ArmiSael]

Usar correctamente los índices, si es que los tienen esas tablas, y lo mismo que dice Frikjan, evitar unions ^^U

[Salax]

joins

PD; soy dead

Este tema ha sido editado por Salax: 21 April 2006 - 06:18 PM

[Yentin]

guay, si, ya se ke las unions son una puta mierda, Me obligan a usar unions pq el jefe es un teleco ke no tiene ni puta idea, tendrías ke ver como está montado el Data warehouse, yo no he visto más replicación de datos en mi vida XD, caquita de la grande.

La cuestión es que segun el necesita tener los centros y los departamentos en la misma columna. ¿como haceis eso con JOINS? pq si lo sabeis hacer ya taría solucionado, yo como dije lo tengo hecho con joins pero los centros y los departamentos tan en columnas distintas.

[belenjer]

haber compa, por ejemplo: si el campo de los centros es "cen_centro" y la de los departamentos es "dpt_depto" y los 2 son de tipo numerico haz lo siguiente:

Select rtrim(convert(char,cen_centro)) + ' - ' + rtrim(convert(char,dpt_depto)) from CENTROS
inner join DEPARTAMENTOS on CENTROS.clave = DEPARTAMENTO.cen_clave

ojo. tienes que ver cuales son las clvaes FK y PK para poder relacionarlas, la tabla de departamentos tiene que tener una FK a la tabla de centros o viceversa.

[kebrantador]

a ver, ahí si he entendido bien el problema, no te queda más cojones que hacer un union, ya que lo que te piden es que devuelvas en una misma columna CodUnitat datos de dos columnas distintas (bueno, en realidad es la misma, pero de dos consultas distintas, una por centro y otra por departamento).

Entiendo que lo que ha puesto belenjer no te sirve, ya que eso es devolver en la columna CodUnitat Los dos datos, tanto centro como departamento, concatenados que si no me equivoco no es lo que te piden, sino que te piden que devuelvas o Centro, o Departamento.

LOL, me parece una chapuza impresionante eso... o sea vas a tener algo así si no me equivoco :

Profe1 Dep1 Otra columns...
Profe2 Dep2 Otra columns...
...
Profe1 Centro1 Otra columns...
Profe2 Centro2 Otra columns...

Es una forma chapucera de reutilizar el filtro por la columna CodUnitat para filtrar tanto por filtros como por centros vale... pero es una chapuza. Yo ahí le plantearía a su jefe que no haga esas chapuzas, pero bueno...

En fin, si no te queda más cojones que hacer eso, ahí no te queda más guevos que usar el UNION, y a ver, un UNION tampoco es que sea algo que tenga que tardar mucho de por sí a no ser que manejes muchos datos... , no es más que hacer 2 consultas y juntar los resultados eliminando repetidos, que en este caso no habrá ...

Si ejecutas las consulta 1 y la consulta 2 por separado, te tardan poco ambas? En tal caso el problema es del union sí, pero no sé porque a mi me da que el problema está más bien en la 2ª consulta...

por qué haces el distinct? No veo que esa consulta te tuviera que devolver profesores repetidos ¿hay profesores en varios centros? ¿Cual es la tabla intermedia de la N a N pues? ¿No me jodasque en los centros estan repetidos?

por qué concatenas joins?

No sé, yo suelo ver más claro esta nomenclatura, aparte que los optimizadores internos de las bbdd se suelen aclarar mejor para optimizarlas (no les fuerzas el orden, con lo que ellos eligen que tablas / clausulas elegir antes para filtrar )

FROM dbo.infopdi_PDI PROFES,
		 pdiCentres CENTROS,
		 dbo.Sid_Codis_Nomenclatures_UPC NOMEN
WHERE CENTROS.Cen = NOMEN.CodiUintat
	 AND CENTROS.strCip = PROFES.Cip

En fin, aunque todos te dicen ¡¡¡UNIONS NOOOO!!!, me gustaría ver como alguno te hace esa consulta sin unions ... sinceramente sería muy educativo...

(que yo no defiendo el union que no mola, yo habría devuelto centros y departamentos en columnas distintas, o sea, sola una consulta, y que tu jefe se las apañara xDDD)

[Yentin]

a ver, ahí si he entendido bien el problema, no te queda más cojones que hacer un union, ya que lo que te piden es que devuelvas en una misma columna CodUnitat datos de dos columnas distintas (bueno, en realidad es la misma, pero de dos consultas distintas, una por centro y otra por departamento).

LOL, me parece una chapuza impresionante eso... o sea vas a tener algo así si no me equivoco :

Profe1 Dep1 Otra columns...
Profe2 Dep2 Otra columns...
...
Profe1 Centro1 Otra columns...
Profe2 Centro2 Otra columns...

Es una forma chapucera de reutilizar el filtro por la columna CodUnitat para filtrar tanto por filtros como por centros vale... pero es una chapuza. Yo ahí le plantearía a su jefe que no haga esas chapuzas, pero bueno...

Si ejecutas las consulta 1 y la consulta 2 por separado, te tardan poco ambas? En tal caso el problema es del union sí, pero no sé porque a mi me da que el problema está más bien en la 2ª consulta...

por qué haces el distinct? No veo que esa consulta te tuviera que devolver profesores repetidos ¿hay profesores en varios centros? ¿Cual es la tabla intermedia de la N a N pues? ¿No me jodasque en los centros estan repetidos?

por qué concatenas joins?

No sé, yo suelo ver más claro esta nomenclatura, aparte que los optimizadores internos de las bbdd se suelen aclarar mejor para optimizarlas (no les fuerzas el orden, con lo que ellos eligen que tablas / clausulas elegir antes para filtrar )

FROM dbo.infopdi_PDI PROFES,
		 pdiCentres CENTROS,
		 dbo.Sid_Codis_Nomenclatures_UPC NOMEN
WHERE CENTROS.Cen = NOMEN.CodiUintat
	 AND CENTROS.strCip = PROFES.Cip

En fin, aunque todos te dicen ¡¡¡UNIONS NOOOO!!!, me gustaría ver como alguno te hace esa consulta sin unions ... sinceramente sería muy educativo...

(que yo no defiendo el union que no mola, yo habría devuelto centros y departamentos en columnas distintas, o sea, sola una consulta, y que tu jefe se las apañara xDDD)

si, lo has entendido.
La cuestión es que hay profes que son por ejemplo del departamento 723 pero dan clases en el centro 270 y en el 394.
entonces con mi Union tendré
Prof1 723 resto columnas
Prof1 270 resto columnas
Prof1 394 resto columnas.


vamos ke es una puta chapuza XD, si lo hago con 2 columnas tendría

Prof1 723 270 resto columnas
Prof1 723 394 resto columnas

y ya estaría.
Luego, la consulta 1 es rapida. La dos menos, pq va contra una vista tocho ke tarda un poco en montarse y es la que hace las cosas lentas, pero al meterle el Union pasa de segundas a 3 o 4 minutos, brutal

Probaré si va más rápido no concatenando las JOINS a ver.

[Yentin]

Usar correctamente los índices, si es que los tienen esas tablas, y lo mismo que dice Frikjan, evitar unions ^^U

se me habia olvidado comentar esto. No soy ningun experto en SQL server y no tengo ni zorra de donde se crean indices o si se pueden crear o que mierdas, es un gestor basura XD.

[ArmiSael]

Bueno,

CREATE [ UNIQUE ] INDEX índice
ON tabla (campo [ASC|DESC][, campo [ASC|DESC], ...])
[WITH { PRIMARY | DISALLOW NULL | IGNORE NULL }]

Con eso podrías optimizar tu consulta, siempre y cuando creas conveniente crear un indice. Eso implica que tendrás más trabajo al insertar, eliminar y actualizar datos ( según el tamaño de la tabla donde crees el índice ), tener cuidado en las particiones ( aunque creo recordar que en SQL Server no existen? ), etc etc

La cosa es que si es una consulta que será muy demandada, y que los campos para los que hagas lo índices serán muy utilizados en las consultas de esa tabla y además la mejora es considerable, eso más o menos te indica que es recomendable que lo crees.

Yo trabajo con Oracle y la verdad se gana muchísimo con Índices, eso sí, se deben tener en cuenta los temas que te comentaba antes para crear uno.

Dices que te tarda el construir la vista, en Oracle existen las vistas materializadas, no se si en SQL Server también ( aunque ten cuidado a veces dan problemas ), pero mira si existen tablas temporales que puedan ayudarte a mejorar la consulta.

Este tema ha sido editado por ArmiSael: 24 April 2006 - 10:34 AM

[Yentin]

ya, no me dices nada nuevo, yo he trabajado toda mi vida con Oracle, tengo por ahi mi ORA o OCA ya no me acuerdo como se llamaba XD, el sql server este es una puta mierda.
El tema de los indices va realmente bien cuando están en un tablespace o un sector que fisicamente esté en otro disco duro. Entonces si que se nota de verdad. Aquí diria que ta todo montado en la misma mierda XD.
La última novedad, no he tocado nada y ahroa tarda 6 segundos, es genial , incluso haciendo operaciones que penalizan en tiempo me tarda muchisimo menos que antes.
Hice caso a Keb y quite los JOINS y lo hice en el Where, pero las primeras veces me lo hizo igual, a casi 3 minutos, pero ahora va a 6 segundos.
Supongo que será la puta carga del servidor pq sino no lo entiendo.
Merci.

Este tema ha sido editado por Yentin: 24 April 2006 - 11:21 AM

[Deadsunrise]

ya, no me dices nada nuevo, yo he trabajado toda mi vida con Oracle, tengo por ahi mi ORA o OCA ya no me acuerdo como se llamaba XD, el sql server este es una puta mierda.
El tema de los indices va realmente bien cuando están en un tablespace o un sector que fisicamente esté en otro disco duro. Entonces si que se nota de verdad. Aquí diria que ta todo montado en la misma mierda XD.
La última novedad, no he tocado nada y ahroa tarda 6 segundos, es genial , incluso haciendo operaciones que penalizan en tiempo me tarda muchisimo menos que antes.
Hice caso a Keb y quite los JOINS y lo hice en el Where, pero las primeras veces me lo hizo igual, a casi 3 minutos, pero ahora va a 6 segundos.
Supongo que será la puta carga del servidor pq sino no lo entiendo.
Merci.

la cache de sql.

[Yentin]

la cache de sql.

mmmm, desconocía que el sql server tubiera cache... o es del servidor donde esta el SGBD? bueno aún así me empiezo a cagar un poco en la puta madre de las caches, cuando ta todo bien van de puta madre, pero hasta entonces, joder me dan una de problemas.

[Deadsunrise]

mmmm, desconocía que el sql server tubiera cache... o es del servidor donde esta el SGBD? bueno aún así me empiezo a cagar un poco en la puta madre de las caches, cuando ta todo bien van de puta madre, pero hasta entonces, joder me dan una de problemas.

mmm es sql server, pensaba que mysql que desde la 4 lleva cache.

[kebrantador]

Hombre, cualquier gestor de bbdd medianamente comercial entiendo que tiene que tener cache... digo yo vamos xD (aunque de m$ me espero cualquier cosa...)

De todas formas, en tal caso tendría sentido que te tardara la 1ª vez, y el resto que hicieras seguidas menos (o practicamente nada). Pero no lo que comentas de que te tardo unas cuantas veces mucho y otras poco... ya que lo que es "montar la vista" no tiene ningun filtro que haga que varie de una a otra vez.

Aunque la verdad, desconozco el sql server este como tratará las vistas. Si fuera Oracle sé que la vista la trata como una consulta más, y cuando haces un select sobre la vista simplemente "añade" esas clausulas a la consulta que monta la vista

El prob es el union, que la verdad es que no mola nada en una vista

Lo de los indices yo ni te lo comenté... ya que entiendo que ya están puestos, sino evidentemente sería el mejor sitio para empezar. ¿no tiene un analizador de querys el sql server para ver por qué indices / campos tira la consulta, o si hace algún FULL TABLE SCAN?

[Yentin]

si tiene un analizador de consultas, pero si ni sikiera sabia ke habia caché, menos me se la tabla en la que guarda los nombres de los elementos, tablas o indices que tiene hechos. Si fuese en Oracle ya lo tendría pq ahi si ke se o tengo donde mirarlo (que ya no me acuerdo )
Yo presupongo que estan puestos, pero le pregutnaré al jefe mañana a ver que me dice.
PD: creo ke me tengo ke repasar los libros de la certificación, joer ke palo xD

[kebrantador]

espero que la certificación sea de Oracle y no de sql server xDDDDD que entonces ya no tendrías excusa

[xtr]

HINT: El Profiler es tu amigo, deberias pasar unas pruebas de carga con cada query y verías que diferencias ;-)

HINT 2: Googlea Sql sever Trace

Este tema ha sido editado por xtr: 24 April 2006 - 03:25 PM

[Yentin]

espero que la certificación sea de Oracle y no de sql server xDDDDD que entonces ya no tendrías excusa

es de oracle 9i, osea ke ta ya anticuada XD, hace como 2 años que la hice creo.... y luego un gran periodo de tiempo sin tocarlo y despeus meterte con sql server, pos toy contaminao XD