Página 1 de 1

OT: Más guias para trabajar con SQL

Publicado: Lun Ago 01, 2005 9:39 am
por jose.luis
Ignacio,
Todaví­a tengo una duda:
a. Trabajar con una sola base de datos
b. Trabajar con tantas bases de datos como Empresas/Año haya.
Creo que me comentaste que tu irí­as por la opción b.
¿Puedes (si eres tan amable) ampliarme el por que?
Saludos y gracias,
José Luis Capel

OT: Más guias para trabajar con SQL

Publicado: Lun Ago 01, 2005 10:27 am
por ignacio
José Luis,
Sin duda algunan opción A. No te lies, todo en una única BD, sin dudarlo. Y
no crees una tabla por año dentro de la BD, una tabla con todo. Si necesitas
velocidad, que lo dudo que te haga falta, haz un histórico de las tablas que
pueden crecer mucho.
Un saludo,
"José Luis Capel" <jose.luis@capelsoft.com> escribió en el mensaje
news:[email=42edd1b4@ozsrvnegro.ozlan.local...]42edd1b4@ozsrvnegro.ozlan.local...[/email]
> Ignacio,
>
> Todavía tengo una duda:
>
> a. Trabajar con una sola base de datos
>
> b. Trabajar con tantas bases de datos como Empresas/Año haya.
>
> Creo que me comentaste que tu irías por la opción b.
>
> ¿Puedes (si eres tan amable) ampliarme el por que?
>
> Saludos y gracias,
> José Luis Capel

OT: Más guias para trabajar con SQL

Publicado: Lun Ago 01, 2005 10:46 pm
por Francisco Sanchez
Siento disentir contigo ignacio, y sin que sirva de punto de polemica pero
no estoy de acuerdo contigo. Por el tipo de aplicaciones a los que se
refiere jose luis yo personalmente he optado por una base de datos por
ejercicio. Simplemente por que mis clientes tienen grandes volumenes de
informacion y siempre sera mas agil de mover tablas que a principio de
ejercicio parten practicamente de 0 que no que vayan acumulando datos de un
ejercicio a otro. Ademas el mantenimiento de esto no es para nada complejo.
Yo lo tengo hecho y de ejercicio a ejercicio se traspasan saldos y demas, y
funciona perfectamente. Hasta incluso puedo hacerlo - el mantenimiento de
esta operatoria - desde un terminal o por web, como quiera, no
necesariamente en el servidor mysql. Es mi aplicacion quien se encarga de
todo eso.
Pero solo es una opinion personal, esto es cuestion de gustos y para gustos
los colores. Mi opinion simplemente es otro punto de vista.
Un saludo

OT: Más guias para trabajar con SQL

Publicado: Lun Ago 01, 2005 11:09 pm
por jasm.nospam
Paco,
Tampoco sin entrar en polémicas y que cada cual haga las cosas como le
venga en gana..... ¿Para que demonios sirve un motor de bases de datos
potente si te curras tu la mitad del trabajo?
Ahh, claro, que tu necesitas compatibilizar todo con el sistema de DBF's
por que tus aplicaciones soportan SQL y DBF a gusto del cliente. ¿¡!?
No deja de sorprenderme lo terriblemente encasillados que estamos en el
diseño de bases de datos pensando en tablas y DBF's. No me extraña que
alguna gente salga huyendo cuando se habla de xBase.....
Como dije antes, cada cual que haga las cosas como le venga en gana o
según su entendimiento y saber que es más fino. Pero sobre todo, nada de
pensar en asimilar cosas nuevas o de aplicar la tecnologí­a
correctamente: como ya dije en chochurro, hay un miedo tremendo a
renovarse ... (totalmente, por que hay los que se renuevan a medias).
Un saludo,
Jose A. Suarez
Francisco Sanchez escribió:
> Siento disentir contigo ignacio, y sin que sirva de punto de polemica pero
> no estoy de acuerdo contigo. Por el tipo de aplicaciones a los que se
> refiere jose luis yo personalmente he optado por una base de datos por
> ejercicio. Simplemente por que mis clientes tienen grandes volumenes de
> informacion y siempre sera mas agil de mover tablas que a principio de
> ejercicio parten practicamente de 0 que no que vayan acumulando datos de un
> ejercicio a otro. Ademas el mantenimiento de esto no es para nada complejo.
> Yo lo tengo hecho y de ejercicio a ejercicio se traspasan saldos y demas, y
> funciona perfectamente. Hasta incluso puedo hacerlo - el mantenimiento de
> esta operatoria - desde un terminal o por web, como quiera, no
> necesariamente en el servidor mysql. Es mi aplicacion quien se encarga de
> todo eso.
>
> Pero solo es una opinion personal, esto es cuestion de gustos y para gustos
> los colores. Mi opinion simplemente es otro punto de vista.
>
> Un saludo
>
>

