Insertar una cadena como registros en una tabla.

Sólo con esto y con la ayuda de la tabla num que siempre tengo implementada en cualquier base de datos con la que trabaje se puede hacer que la cadena ".ax154.as458.az4521." se inserte en una tabla como registros separados, es decir:

ax154
as458
az4521

Se podría hacer un cursor, que resulta lo más fácil, pero puedo decir que hacer un cursor con esto es hacer una buena chapuza. Lo que muestro a continuación está basado en las enseñanzas de una presentación que Itzik Ben-Gan nos hizo en MURCIA.

Para que funcione debemos tener a mano la tabla num:

if NOT exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[num]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
BEGIN
CREATE TABLE [dbo].[num] ( [num] [int] NOT NULL ) ON [PRIMARY]
CREATE UNIQUE CLUSTERED INDEX [PK_num] ON [dbo].[num]([num]) ON
[PRIMARY]
END
GO
IF NOT exists(SELECT * FROM num)
BEGIN
INSERT num values(1)
WHILE (SELECT TOP 1 isnull(num,0) FROM num ORDER by num
desc)<1001
INSERT num
SELECT TOP 1 ISNULL(num,0)+1 FROM num ORDER by num desc
END
GO


Como podéis ver lo único que hace la instrucción anterior es crearnos una tabla con 1000 números secuenciales con una diferencia de 1. Apoyándonos en esta tabla podremos separar la cadena en registros de una forma muy fácil:

DECLARE @Cadena_Farm AS VARCHAR(8000)
SET @Cadena_Farm='.ax154.as458.az4521.'
SELECT (CASE WHEN SUBSTRING(@Cadena_Farm,num,1)='.'
THEN
SUBSTRING(@Cadena_Farm,num+1,CHARINDEX('.',SUBSTRING
(@Cadena_Farm,num+1,8000))-1)
ELSE '' END) AS Cadena
INTO TablaQueNecesito
FROM Num
WHERE num<LEN(@Cadena_Farm) AND SUBSTRING(@Cadena_Farm,num,1)='.'
GO

Optimizaciones para SQL Server. Versión 1.

Antes de nada lo mejor que se puede hacer y que nunca falla es hacer bocetos del diseño con un lápiz en una cartulina grande. Os recomiendo una cartulina o rollo industrial de papel porque normalmente un folio se queda pequeño nada más empezar y si acumulamos varios folios al final podríamos perdernos. Debemos evaluar la dimensión de datos que va a tener nuestra base de datos, preveer posibles crecimientos, etc. Si la media de nuestros clientes trabajan con 2 millones de registros y con posibilidad crecimiento a 5, no está de más hacer pruebas con ningún registro, con 5 y con 10 millones.

1.-Normalizar , normalizar y normalizar.
a) No repetir datos en distintas tablas.
b) No crear tablas con muchas columnas
c) No crear tablas cuya suma de tamaño columnas sea muy grande.
d) Evitar relacionar muchas tablas entre sí.
2.-Respetar mayúsculas y minúsculas en todos los objetos, tablas, SP, vista, etc. No es lo mismo "Hola" que "hola" para el motor de SQL aunque luego lo ejecute igual. Puede que no encuentre un plan de ejecución en la caché y tenga que crearlo otra vez....
3.-Crear índices, 1 agrupado al menos.
a)Para crear índice debemos tener muy claro antes que tipo de consultas se van a hacer. Si nos conviene utilizar varias columnas en un índice o no.
b)Si utilizamos varios columnas debemos determinar el orden de estas columnas en los índices y en las consultas. En una consulta ordenada por (fecha,factura) un índice (fecha, factura) optimizaría bastante el tiempo de respuesta, sin embargo un índice (factura, fecha) no nos serviría en esta caso.
c)Debemos tener en cuenta que los índices ocupan espacio de disco.
4.-Tracear el movimiento de la base de datos para ver posibles errores. Controlar las inserciones, actualizaciones, borrados y consultas para ver su rendimiento. Quitar y añadir índices.
5.-Si disponemos de 2 disco duros se puede separar el fichero de datos del fichero LOG.
6.-Intentar separar SQL Server de cualquier otro servidor. Un servido dedicado sólo a SQL Server aunque no sea una supermáquina puede optimizar muchísimo el rendimiento SQL Server.
7.-Controlar el tamaño de Log. Es muy frecuente encontrar en los foros gente con problemas del tamaño del Log de la base de datos.
8.-Planificar una plan de mantenimiento para la base de datos.

Dejo abierto este artículo para futuras correcciones....