Consulta Sql Server

[ElDuc]

Señor@s, tengo un problema, a ver si pueden ayudarme:

Trabajo con Delphi 2010 y con Firebird.

El teme está en que la base de datos que tengo, es muy compleja estructuralmente, tiene mucha información (> 500 GB) y realizo muchas consultas (> 300 por segundo),

Firebird, es muy lento para este trabajo y quería probar con Sql Server para ver si consigo un mejor rendimiento.

El problema es que las consultas que realizo con ADOQuery no me funcionan, no sé si es porque los nombres de las tablas son dbo.Nombre o porque será.

Si pueden echarme una mano, se lo agradeceré.

[Neftali [Germán.Estévez]]

Para poder centrarse, estaría bien poner una consulta que te falla y el error que te está devolviendo SQLServer.
Yo uso SQLServer y realizo consultas sin usar el dbo. en todas las tablas.

[ElDuc]

Gracias Neftali, lo pruebo y te digo.

¿Tu crees que vale la pena pasar de Firebird a Sql Server?

[Casimiro Notevi]

Básicamente, una consulta a una BD no es más lenta porque sea más grande o menos, sino que lo que influye es que esté bien diseñada y tenga los índices apropiados y use los planes adecuados.
Aparte de ahí, para una BD de 500 GB ¿seguro que son 500 GB, y no MB? y que tiene muchas conexiones "simultáneas" debes configurar lo mejor posible el servidor.
Por supuesto, Linux, con eso ya ganas al menos un 30% de prestaciones, garantizado, memoria RAM, discos rápidos, configurar el directorio temp en un disco aparte es muy útil con Firebird, etc. Son detalles a tener en cuenta en una larga lista que habría que ir probando si tuviésemos muchísima más información de la que tenemos, que solamente sabemos que va lento y que quieres cambiar. Esa no es la solución si no sabes por qué va lenta.
Una vez que sepas el motivo del porqué va lenta, entonces sí, depende de ese motivo puedes solucionarlo o cambiar de BD si la nueva te soluciona ese problema.
Me explico con un ejemplo tonto: Tu moto marca Honda va lenta, no sé el motivo, pero me cambio a Yamaha. Y por qué iba lenta, luego descubres que era porque tenía el filtro de aire tan sucio que no dejaba pasar aire. Sólo había que cambiar el filtro del aire. Y tú fuiste y te compraste otra moto.

[ElDuc]

Gracias Casimiro.
Tendré en cuenta tus observaciones.

[Neftali [Germán.Estévez]]

Empezado por ElDuc

¿Tu crees que vale la pena pasar de Firebird a Sql Server?

Personalmente he trabajado con ambos y me gusta mucho SQLServer (si tuviera que escoger me quedaría con este).
Aunque hay que decir que no estás comparando cosas iguales.

Yo también dudo de si hablas de 500MB o 500GB.

Ten en cuenta que SQLServer en su versión free (Express) tiene limitaciones. Si optas por esa (en el caso de 500MB), debes tener en cuanta que estén dentro de lo que necesitas.
Si optas por la versión licenciada (en el caso de 500GB), debes tener en cuanta el coste de las licencias.

[ElDuc]

Gracias, Neftali.

Finalmente he optado por continuar con Firebird.

Gracias a todos.

[MAXIUM]

Y nos dejó con la duda del tamaño

[ElDuc]

La verdad es que creo que se acercará a 1TB, pero tengo que buscar algún disco SSD interno que me permita esta posibilidad.

Otra vez, gracias a todos, cuando acabe el proyecto, os comento.

[Casimiro Notevi]

Mírate esto: https://ib-aid.com/en/articles/
El apartado "Perfomance" te puede interesar.
Aparte de eso, cuando tengas dudas pregunta por aquí, algunos tenemos experiencia con Firebird desde que nació, e incluso desde antes.

[ElDuc]

Muchas gracias Casimiro, lo he hojeado y es muy interesante.

Os comento, estoy creando un sistema de SEMI-Inteligencia artificial para Forex-Divisas, de ahí la capacidad tan alta que necesito.

Digo SEMI, porqué después de perder semanas intentando encontrar un buen tutorial en español sobre inteligencia artificial y no encontrar nada práctico, he optado por hacerlo a mi modo desde cero. Si alguien conoce un buen tutorial, por favor, decidmelo.

Voy a crear un hilo referente a lo explicado en el último párrafo.

[Casimiro Notevi]

Bien, pues pregunta en ese hilo que has creado. También tengo bastante experiencia con forex.