 |
Club Builder
Foro de C++Builder en español
|
| Ver tema anterior :: Ver tema siguiente |
| Autor |
Mensaje |
Joey
Invitado
|
 Publicado: Vie 22 Ago, 2003 8:37 am Asunto: Elegir Motor de Base de datos |
 |
|
| Hola colegas, mi pregunta era la siguiente: Para una aplicacion monopuesto, monousuario, ¿Cual es el mejor motor??. ¿ Paradox , Access, ADO ?. Gracias por vuestro tiempo. |
|
| Volver arriba |
|
 |
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Vie 22 Ago, 2003 8:40 am Asunto: |
|
|
Para mi Interbase/Firebird, ya que tener un motor que sea activo te ayuda mucho, soporta triggers, procedimientos almacenados, restricciones de integridad referencial, esto ultimo muy importante porque además de ayudar a la consistencia de la BD permite simplificar la programación de las aplicaciones, al descargar sobre la BD ciertas tareas.
Ciao y suerte. |
|
| Volver arriba |
|
|
Touchsoftwares
Master
Registrado: 16 Dic 2002Mensajes: 869Ubicación: MEXICO Playa del Carmen
|
| Publicado: Vie 22 Ago, 2003 4:06 pm Asunto: |
|
|
En mi caso uso MYSQL a traves de ODBC de windows, me gusto por que uso los controles normales (pienso que podria emigrara a otros tiposde bases de datos mfacilmente), el mysql es rapido y corre en cualquier plataforma.
No he usado interbase pero he escuchado cosas buenas
Te dire que Ian Marteen (el autor del libro la cara oculta de c++ builder) me conteto en un email que el mysql es el servidor de base de datros para los que no les gustan las bases de datos (tengo el mensaje en el foro busca "Marteens")
Saludos
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc
http://www.touchsoftwares.com |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Vie 22 Ago, 2003 4:35 pm Asunto: |
|
|
Yo el unico problema que le achaco a MySQL es el tema de las Restricciones de Integridad referencial (depende la versión que utilizes están soportadas o no). Esto te simplifica mucho la aplicación.
Imaginate que tienes una tabla Catalogo.
| Código: |
/* No es la forma correcta de definir las restricciones, pues es mejor darles nombres, pero es para hacer el ejemplo más entendible y pequeño*/
CREATE TABLE ARTICULOS (
codigo integer not null,
descripcion varchar(20),
precio integer,
primary key(codigo)
)
// y otra tabla llamada Ventas.
CREATE TABLE VENTAS (
codigo_venta integer not null,
codigo_articulo integer,
precio_venta integer,
primary key(codigo_venta),
foreign key(codigo_articulo) references ARTICULOS(codigo)
ON DELETE CASCADE
ON UPDATE CASCADE
) |
Esto me ha simplificado el codigo de la siguiente manera.
En interbase por ejemplo que si estan soportadas estas restricciones tendriamos el siguiente funcionamiento.
- Si yo modifico el campo CODIGO de Articulo, automaticamente el SGBD modifica los campos de la tabla VENTAS donde aparezca ese articulo. Eso evita la inconsistencia. (ON UPDATE CASCADE).
- Si yo borro un articulo de la tabla ARTICULOS automaticamente se me borran todos los articulos de la tabla VENTAS donde aparezcan ese ARTICULO. (ON DELETE CASCADE).
- Si hubieramos omitido el ON DELETE CASCADE en la creación de la TABLA, al intentar borrar un articulo, si de este articulo se ha hecho alguna venta, es decir hay tuplas en la Tabla VENTAS donde figura ese articulo, Interbase nos hubiera disparado un error y no nos dejaría eliminar el articulo de la TABLA ARTICULOS (garantizandonos así la consistencia, es el llamado ON DELETE RESTRICT).
Sin embargo si estamos con MySQL (PERO QUE NO SOPORTE RESTRICCIONES, tendriamos el siguiente funcionamiento.
- Si yo modifico el codigo del articulo en la tabla ARTICULOS, no se habrían modificado los codigos de articulos en la tabla VENTA, con lo que el programador debe programar lineas de codigo para controlar la consistencia de la BD. (Engorro imaginate que tienes así muchas tablas).
- Si yo borro un articulo, habría ventas de las cuales pertenecerían a articulos que no existen, luego esto puede ser considerado como INCONSISTENCIA O NO, y habría que tomar decisiones de si requiere hacer más codigo para tratarlo como incosistencia o está permitido este funcionamiento.
Todo este tratamiento puede hacer que el SGBD sea más o menos complejo, pero los SGBD activos son más interesantes porque descargan al programador de algo de su trabajo. A lo mejor me estoy pasando y para una aplicación monopuesto es tontería irse a un SGBD más potente o complejo, pero sinceramente la ayuda que me proporciona el solo pensar en la integridad referencial no me hace dudar. Porque hay que pensar que (a las malas) el diseño de la BD podría sufrir modificaciones en cuanto a su estructura (logicamente esto se produciría de un mal diseño inicial), pero si se produjera, si estubieramos ante un SGBD que soportara integridad referencial los cambios no afectarian al programa, y varias lineas SQL cambiadas seguiriamos garantizando la consistencia de la BD. Sin embargo si nuestro SGBD no lo soportara, estariamos teniendo que volver a trabajar con el codigo que nos garantizaba esta consistencia y probablemente caeriamos en algunos fallos por despiestes u olvidos que no son nada convenientes.
En fin, como siempre cada cual lo que le guste y lo que le funcione bien.
Ciao y perdonad por el texto tan largo.
Me acabo de acordar de una cosa, si vas utilizar Querys para hacer algunas consultas más complejas, MySQL cero que no soporta Sub-consultas y esto si que hace aun más compleja la programación. Se que habrá gente que hará cosas similares con los JOIN, etc. Pero una SubConsulta te puede hacer la vida mucho mucho más facil, porque en varias lineas podrías tener los datos que te interesan y simplemente tendrías que sacarlos por pantalla, sin tener que estar consultando varias tablas para hacerlo en el caso de no soportar las subconsultas. |
|
| Volver arriba |
|
|
Touchsoftwares
Master
Registrado: 16 Dic 2002Mensajes: 869Ubicación: MEXICO Playa del Carmen
|
| Publicado: Sab 23 Ago, 2003 3:25 pm Asunto: |
|
|
Efectivamente tienes toda la razon..., analizare otros manejadores de bases de datos , gracias
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc
http://www.touchsoftwares.com |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Sab 23 Ago, 2003 3:57 pm Asunto: |
|
|
Gracias amigo Touch, lo que había comentado es obvio de que son realmente mejoras frente a SGBD que no las llevan, muchas veces estas mejoras no son incluidas para garantizar un rendimiento optimo de velocidad. Aun así habría que hacer test claro para ver como rinden estos SGBD frente a consultas grandes y pequeñas. Mucha gente da como bueno el funcionamiento de MySQL en cuanto a velocidad, luego asumo que funcionará bien.
Como ya dije en otro post parecido, Oracle hasta la versión 6 o 7 no incluia las foreign key, así se aseguraban un rendimiento optimo en rapidez, al no tener que realizar ciertas comprobaciones. Aun así en la web de MySQL hay hechos varios test aunque yo no me fiaría mucho de los test por parte de la propia empresa, compara con BD ya un poco obsoletas, es decir, si la versión estable de MySQL es la 3.23 (más o menos) no está bien hacer una comparación de MySQL 4 con Interbase 5, (cuando por ejemplo Interbase va por la 7) y por ejemplo no hay comparativas con Firebird, o van y se ponen a comparar MySQL 4 con Access (ya te cagas!!).
En fin, imagino que MySQL va muy bien, por cuando toda la gente que hay utilizandola y más para Internet, luego eso es obvio, pero prefiero que me ofrezca ayudas y me simplifice mi aplicación y tener que despreocuparme un poco de la consistencia, en un proyecto medianamente grande, se te podría ir de las manos.
En fin, comentarios para todos los gustos. Imigino que mucha gente estará supercontenta con MySQL. Yo me quedo con Firebird. |
|
| Volver arriba |
|
|
Kurroman
Lt
Registrado: 07 Dic 2003Mensajes: 79
|
| Publicado: Lun 08 Dic, 2003 8:28 pm Asunto: |
|
|
Lo bueno de MySQL es que es de las bds mas rapidas que puedas encontrar, sobre todo a nivel de consultas, es facil de usar, portable, preparada para red y tiene control de acceso. Respecto la integridad referencial pues depende del numero de tablas que tengas sabras el trabajo extra que tendras que realizar. Ademas si quieres meter una parte web a tu sistema lo tienes a wevo con php. Ah, y admite valores de autoincremento.
Firebird e Interbase no las he usado, pero la voy a probar en breve. Mas que nada por usar IBX. Yo MySQL tengo wenas experiencias pero programando en Java/JSP/PHP. |
|
| Volver arriba |
|
|
ikis
Master
Registrado: 28 Dic 2002Mensajes: 703Ubicación: Madrid, España
|
| Publicado: Mie 10 Dic, 2003 10:14 am Asunto: |
|
|
solo para hacerte la aclaración que IBX est;a deprecated, lo que Borland ha puesto en reemplazo es dbExpress que te será especialmente úitl para Interbase,
saludos |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Mie 10 Dic, 2003 10:44 am Asunto: |
|
|
Es cierto que IBX está o estará en breve deprecated, pero la persona que se encarga de su desarrollo siempre está sacando actualizaciones. Que raro verdad? jajaaja.
Ojalá sucediera esto mismo con Builder.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
ikis
Master
Registrado: 28 Dic 2002Mensajes: 703Ubicación: Madrid, España
|
| Publicado: Mie 10 Dic, 2003 12:02 pm Asunto: |
|
|
| no se q opines, pero según leí, el punto flojo de IBX es el acceso concurrente a las tablas |
|
| Volver arriba |
|
|
|
|
No puedes publicar temas nuevos en este foro
No puedes responder a temas en este foro
No puedes editar tus mensajes en este foro
No puedes borrar tus mensajes en este foro
No puedes votar en las encuestas de este foro
|
© 2002–2026 Club Builder · Funciona con phpBB.
|
FAQ
Buscar
Miembros
Grupos de Usuarios
Registrarse
Perfil
Entra para ver tus mensajes privados
Entrar
