MySQL, Delphi y cliente servidor

[[poliburro]]

Amigo, Yo te recomendaría que si deseas hacer una aplicación de dos capas, lo mejor que puedes usar es MsSql + ADO, colocando las reglas del negocio en la parte del servidor de base de datos (USando para ello Sps, trigers, funciones, etc etc etc) y solo la funcionalidad en la parte de la apliacción.


Mysql no es una buena opción para desarrollos de escritorio N-Tier. (Lo siento fans de Mysql), puesto que una de sus mayores desventajas es precisamente la capa de coenxión en aplicaciones de escritorio. ya que por un lado si deseas usar ADO, mysql solo proporciona conectores Odbc con lo que la capa se hace más gruesa además de que la versión actual de ODBC ofrece un soporte muy pobre a los Sps de Mysql 5. Por otro lado zeos te permite mantener una capa de conexión delgada pero tiene muchas desventajas precisamente en el soporte a Sps y seguridad.


Para el web es grandioso, pero para aplicaciones Ntier no lo recomiendo. A menos que Mysql saque un proveedor OleDb.


suerte

[roman]

Uso MySql sin ningún problema en aplicaciones de escritorio. Claro que no uso ODBC y tampoco Zeos. Uso MyDac.

// Saludos

[[poliburro]]

y podrías comentarnos román, como manejas tus transaciones?
como manejas tu lógica de negocios?
en cúantas capas están desarrolladas tus aplicaciones?.
Como menejas tus conexiones?


Sería muy bueno que lo comentaras ya que así, quien se está iniciando en mysql y pudiera considerar esos aspectos en base a tu experiencia con Mysql y MyDac

[roman]

¿Cómo manejo mis transacciones? Pues con StartTransaction, Commit y Rollback. ¿En cuántas capas? Aquí estábamos hablando de dos ¿qué no? No uso stored procedures, no me gustan, no los he necesitado. ¿A qué te refieres con manejar conexiones?

Por cierto, conste que yo no estoy diciendo que sea mejor usar MySql que MS SQL ni alrevés, sólo que sí que se puede hacer la conexión sin ODBC.

// Saludos

[[poliburro]]

tampoco creí eso, solo que me dió curiocidad saber como programabas en cliente servidor con mydac y mysql.


Te recomendaría mucho que evaluaras el uso de Sps ya que de verdad te facilitan mucho la tarea, y en cuanto a las conexiónes mi pregunta era sobre si las usabas persistentes o dinámicas, ahh y de las transaccciones si lo hacias en la aplicación con mydac o en la base de datos. incluyendo la lógica de negocios.

Te preguntaba eso ya que son cuestiones de vital importancia a considerar cuando desarrollas aplicaciones Ntier

[JXJ]

Poliburro.

eso de los Stored procedures, como funcionan, o en donde
es mejor emplearlos.

'¿podrias poner algun ejemplo donde los usas con su codigo fuente?

Gracias

[[poliburro]]

Un procedimiento almacenado es un script escrito en lenguaje T-Sql y es almacenado por el motor de base de datos que tú elijas. Es muy recomendable su uso Por entre muchas, las siguientes razones.


1- Ya que el motor de base de datos es quíen análiza y optimiza al momento de ser creados los Procedimientos almacenados, su ejecución en cada llamada tiene un mayor rendimiento a que si estás lanzando querys que deben ser analizadas y optiminzadas por cada ejecución. En este punto otra ventaja es que en sql server puedes hacer uso de los planes de ejecución para evitar los Index scan que decrementan terriblemente el rendimiento del motor de base de datos.

2- El leguaje T-SQl te permite optimizar operaciones que si las haces desde tu aplicación requeririan el lanzamiento de varias consultas al motor de base de datos.


3- Al tener tu lógica en el motor de base de datos, un cambio en la manera en que debe ser procesada determinada acción sobre tus tablas es una tarea sencilla en comparación de las aplicaciónes que tienen regadas copnsultas de acceso a datos. Además de que un Sp que desarrollaste para un sistema de escritorio puede funcionarte para un fron-end web. En cambio, si usas consultas deberás hacer doble trabajo.





4-Imagina que tienes una aplicación que lanza código de decenas o cientos de líneas para consultar datos, ahora imagina que tu aplicación es ejecutada por 100 clientes concurrentes. Resultado de esto? un desperdicio innecesario de recursos de red, y un decremento terrible del motor de base de datos. Al utilizar Sps, solo invocas el nombre del sp, le pasas los parámetros, si acaso los requiere, y listo, ya que el motor previamente ha optimizado el script, su degradación es mínima

Hay muchás más razones del por que se deben usar sps. y su uso es muy sencillo,

tomas la paleta ADO seleccionas el AdoStoredProcedure y haces


ADOStoredProc1.Parameters.CreateParameter(Nombre,Tipo,Direccion,Tamaño,ValorInicial)


Suerte