Como manejar una forma inmensa?

[u_goldman]

Hola a todos, aqui les pido su consejo, resulta que tengo un formulario mas o menos de 150 campos, ya trabaje con el diseno y la validacion la estoy haciendo en javascript pues no son datos criticos, ahora necesito ingresar esos valores a una tabla, si ya se que es terrible y en terminos de programacion, una tecnica pobre, ingresar todos esos datos a una sola tabla, pero asi es el requerimiento del sistema pues el cliente no quiso pagar mas.

Ahora concretamente, como manejarian uds. la incersion a la DB?

He pensado en crear los campos con el mismo nombre que tienen en el formulario, para hacer un ciclo e insertar todos como en un proceso bulk, sin tener que hacer por c/u un request manualmente.

Que otras ideas se les ocurren?

Salu2, y gracias anticipadas por las recomendaciones!

[trasgukabi]

te refieres a hacer el insert de una sola vez? eso sería lo tremendamente jodido, compadre. yo me iría más por dividirlo en un insert y 10 updates(pongo 10 como podría haber puesto otra cifra), ya que así, el problema del timeout sería menos.

lo de llamar a los campos como los del formulario es la mejor opción para armar la(s) consultas

No sé si te valdrá, espero que sí.

VENGA VAGOS, TODO CRISTO A PENSAR!!! QUE ESTE TÍO SE PASA EL DÍA RESPONDIENDO PREGUNTAS Y PARA UNA VEZ QUE PREGUNTA NO HAY QUE DEJARLE A MEDIAS!!!!

[orharo2003]

todos los campos en una sola tabla ?
150 campos, normalización ??

Pues coincido con trasgukabi..

[Neuron_376]

Pues mal el caso, pero entiendo, si no quieren pagar mas, es su bronca, sin embargo, en mi opinion, por lo mismo que no quisieron pagar mas, creo que tendran que pagar las consecuencias de lo que se estan "ahorrando".

En mi opinión, creo que vas a necesitar muchos indices bien definidos para que funcionen correctamente los select, etc., entonces empezando por ahi, la inserscion masiva seria mejor, es decir, todo al mismo tiempo, ni modo, por que cada ves que haces un update, etc., tambien los indices se modifican, lo que al final de cuenta me parece que dividir en varios updates seria al final de cuentas mas pesado, tambien, para optimizar, create un SP, donde le pasas la cadena de SQL para la insercion, el simple hecho de que el insert sea dentro del SP, lo hara mucho mas rapido que una consulta desde fuera, no uses recordset para esto, usa un set rs = conn.execute, por el tema de los recursos, para el timeout, tu sabes que hacer.

La forma en que la armes, etc., creo que esta bien como lo piensas hacer, aunque claro, debes validar todo muy, muy bien en el ASP que recibe para evitar graves problemas.

Otra cosa de bases de datos, es que tendras que ser muy ciudadoso con como ordenar los campos, te recomiendo agruparlos por tipo, dejando los dinamicos al final, es decir;

intX
intY
intZ
char1
char3
char3
varchar1
varchar2
varchar3

Y a como estan las cosas, si tienes campos tipo text, etc, para guardar grandes cosas, puedes usar un textfile para eso, que no este en la db consumiendo espacio.

Tambieno para fotos por ejmplo, en lugar de URL, etc., usa los metodos por ID, es decir, como:

Puede tener 5 fotos, entonces en la DB, en lugar de 5 URL, pones, NumFotos, entonces por ASP dices:

/carpetaFotos/ID.NUMFOTO.jpg

Entonces, si quieres guardar 3 fotos, solo pones

ID = 1
NumFotos = 3
/carpetaFotos/1.1.jpg
/carpetaFotos/1.2.jpg
/carpetaFotos/1.3.jpg

Asi, le quitas peso a la base de datos.

Si tienes cosas de localidad, haz index, como clustered indes sobre pais-estado, que minimizaran el proceso de select, lo select, hazlos basados en los indices que creaste para asegurar que el select se apoya en el index que creaste, etc.

Ufff, me extendi, es que son muchos detallitos que pueden ir quitando, pero en tu caso con algo tan pesado, debes ir modificando tu Tabla de modo que todos estos detallitos de optimización los puedas aplicar para que funcione lo mejor posible, algo que de antemano no es ideal.

Puedes tambien poner la DB para apoyarte más

Suerte!!

[u_goldman]

todos los campos en una sola tabla ?
150 campos, normalización ??

Gracias masters por sus respuestas...Si, lo se, pero repito, el cliente no quiso pagar por un trabajo bien hecho

Ahora, en su opinion, es mejor ejecutar un INSERT y despues ejecutar tantos UPDATES como sean necesarios en lugar de un INSERT gigante?

Regularmente yo utilizo clases para todos mis procedimientos, con lo cual me veo en la necesidad de generar un miembro de la clase por cada campo, tengo un script ya hecho donde le paso el nombre de los campos y este script genera los miembros de la clase, asi evito la fatiga de hacerlo todo a pulmon y que si no la hago como programador, me contraten como mecanografo

