Manu,
Mi respuesta anterior es para justificar a los que quieren tener el mismo
programa sustentando diferentes bases de datos. Obviamente una buena
implementación de bases de datos puede ser muy parecida entre diferentes
bases de datos. Se pueden obtener resultados parejos aunque para ello
tengas que hacer cosas ligeramente diferentes. Estos cambios entre
diferentes bases de datos cuesta tiempo... y dinero. Y la administración de
cada base de datos tambien es costosa en tiempo.... y dinero. Entonces...
los coste de implementación de cada nueva base de datos que quieras
soportar bien podría resumirse en la siguiente ecuación (permitidme este
ejercicio que no deja de ser algo más bien lúdico que empírico):
nCoste := nCosteInicial * ( nNumeroBases - nNumeroBases * nFactorNoHecho)
nCoste es el coste resultante.
nCosteInicial es el coste de implementación de la primera base
nNumeroBases son (en número) las nuevas bases a implementar
nFactorNoHecho es (de cero a uno) el porcentaje que se presupunone hay que
desarrollar nuevo.
Creo que esta ecuación es aplicable a cada uno de los elementos que
interviene en la creación de software:
- Analisis Base datos
- Análisis Software
- Programación software
- Programación base datos
- Administración base datos
- Soporte
Luego... Habría que sumar los ingresos derivados de las ventas y soporte del
software y ver la desviación de inversión respecto a resultados.
Saludos,
José Luis Capel
> Estoy de acuerdo contigo... pero eso puede ser un poco superficial y a
> la larga muy costoso.
> Hoy en día tienes que pensar primero en la estructura de la bases de
> datos, Tablas, Relaciones, dominios, Disparadores, procedimientos
> almacenados, indices, etc... eso te debería llevar como mínimos el 75%
> del tiempo y por último en lo que vas a usar de programación para
> accederla...
> Te puedo decir que en mi trabajo hemos tenido que perder más de un año
> por culpa de lo que digo... y la aplicación funcionaba pero cuando se
> empezó a meter caña a tope vimos que para el cálculo de la nómina de los
> trabajadores de diputación había que dejar los proceso toda la noche...
> con algunos procedimientos almacenados se redujo a horas y con el cambio
> a un gestor de bases de datos diferente y la reestructuración de las
> tablas pasó a minutos...
>
>
> José Luis Capel - escribió:
>> Manu,
>>
>> Todo se reduce a una cuestión económica. Si el provecho que sacas supera
>> el
>> coste invertido entonces todo es bueno y cualquier argumento técnico
>> queda casi en segundo plano.
>>
>> Saludos,
>> José Luis Capel
>>
>>
>> "Manu" <
manuexposito@terra.es> escribió en el mensaje
>> news:[email=
451f7f90@news.xailer.com...]
451f7f90@news.xailer.com...[/email]
>>> Creo que los dos tenéis razón, como siempre...
>>> Desgraciadamente el estandar sólo tiene unas especificaciones básicas y
>>> cada proveedor amplía con creces a ese estanadar creando
>>> incompatibilidades. Realmente eso nunca ha sido lo importante para los
>>> fabricantes de bases de datos, por desgracia.
>>>
>>> En SQL, me refiero en bases de datos relacionales, lo importante a tener
>>> en cuenta son las tres capas básicas y la ubicación de estas.
>>> - Las reglas de integridad y coherencia, estarían indiscutiblemente en
>>> el gestor de bases de datos...
>>> - Las reglas de negocio, aquí si habría dudas ya que estas podrían estar
>>> en la Base de datos o en el programa de acceso. Precisamente lo que se
>>> intenta es que los datos sean lo más independientes posible del programa
>>> que los accede. Deberíamos conseguir que lo de menos fuera el programa
>>> que los accede que podría ser Delphi, VB o Xailer por ejemplo. Hay que
>>> recordar que hacer un cálculo de una nómina, por ejemplo será mucho más
>>> facil y rápido hacerlo en el servidor con un Procedimiento almacenado
>>> que en un programa PRG en el cliente...
>>> - Programa que accede a los datos. Aquí cada uno elegirá el que más le
>>> guste, yo Xailer, jeje.
>>>
>>> Pienso que los programadores deberíamos llegar a usar las sentencias SQL
>>> directamente ya que las podríamos adaptar al gestor de bases de datos
>>> que usemos...
>>> Y se quiera o no un cambio en la Base de Datos significa un cambio en
>>> programas a pesar del uso de DataSet o Datasources...
>>>
>>> Ahora no puedo seguir, me voy con mis niños a la calle, pero si sigue el
>>> hilo seguiré con la exposición...
>>>
>>> Saludos
>>>
>>>
>>>
>>> José Luis Capel escribió:
>>>> José,
>>>>
>>>>> - Sentencias de actualizaci?n de datos (INSERT y UPDATE): no creo que
>>>>> haya diferencias significativas entre unos motores y otros. Adem?s, si
>>>>> se
>>>>> utiliza un sistema de acceso a datos como ADO, entonces ni siquiera
>>>>> vamos
>>>>> a usar estas sentencias.
>>>> El que uses ADO no significa que renuncies a utilizar DML. Yo estoy
>>>> utilizando uno y otro dependiendo de la situación. De hecho utilizar
>>>> directamente DDL es mucho más rápido que con ADO. Aparte lo anterior,
>>>> los
>>>> insert y updates se pueden complicar mucho. Puedes hacer sentencias
>>>> update
>>>> como esta
>>>>
>>>> UPDATE supplier SET supplier_name = ( SELECT
>>>> customer.name
>>>> FROM customers
>>>> WHERE customers.customer_id = supplier.supplier_id)
>>>> WHERE EXISTS
>>>> ( SELECT customer.name
>>>> FROM customers
>>>> WHERE customers.customer_id = supplier.supplier_id);
>>>>
>>>> Con lo cual puede que uno u otro sistema no sea sitácticamente igual.
>>>>> - Sentencias de carga de datos en los mantenimientos (p.ej. cargar en
>>>>> un array las l?neas de un pedido): no creo que sea necesario utilizar
>>>>> sentencias SELECT tan complicadas que sean incompatibles entre
>>>>> distintas BB.DD.
>>>>>
>>>> Bueno... depende... todo depende de lo que quieras buscar y como lo
>>>> quieras
>>>> traer. Yo utilizo select sencillas y otras donde hago una ristra de
>>>> inner
>>>> joins de varios niveles.
>>>>
>>>>> - Consultas para informes, extractos, etc.: aqu? s? creo que puede
>>>>> haber diferencias entre distintos motores. Pero como ya comentamos
>>>>> este verano,
>>>>> creo que este problema se puede resolver creando vistas en la BD y
>>>>> entonces desde el programa nos limitaremos a poner "SELECT * FROM
>>>>> VistaLoQueSea" salvando las incompatibilidades.
>>>>>
>>>> Las vistas pueden ser una solución válida...
>>>>> Respecto a los lenguajes de manipulaci?n de la BD (crear la BD,
>>>>> usuarios,
>>>>> tablas, etc.) s? es cierto que todos son distintos. Pero hoy dia te
>>>>> coges
>>>>> cualquier programa de administraci?n de la BD y te genera un script
>>>>> completo que puedes guardar en un campo memo de un dbf, y tener en ese
>>>>> dbf
>>>>> varios registros, uno por cada BD que soporte tu programa.
>>>>>
>>>> Entonces tienes que aprender varios programas de administración de
>>>> datos. Tambien has de aprender la sintáxis de cada uno para saber que
>>>> campos y
>>>> tipos crear. Aparte está de disparadores y esas cosillas...
>>>>
>>>>> Puede que haya otras caracter?sticas que diferencien las distintas
>>>>> BB.DD.
>>>>> y que puedan influir puntualmente en el dise?o de un programa, pero
>>>>> francamente creo que con un poco de imaginaci?n se pueden solucionar y
>>>>> no
>>>>> ser un escollo para poder soportar, no digo todas, pero s? 2 ? 3
>>>>> BB.DD. en un programa sin complicarse la existencia.
>>>>>
>>>> Con imaginación puedes solventar muchos escollos. Estoy seguro de
>>>> ello. Pero imaginar cuesta tiempo... y además luego has de acordarte de
>>>> lo imaginado para sueño por que si no... puede llegar a ser una
>>>> pesadilla (José, permíteme este juego de palabras sin ánimo de ofender
>>>> ni nada por el
>>>> estilo).
>>>>
>>>> Saludos,
>>>> José Luis Capel
>>>>
>>
>>