FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Cual es el motor DB mas adecuado y mas potente ?
Hola. Soy muy nuevo en delphi y sobre todo el programación en general.
Para mis mini sistemas utilizo tablas PARADOX conectandome desde delphi con alias creados por codigos utilizando el BDE admin . Cual es el sistema mas confiable y mas utilizado por los profesionales en sistemas? SQL Server, interbase, oracle , mysql ..... etc .. y como se puede comparar con paradox ? . Utilizando paradox se puede hacer algo absolutamente profesional ? o es lo mas básico en DB. ? Todos los manualcitos que lei se manejan con PARADOX entonces supuse que es lo mas básico en base de datos y lo mas práctico... es asi ? Mil gracias amigos de antemano saludos de un novato |
#2
|
||||
|
||||
El mas potente, indudablemente es oracle, seguido por db2.
Luego hay muchos SGDB's realmente buenos y confiables, todos con pros y contras: firebird, interbase, sqlserver, entre otros. Luego están las "bases de datos de escritorio" como se ha dado por llamar, que regularmente son archivos planos con mayor o menor soporte para ciertas características relacionales, como SQL y/o integridad referencial, entre estos: Paradox, dbase, fox, access. ¿el mas adecuado? mi respuesta es siempre la misma: depende. Eso si, desde hace muchos años uso y recomiendo usar siempre un motor 100% relacional, incluso para sistemas muy pequeños. De esa cuenta que mi elección regularmente es firebird para proyectos pequeños/medianos y oracle para grandes proyectos. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#3
|
||||
|
||||
Cita:
Lo principal es separar entre Bases de Datos de escritorio y Bases de Datos Cliente-Servidor. Las primeras son sencillas y personalmente pienso que para aplicaciones pequeñas en local (no en red) y las segundas son sistema más completos y complejos, con más potencia y prestaciones y enfocados a programas para trabajo en Red. Cada tipo es para un entorno diferente. Tal vez para un programita de una agenda de teléfonos que trabaja en local (con 2 tablas de 100 registros)sea "demasiado" montar un SQL Server o un FireBird y en ese caso sea "mejor" un Paradox; Y en cambio, para una aplicación que trabaja en Red con 10 puestos será "muy poco" un Paradox (aunque pueda funcionar) y en ese caso puede ser "mejor" un SQLServer/FireBird (por nombrar dos). Por lo tanto, antes de comparar debes tener claro qué tipo de Base de Datos necesitras: * Escritorio: Paradox, DBase, MSAccess,... * Cliente/Servidor: SQLServer, InterBAse, FireBird, MySQL,... Y otra cosa, no puedes hacer una comparación entre Bases de Datos de ambos tipos; Es decir "no tiene sentido" (a mi entender) comparar Paradox con InterBase, ya que son cosas diferentes, con funcionalidades diferentes y para problemas diferentes. Cita:
Cita:
Personalmente para algo "profesional" no usaría Paradox, aunque eso no quiere decir que no se pueda hacer; Hay miles de aplicaciones profesionales trabajando actualmente con Paradox, pero a día de hoy yo no lo escogería. Para una BD de escritorio prefiero Access (más estandard -aunque no nos guste-, más manejable por el usuario y a mi entender con mejores prestaciones). Para temas de C/S FireBird o SQLServer dependiendo de prestaciones, necesidades y presupuesto.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#4
|
||||
|
||||
En tu caso, no recomiendo seguir usando la BDE... muchas veces es mas grande el runtime de la BDE que la aplicacion como tal. Para sistemas pequeños/medianos una base de datos como Firebird es lo mejor. Adicionalmente se puede usar de forma "embeida" en donde NO tienes que instalar el servidor firebird sino que instalas la aplicacion con una DLL y el acceso es local (como con Paradox) pero al tiempo tienes un motor relacional con todo los "jugetes" como vistas, procedimientos almacenados, generadores y triggers y solo es cuestion de cambiar la cadena de conexion y !bingo! ya te conectas a un servidor firebird.
Este articulo te puede servir: http://www.solucionesvulcano.com/blo...ciendo-la.html Y con lo de potente? La verdad es que la GRAN mayoria de las aplicaciones JAMAS explotaran las capacidades de motores mas "grandes" como Oracle, DB2 o Sql Server. Normalmente toca usarlas mas porque los clientes/mercado lo demandan que porque sean realmente, necesarias. No digo que no se usan sino que muchas veces se usan de forma desproporcionada (como el BDE, estos motores terminan siendo MAS grandes que la aplicacion como tal) Con Firebird podras manejar cantidades muy grandes de registros (incluso archivos de datos que pasan la GIGA de tamaño) sin problemas. De hecho, el principal cuello de botella de las aplicaciones actuales es la RED, seguida del Disco Dura y luego la memoria.... no la BD...
__________________
El malabarista. |
#5
|
|||
|
|||
agradecimiento y pregunta =)
Primero les agradezco de parte mia y de todos los novatos del club la catedra que dieron de base de datos y segundo, llego a la conclusión que tengo que
aprender urgente a trabajar con Motores SQL, como los mencionados por ustedes . En mi facultad (Univ. Caece Mar del Plata. Argentina) se nombra mucho SQL Server. Pero bueno ... habria que analizar todos los motores uno por uno y conocer sus prestaciones mas importantes y en que caso es la decisión adecuada elegirlo. Voy a empezar a buscar información acerca de todos. En mi caso, lo que decidi hacer es comenzar a estudiar delphi con tablas locales embeidas, en esta oportunidad paradox. Lo hice intentando hacer un sistema de debitos y creditos por cliente, con ABM de rubros y productos. Funciona perfectamente, convinandolo con QReport pude tirar listados de lo que necesito. Pero estoy ahora conciente (y gracias a ustedes) que para un sistema de este tipo sea profesional para ser utilizado por una empresa grande tiene que manejarse con un motor SQL mas apto al caso. Aparte puedo tener muchos problemas en concepto de seguridad de datos usando ese tipo de tablas. No lo veo conveniente si esto se refiere a los ingresos económicos de una empresa. Es muy dificil migrar todos los datos de PARADOX a una base CLIENTE-SERVIDOR ? Cambia mucho el diseño y estructura de las tablas ? El codigo de ABM, con las consultas hay que modificarlo en su totalidad ? Espero no tener que empezar de nuevo si lo que quiero es utilizar SQL Server o FIREBIRD. Mil gracias por todo. Saludos. |
#6
|
||||
|
||||
Mamcx, perdona la tontería pero no es "embeida" es "embebida"
Al principio creí que era un error de sintaxis, pero veo que no. Espero que no me tomen por un tiquismiquis.
__________________
Milo |
#7
|
||||
|
||||
Cita:
Ahora bien, nada impide usar un motor Sql estilo una engine local. Es perfectamente valido solo tener tablas y relaciones, sin procedimientos o triggers. Si estas empezando, considera seriamente ir derecho a Firebird, porque: a- Igual terminaras usando un Motor Sql y el concepto con uno es similar al otro b- No tienes que usar procedimientos almacenados, pero es bueno tener la oportunidad en caso de ser necesario c- PARADOX es una base de datos que ya paso a la historia... d- El despliege de la aplicacion es MUCHO mas simple. Si usas firebird embeido (ejeeeje yo digo embeido y no como se debe!) solo despliegas 1 DLL + 1 Archivo de texto, en contraste instalar la BDE es mas complejo... Y si por cualquier razon, como por ejemplo, si cuestionan que tu aplicacion no es cliente/servidor instalar Firebird normal, cambias la cadena de conexion t PRESTO ya tu aplicacion es al estilo de grandes ligas. Ahora, supongamos que te aferras a Paradox. O igual, eventualmente te tocara usar un motor diferente al que uses al inicio, asi sea firebird. Consejos? 1- NO pongas los TDataSet en los formularios o informes. No, no lo hagas. En estos lugares solo se deben poner TDataSources y nada mas 2- Si tu aplicacion es pequeña, es Ok tener los TDataSet en un TDataModule. Pero te recomiendo que crees una unit que se ESPECIALIE en acceso a datos: function ObtenerSql(lcSql):TDataSet y lo enlazes por codigo a los TDataSource. Asi a) Podras abiri multiples veces el mismo conjunto de datos sin preocuparte en que el registro se mueva de lugar en los demas b) Al devolver TdataSet te aseguras que si necesitas cambiar de TTable a TClientDataSet lo haces sin esfuerzos. 3- Usa un archivo con la lista de sql y usa constantes: const SqlListarClientes = 'SELECT * FROM Clientes'; Asi si cambias de motor Sql existe un UNICO lugar donde hacer los cambios...
__________________
El malabarista. |
#8
|
||||
|
||||
Cita:
Cita:
__________________
El malabarista. |
|
|
|