OT: Más guias para trabajar con SQL

Publicado: Lun Ago 01, 2005 11:42 pm
por jose.luis
Ignacio,
Finalmente, y después de meditarlo un tiempo (media hora más o menos
;-)) creo que voy a seguir tus consejos.
Una sola base de datos para todo... además con SQL Server... y si
puedo... OLAP... y a ver que pasa!!
He empezado a hacer pruebas creando tablas simples. Como añadido a cada
tabla tengo que incluir el campo 'Empresa' y el campo 'Anyo' y construir
la clave primaria con restricciones incluyendo estos dos campos como
parte de la misma.
La pregunta que, creo que ya me has respondido, me gustarí­a que me
ampliases (o JFG) es: que pasará con ADO?? ¿Que ventajas, aparte de las
evidentes, aporta? ¿Puedes darnos unas pinceladas de lo que nos va a
venir? ¿Y cuando?
> Si necesitas
> velocidad, que lo dudo que te haga falta, haz un histórico de las tablas que
> pueden crecer mucho.
¿Por que dudas que me puede hacer falta velocidad? (Es solo una curiosidad)
Saludos y gracias a todos los que me han respondido.
José Luis Capel

OT: Más guias para trabajar con SQL

Publicado: Mar Ago 02, 2005 9:29 am
por ignacio
José Luis,
> Finalmente, y después de meditarlo un tiempo (media hora más o menos ;-))
> creo que voy a seguir tus consejos.
Me alegro. Cuando el cliente te pida un gráfico comparativo de los últimos 5
años y lo resuelvas con un simple SELECT me lo agradeceras. ;-)
> La pregunta que, creo que ya me has respondido, me gustaría que me
> ampliases (o JFG) es: que pasará con ADO?? ¿Que ventajas, aparte de las
> evidentes, aporta? ¿Puedes darnos unas pinceladas de lo que nos va a
> venir? ¿Y cuando?
Con ADO irá todo mucho más fino, y con muchas más posibilidades que lo que
el actual driver ODBC ofrece. Todo el trabajo que hayas hecho con ODBC
facilmente lo podrás mover a ADO sin problemas.
Tecnicamnente con ADO ya existe una capa intermedia que se encarga del
manejo del buffer completo de datos, y por lo tanto no es necesario crear
ninguna DBF temporal como hacemos con ODBC. Además con ADO, todas las
operaciones de mantenimiento son controladas directamente por él soportando
directamente los métdos AddNew, Update, etcetera.
¿Cuando? Aunque ya se podría empezar a trabajar en ello, y de hecho se han
hecho bastantes pruebas al respecto. Creo que debemos esperar a que los
controles ActiveX esten operativos, más que nada, porque queremos que ADO
vaya realmente rápido y estable convirtiendose de facto en el sistema
preferido para acceder a bases de datos desde Xailer.
> ¿Por que dudas que me puede hacer falta velocidad? (Es solo una
> curiosidad)
Una tabla de albaranes, puede crecer mucho con los años. Si tus busquedas se
van a basar en claves primarias no tendrás ningún problema. Si por el
contrario al cliente le da por buscar por todos los campos, puede que te
interese hacer una tabla aparte con datos de años anteriores. No obstante,
yo antes haría lo siguiente:
- En el QBE establecer como rango de fecha el ejercicio en curso, y crear un
índice por fecha
- Crear otros índices sobre campos utilizados en la búsqueda.
Un saludo,
Ignacio Ortiz de Zúñiga