El caso es que podria hacer el ciclo como lo dije anteriormente, para construir la consulta de manera dinamica, solamente con una condicion y con cada item que llegue de la forma <> "", pero no se cual sera la mejor alternativa.

En fin, espero que me puedan seguir contribuyendo con sus ideas

[u_goldman]

Gracias, ya me habia venido a la mente lo del Stored Procedure, pero como ves el problema de los incrementos de condiciones y el mantenimiento de la aplicacion toda vez que no quisiera almacenar strings vacios, sino dejar los campos nulos?

[Neuron_376]

Para eso, haste una funcion para que te ayude a eso, estoy de acuerdo con almacenar NULL mejor que vacios.

Algo como:

strCampo = str_ReqParaDBString("CampoForm")

Entonces en la funcion, que haga toda la validacion que necesitas, como:

function ReqParaDBString(strNombreCampo)

strCampo = Trim(Cstr(Request.Form(strNombreCampo)))

if strCampo = "" then
strCampo = NULL
else
//X validaciones que necesites
end if

str_ReqParaDBString = strCampo

Entonces siempre mandas llamar esta funcion, que sera la encargada de ponerte un valor correcto en la variable

Sin embargo, estoy de acuerdo con NULL, pero si necesitas hacer consultas donde sumas campos tipo cadena, como:

select (Campo1 + ' ' + Campo2) 'Categoria' from tabla ....

Entonces es mejor usas cadenas vacias que NULL, porque en esas consultas vas a necesitas usar la funcion isnull en la consulta, y aplicar funciones en la consulta siempre es mas pesado, espero haberme explicado.

Y bueno, por otra parte, el incremento de condiciones, como tu mismo dijiste una vez, mejor hacer todo paso a paso, que estar complicandote con mas cosas, ademas en el performance, es mas rapido una serie de if, que un ciclo, por lo cual seria mejor si usas if para cada uno... solamente en los comunes algun ciclo por ahi, pero tu sabes bien, que para cambiar toda esa estructura, mejor tener if separados, lo hace mas facil, al final de cuentas no creo que sea tan pesado, porque si estoy pensando bien, el insert es cuando creas un nuevo usuario, un nuevo producto, algo asi por el estilo, entonces, no debe ser una seccion con muchísimo trafico, lo que tendra mas trafico a mi parecer son las consultas, entonces ahi es donde tienes que centrar mas la atencion del performance.

Bueno, eso estoy adivinando.

[trasgukabi]

he preparado otra cosita, así tienes para elegir. Igual hay algun error, porque lo he hecho a toda pastilla....

Código:

<%
sqlinsert1="Insert Into tabla("
sqlinsert2=") VALUES ("
For Each elemento in Request.form
	if Request.form(elemento)<>"" then
		sqlinsert1=sqlinsert1&cstr(elemento)&","
		if isnumeric(Request.form(elemento)) then
		   sqlinsert2=sqlinsert2&Request.form(elemento)&","
		else
			sqlinsert2=sqlinsert2&"'"&Request.form(elemento)&"',"
		end if
	end if
Next
sqlinsert1=left(sqlinsert1,len(sqlinsert1)-1)'para quitar la coma del final
sqlinsert2=left(sqlinsert2,len(sqlinsert2)-1)&")"
sql=sqlinsert1&sqlinsert2 
response.Write(sql)%>

[u_goldman]

A todos los que se tomaron la molestia de responder
Finalmente les cuento que despues de hacer cuantiosas valoraciones llegue al siguiente "approach"

1.- Genere un script que recorriera el codigo de la forma para tomar los nombres de cada uno de los inputs.
2.- A partir de este txt, cree un script que con sus adaptaciones necesarias creara:

- Los campos en la base de datos
- Los miembros de una clase(publicos y privados)
- Las asignaciones necesarias objeto.propiedad = request.form("campo")
- La sentencia gigantezca de incersion

Finalmente me incline por parametrizar la consulta, ya que podia aceptar valores nulos y no me tendria que preocupar por el tipo de dato, finalmente genere esta parametrizacion mediante mi txt que sirvio de base para todo.
La forma ahora funciona bastante bien, de hecho la he probado con 5 usuarios enviando datos simultaneamente y no hemos experimentado mayor complicacion(si, 5 usuarios no es nada, pero algo es algo dijo un calvo )

Afortunadamente las lineas que tuve que escribir fueron alrededor de 100, contra 2141 que tiene el archivo que contiene la clase para esta forma

Concluyendo:
La solucion fue la forma tradicional de hacer un vaciado en una forma, la utilizacion del objeto Command, fue particularmente util para tratar con estos cientos de campos que pueden tener un valor nulo, ademas que permite tener un orden bastante aceptable en el codigo y en un futuro cercano, si se presenta el problema con el manejo de la tabla, podre implementar sin ningun problema un stored procedure para mantener el codigo de incersion dentro del SQL.

Gracias nuevamente por sus aportaciones e ideas, que me sirvieron de mucho en la creacion de este maldito monstruo!

Salu2,