Como diseñar Base de Datos MS-SQL Server
514 views
Skip to first unread message
Fabricio
Oct 11, 2010, 1:47:55 PM10/11/10
to Comunidad de Visual Foxpro en Español
Hola Amigos, hasta la fecha he usado tablas libres en mis sistemas y
en algunos .DBC, pero ahora estoy pensando en utilizar MS-SQL Server,
así que quiero la ayuda y los consejos de los expertos o
experimentados.
Yo desarrollo conjuntos de sistemas, por ejemplo:
- Contabilidad General y Emisión de Cheques
- Inventarios, Facturación y Cuentas por Cobrar
- Facturación de Servicios
- Inventarios de Suministros
- Activos Fijos
Cada uno de esos sistemas o conjuntos, tienen sus propias .DBF, cada
uno está instalado en una carpeta aparte, todos ellos hacen referencia
a la Contabilidad General para la interfase contable o a los sistemas
que sean necesarios.
Esto me facilita comercializar cada uno de ellos como un sistema por
separado y llenar las necesidades específicas de cada cliente en
particular, me permite venderlos a un precio menor que en lugar de
vender un sistema completo por un precio más elevado.
Ahora que quiero empezar a usar SQL, me surgen las preguntas:
- Cómo debo diseñar mi base de datos?
- Debo hacer una sola base de datos?
- Puedo manejar una base de datos para cada sistema?
- Puedo interconectar esas bases de datos entre sí?
- Qué es lo más idóneo o recomendable?
- Cuál es el diseño más adecuado o apropiado?
Espero sus valiosos comentarios al respecto
Si alguno tiene algún documento que me sirva de referencia puede
enviármelo al correo fabricio...@hotmail.com
Desde ya muchas gracias a todos.
en algunos .DBC, pero ahora estoy pensando en utilizar MS-SQL Server,
así que quiero la ayuda y los consejos de los expertos o
experimentados.
Yo desarrollo conjuntos de sistemas, por ejemplo:
- Contabilidad General y Emisión de Cheques
- Inventarios, Facturación y Cuentas por Cobrar
- Facturación de Servicios
- Inventarios de Suministros
- Activos Fijos
Cada uno de esos sistemas o conjuntos, tienen sus propias .DBF, cada
uno está instalado en una carpeta aparte, todos ellos hacen referencia
a la Contabilidad General para la interfase contable o a los sistemas
que sean necesarios.
Esto me facilita comercializar cada uno de ellos como un sistema por
separado y llenar las necesidades específicas de cada cliente en
particular, me permite venderlos a un precio menor que en lugar de
vender un sistema completo por un precio más elevado.
Ahora que quiero empezar a usar SQL, me surgen las preguntas:
- Cómo debo diseñar mi base de datos?
- Debo hacer una sola base de datos?
- Puedo manejar una base de datos para cada sistema?
- Puedo interconectar esas bases de datos entre sí?
- Qué es lo más idóneo o recomendable?
- Cuál es el diseño más adecuado o apropiado?
Espero sus valiosos comentarios al respecto
Si alguno tiene algún documento que me sirva de referencia puede
enviármelo al correo fabricio...@hotmail.com
Desde ya muchas gracias a todos.
Walter R. Ojeda Valiente
Oct 11, 2010, 6:34:02 PM10/11/10
to publice...@googlegroups.com
Hola Fabricio
Primero, debo decirte que lo que pretendes hacer te llevará mucho tiempo y deberías sopesar si vale la pena. Suponiendo que así sea:
- Una estructura similar a la de tus tablas libres usarás en tus tablas SQL
- Puedes tener:
a. una sola base de datos para todos los sistemas, o
b. una base de datos para cada sistema, o
c. una base de datos con todas las tablas generales y luego bases de datos para cada sistema en particular
c1. En la base de datos GENERALES (o nombre similar) deberías tener las tablas cuyos datos comparten varios sistemas (como SUCURSALES, CLIENTES, PROVEEDORES, TIPOS DE DOCUMENTOS, etc.)
c2. En la base de datos INVENTARIOS deberías tener las tablas que solamente se utilizan en el módulo de inventarios. Y así con las demás.
- Yo prefiero la opción c., ya que eso me asegura que las tablas generales tengan siempre la misma estructura. Si eliges la opción b. podría darse el caso que la tabla SUCURSALES de un sistema sea distinta que la tabla SUCURSALES de otro sistema y eso alguna vez podría complicarte la vida. Y si eliges la opción a., en tu base de datos tendrás tablas que muchos sistemas jamás usarán.
- Si alguna de tus tablas no cumple con la integridad referencial, es buen momento para que lo hagan.
- Trata de programar lo máximo que puedas dentro de los triggers y los stored procedures, allí debería estar toda la lógica de tus sistemas, el Visual FoxPro deberías usar para mostrar las pantallas, los informes y muy poco más. Todo (o casi todo) el procesamiento debería ocurrir dentro de tus bases de datos.
Saludos.
Walter.
Primero, debo decirte que lo que pretendes hacer te llevará mucho tiempo y deberías sopesar si vale la pena. Suponiendo que así sea:
- Una estructura similar a la de tus tablas libres usarás en tus tablas SQL
- Puedes tener:
a. una sola base de datos para todos los sistemas, o
b. una base de datos para cada sistema, o
c. una base de datos con todas las tablas generales y luego bases de datos para cada sistema en particular
c1. En la base de datos GENERALES (o nombre similar) deberías tener las tablas cuyos datos comparten varios sistemas (como SUCURSALES, CLIENTES, PROVEEDORES, TIPOS DE DOCUMENTOS, etc.)
c2. En la base de datos INVENTARIOS deberías tener las tablas que solamente se utilizan en el módulo de inventarios. Y así con las demás.
- Yo prefiero la opción c., ya que eso me asegura que las tablas generales tengan siempre la misma estructura. Si eliges la opción b. podría darse el caso que la tabla SUCURSALES de un sistema sea distinta que la tabla SUCURSALES de otro sistema y eso alguna vez podría complicarte la vida. Y si eliges la opción a., en tu base de datos tendrás tablas que muchos sistemas jamás usarán.
- Si alguna de tus tablas no cumple con la integridad referencial, es buen momento para que lo hagan.
- Trata de programar lo máximo que puedas dentro de los triggers y los stored procedures, allí debería estar toda la lógica de tus sistemas, el Visual FoxPro deberías usar para mostrar las pantallas, los informes y muy poco más. Todo (o casi todo) el procesamiento debería ocurrir dentro de tus bases de datos.
Saludos.
Walter.
Fabricio
Oct 11, 2010, 8:42:11 PM10/11/10
to Comunidad de Visual Foxpro en Español
Hola Walter,
Me gusta la opción C es el escenario más flexible que puede diseñarse,
como no tengo experiencia con SQL, no se si se puede establecer
integridad relacional entre tablas de dos bases de datos diferentes,
por ejemplo la tabla clientes estaría en la base de datos generales,
se necesita integridad relacional para evitar que borren clientes que
tengan registros en facturación o cuentas por cobrar por ejemplo, esto
puede hacerse en SQL? de lo contrario tendría que quedarme con la
opción A.
Otra opción que he visto, es que hay algunos desarrollan un sistema
completo y al momento de venderlo desactivan los módulos que el
cliente no compra, de tal forma que dentro del .EXE está todo el
código y en la base de datos las tablas de los módulos desactivado,
que opinas al respecto? tú como acostumbras hacerlo?
Muchas gracias por tus comentarios Walter.
Me gusta la opción C es el escenario más flexible que puede diseñarse,
como no tengo experiencia con SQL, no se si se puede establecer
integridad relacional entre tablas de dos bases de datos diferentes,
por ejemplo la tabla clientes estaría en la base de datos generales,
se necesita integridad relacional para evitar que borren clientes que
tengan registros en facturación o cuentas por cobrar por ejemplo, esto
puede hacerse en SQL? de lo contrario tendría que quedarme con la
opción A.
Otra opción que he visto, es que hay algunos desarrollan un sistema
completo y al momento de venderlo desactivan los módulos que el
cliente no compra, de tal forma que dentro del .EXE está todo el
código y en la base de datos las tablas de los módulos desactivado,
que opinas al respecto? tú como acostumbras hacerlo?
Muchas gracias por tus comentarios Walter.
Walter R. Ojeda Valiente
Oct 12, 2010, 12:34:43 AM10/12/10
to publice...@googlegroups.com
Hola Fabricio
Mi experiencia con SQL se basa mayormente en Firebird, de eso es lo que te puedo comentar con más conocimientos de causa. He trabajado un poco con MySQL, pero mucho menos.
En Firebird dentro de los triggers y los stored procedures se puede hacer referencias a tablas de otras bases de datos y yo hago de esa manera para asegurarme que no se borre un código que tuvo movimientos.
O sea, si alguien quiere borrar un cliente verifico que no haya tenido movimientos en la base de datos que guarda los movimientos (ventas, cobranzas, etc.) y de acuerdo a eso, permito o no que sea borrado. Es algo manual, pero funciona bien.
Con respecto a tener un solo sistema monolítico que haga de todo, desactivando los módulos que el cliente no compró, no me gusta la idea. He visto que es frecuente entre los yanquis hacer de esa manera, pero yo prefiero hacer un sistema específico para cada tarea. Para facilitarme la vida, tengo varios .PRG con clases, rutinas y funciones de uso general. También varios forms generales. O sea, sea cual sea el sistema siempre usan el mismo código. En caso de hacerle un cambio es cuestión de recompilar para actualizar.
Por ejemplo, cuando hay que mostrar un mensaje de error, todos los sistemas llaman a exactamente la misma rutina la cual llama a exactamente el mismo formulario. Cuando quiero pasar de letras a números, todos llaman a la misma función. Cuando quiero leer un archivo .INI también. Y así sucesivamente.
Creo que hacer un solo sistema monolítico requiere de mucho más trabajo de análisis, diseño y programación que hacerlo por separado. Y el riesgo que corres si te lo decompilan es mayor. Pero si está bien hecho podrías ganar más dinero que teniéndolos por separado, ya que tu cliente constantemente estará viendo que tu sistema tiene otros módulos y podría entrarle el interés de comprarlos.
Es cuestión de gustos.
Saludos.
Walter.
Mi experiencia con SQL se basa mayormente en Firebird, de eso es lo que te puedo comentar con más conocimientos de causa. He trabajado un poco con MySQL, pero mucho menos.
En Firebird dentro de los triggers y los stored procedures se puede hacer referencias a tablas de otras bases de datos y yo hago de esa manera para asegurarme que no se borre un código que tuvo movimientos.
O sea, si alguien quiere borrar un cliente verifico que no haya tenido movimientos en la base de datos que guarda los movimientos (ventas, cobranzas, etc.) y de acuerdo a eso, permito o no que sea borrado. Es algo manual, pero funciona bien.
Con respecto a tener un solo sistema monolítico que haga de todo, desactivando los módulos que el cliente no compró, no me gusta la idea. He visto que es frecuente entre los yanquis hacer de esa manera, pero yo prefiero hacer un sistema específico para cada tarea. Para facilitarme la vida, tengo varios .PRG con clases, rutinas y funciones de uso general. También varios forms generales. O sea, sea cual sea el sistema siempre usan el mismo código. En caso de hacerle un cambio es cuestión de recompilar para actualizar.
Por ejemplo, cuando hay que mostrar un mensaje de error, todos los sistemas llaman a exactamente la misma rutina la cual llama a exactamente el mismo formulario. Cuando quiero pasar de letras a números, todos llaman a la misma función. Cuando quiero leer un archivo .INI también. Y así sucesivamente.
Creo que hacer un solo sistema monolítico requiere de mucho más trabajo de análisis, diseño y programación que hacerlo por separado. Y el riesgo que corres si te lo decompilan es mayor. Pero si está bien hecho podrías ganar más dinero que teniéndolos por separado, ya que tu cliente constantemente estará viendo que tu sistema tiene otros módulos y podría entrarle el interés de comprarlos.
Es cuestión de gustos.
Saludos.
Walter.
carlos SALCEDO
Oct 12, 2010, 7:09:16 AM10/12/10
to publice...@googlegroups.com
Hola fabricio
Como aporte te comento, que tengo la experiencia con dos sistemas
pero que cuentan con otros modulos y el diseño es algo como lo que dice walter
pero asi:
1.una base de datos para el negocio(inventario,contabilidad etc)
2. Otra para administrar la primera, por que el software esta echo para que aun los
menus se pueden agregar,elegir el servidor,crear otras empresas etc
Bendiciones
Carlos
From: wr...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Como diseñar Base de Datos MS-SQL Server
Date: Mon, 11 Oct 2010 22:34:02 +0000
Luis Mata
Oct 12, 2010, 9:09:11 AM10/12/10
to publice...@googlegroups.com
Con una sola BD te ahorras mucho trabajo, ya que los
reportes son mucho mas faciles de generar y las consultas tambien.
el seguimiento de datos es mucho mas facil, la
consolidacion es mucho mas facil:
Rcomiendo la siguiente estructura
Empresa
Sucursal
Almacenes
este para un caso de sistema comercial
pero para todos los casos el codigo de empresa debe de
estar sobre todo ya que hay empresas que tienen sub-empresas, y cada empresa
tiene sucursales y las sucursales tienen almacenes.
Hacer un BD es un Arte.
Luis
Miguel Antúnez
Oct 12, 2010, 10:14:46 AM10/12/10
to publice...@googlegroups.com
Bien dicho, hacer una base de datos es un Arte.
Para este fin en mi caso uso una herramienta de diseño llamado visual paradigm, me ayuda mucho a diseñar aparte que ya te genera el script. para diferentes tipos de base de datos.
hay que tener en cuenta siempre la formas normales, en algunos de los casos no apegarse mucho a la teoría.
Siempre tengo en cuenta en todas mis tablas una columna como primary key y de tipo identity a menos que vaya a ser una tabla que este. con replicación tipo update.
tenere en cuenta la integridad referencial, los campos con valores con defecto, las constraints, los campos de tipos calculados, las claves unicas, etc.
Saludos y suerte.
--
Miguel Angel Antúnez Camones
Especialista en SQL Server
mant...@frenosa.com.pe
mant...@gmail.com
miguel_...@msn.com
Cel. 997914428
Microsoft Active Professional
Membresía FY10-04-0745
Miguel Angel Antúnez Camones
Especialista en SQL Server
mant...@frenosa.com.pe
mant...@gmail.com
miguel_...@msn.com
Cel. 997914428
Microsoft Active Professional
Membresía FY10-04-0745
Fabricio
Oct 12, 2010, 10:48:06 AM10/12/10
to Comunidad de Visual Foxpro en Español
Hola Carlos
No entiendo muy bien lo de crear una base de datos para administrar la
otra, podrías ampliar un poco, te lo agradeceré.
Fabricio
No entiendo muy bien lo de crear una base de datos para administrar la
otra, podrías ampliar un poco, te lo agradeceré.
Fabricio
Fabricio
Oct 12, 2010, 10:54:23 AM10/12/10
to Comunidad de Visual Foxpro en Español
Les comento que la única experiencia que he tenido con bases de datos
ha sido con bases de datos de access, en una empresa teníamos dos
bases de datos :MDB, una para Contabilidad y otra para el resto de
sistemas (compras, inventarios, facturacion, cuentas por cobrar,
cuentas por pagar, etc.) en esta segunda se hacia referencia a tablas
de la de Contabilidad para poder generar los asientos de diario y
otras cosas.
Luego se diseñó cada módulo por separado donde estaba el código
fuente, y se vinculaban las tablas de una o de las dos bases de datos,
y además se agregaban las tablas temporales para cada módulo.
No tengo idea de como hacer algo parecido en SQL, tengo entendido que
MS-SQL, MySQL, y otros son muy similares, yo me estoy decidiendo por
MS-SQL Server en versión Express, que puede descargarse gratuitamente,
me imagino que los otros tienen sus bondades, me gustaría me dijeran
que opinan de ellos, me han dicho que MS-SQL es el que tiene la mejor
interfase para administrarlo, no s si sea cierto.
Muchas gracias a todos por sus aportes, estoy tomando nota para
ayudarme a decidir de que manera debo diseñar la base de datos.
ha sido con bases de datos de access, en una empresa teníamos dos
bases de datos :MDB, una para Contabilidad y otra para el resto de
sistemas (compras, inventarios, facturacion, cuentas por cobrar,
cuentas por pagar, etc.) en esta segunda se hacia referencia a tablas
de la de Contabilidad para poder generar los asientos de diario y
otras cosas.
Luego se diseñó cada módulo por separado donde estaba el código
fuente, y se vinculaban las tablas de una o de las dos bases de datos,
y además se agregaban las tablas temporales para cada módulo.
No tengo idea de como hacer algo parecido en SQL, tengo entendido que
MS-SQL, MySQL, y otros son muy similares, yo me estoy decidiendo por
MS-SQL Server en versión Express, que puede descargarse gratuitamente,
me imagino que los otros tienen sus bondades, me gustaría me dijeran
que opinan de ellos, me han dicho que MS-SQL es el que tiene la mejor
interfase para administrarlo, no s si sea cierto.
Muchas gracias a todos por sus aportes, estoy tomando nota para
ayudarme a decidir de que manera debo diseñar la base de datos.
carlos SALCEDO
Oct 12, 2010, 10:56:28 AM10/12/10
to publice...@googlegroups.com
Fabricio
El sistema esta hecho de tal forma que quien lo compra
puede Crear sus propios submenus,agregar programas(Vfp)
Crear sucursales,bodegas,etc
La admin contiene,modulos,usuarios,menus mejor dicho
toda la estructura de la otra
la ofima contiene el negocio como tal
Movimiento
detamovimiento
docuemtos
saldos
etc,etc
Ahora esto porque se vende de esa forma pero tu puedes logras lo mismo
con una sola. Anteponiedole a cada tabla el modulo al que pertenece
y cada modulo lo puedes hacer por separado
Bendiciones
Carlos
> Date: Tue, 12 Oct 2010 07:48:06 -0700
> Subject: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
> From: fabricio...@hotmail.com
> To: publice...@googlegroups.com
Luis Mata
Oct 12, 2010, 10:09:26 AM10/12/10
to publice...@googlegroups.com
Tambien se debe de tener en cuenta que si se tiene mas de
1 Base de Datos no podras relacionarlas entre si y esa es una desventaja muy
grande.
Luis
----- Original Message -----From: carlos SALCEDO
Alan Cybar
Oct 12, 2010, 11:06:39 AM10/12/10
to publice...@googlegroups.com
Podes trabajar con los esquemas para no crear dos BD.
Por ejemplo un esquema sistema y otro datos, o movimientos, ya queda a
tu criterio como llamarlas para diferenciarlas.
Por ejemplo un esquema sistema y otro datos, o movimientos, ya queda a
tu criterio como llamarlas para diferenciarlas.
Alan
carlos SALCEDO
Oct 12, 2010, 11:35:09 AM10/12/10
to publice...@googlegroups.com
Hola Fabricio
Bueno con respecto a esto te digo lo siquiente
1.Aquien va orientado el software?, Sqlserver implica un matrimonio
con windows y si tu programa es bueno y se interesan empresas
con server Linux? .
2.El tamaño de la aplicacion Sqlserver 2008r2 express te "regala"
10 Gb de almacenamiento - si la db crece seriamente?
3.Sqlserver tiene buenas herramientas administrativas
en el corto tiempo que llevo cacharreandola me di cuenta de lo siquiente
- El agente esta desabilitado ese es el que hace los backup automaticos
- No trabaja comprimida (la express)
por lo demas bien
4.las otras tambien tienen buenas siendo que no son tan windows
Espero que los demas colegas tambien tre aporte para que tomes
la decision que mas te conbenga a ti
Bendiciones
Carlos
> Date: Tue, 12 Oct 2010 07:54:23 -0700
> Subject: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
> From: fabricio...@hotmail.com
> To: publice...@googlegroups.com
Bueno con respecto a esto te digo lo siquiente
1.Aquien va orientado el software?, Sqlserver implica un matrimonio
con windows y si tu programa es bueno y se interesan empresas
con server Linux? .
2.El tamaño de la aplicacion Sqlserver 2008r2 express te "regala"
10 Gb de almacenamiento - si la db crece seriamente?
3.Sqlserver tiene buenas herramientas administrativas
en el corto tiempo que llevo cacharreandola me di cuenta de lo siquiente
- El agente esta desabilitado ese es el que hace los backup automaticos
- No trabaja comprimida (la express)
por lo demas bien
4.las otras tambien tienen buenas siendo que no son tan windows
Espero que los demas colegas tambien tre aporte para que tomes
la decision que mas te conbenga a ti
Bendiciones
Carlos
> Date: Tue, 12 Oct 2010 07:54:23 -0700
> Subject: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
> From: fabricio...@hotmail.com
> To: publice...@googlegroups.com
Fabricio
Oct 12, 2010, 1:16:36 PM10/12/10
to Comunidad de Visual Foxpro en Español
Los sistemas estan enfocados para verderselos a quien los necesite, en
mi experiencia me ha dado resultados vender cada módulo por separado
por que representa una inversión menor para el cliente y satisface la
necesidad inmediata, con el tiempo compra otro módulo dependiendo de
lo que necesite, los módulos comparten algunas tablas e interactuan
entre si de ser necesario.
Ahora he decidido trabajar con un motor de base de datos, quiero que
mis nuevos sistemas estén desarrollados en capas o niveles, que tengan
un buen motor de bases de datos que evite los inconvenientes de
los .dbf nativos de VFP.
No se cuál motor es el que me convenga más, Carlos tiene razón en
cuanto que la versión express de MS-SQL Server tiene sus limitaciones,
las que no había tomado en cuenta, pero aún no se cual motor sea el
más adecuado, no tengo experiencia con ninguno, por eso recurrí al
foro para escuchar sus valiosos comentarios de las experiencias que
han tenido.
En el caso de los scheme no tengo idea de eso, voy a buscar en el web
y documentarme al respecto.
Gracias nuevamente.
mi experiencia me ha dado resultados vender cada módulo por separado
por que representa una inversión menor para el cliente y satisface la
necesidad inmediata, con el tiempo compra otro módulo dependiendo de
lo que necesite, los módulos comparten algunas tablas e interactuan
entre si de ser necesario.
Ahora he decidido trabajar con un motor de base de datos, quiero que
mis nuevos sistemas estén desarrollados en capas o niveles, que tengan
un buen motor de bases de datos que evite los inconvenientes de
los .dbf nativos de VFP.
No se cuál motor es el que me convenga más, Carlos tiene razón en
cuanto que la versión express de MS-SQL Server tiene sus limitaciones,
las que no había tomado en cuenta, pero aún no se cual motor sea el
más adecuado, no tengo experiencia con ninguno, por eso recurrí al
foro para escuchar sus valiosos comentarios de las experiencias que
han tenido.
En el caso de los scheme no tengo idea de eso, voy a buscar en el web
y documentarme al respecto.
Gracias nuevamente.
Victor Espina
Oct 12, 2010, 2:56:52 PM10/12/10
to Comunidad de Visual Foxpro en Español
Hola Fabricio.
El salto que piensas hacer es bastante grande. Programar para cliente
servidor, sea con SQL Server, Firebird, MySql o el que sea, es
bastante distinto de programar para DBFs.
Dicho esto, he aqui mis recomendaciones:
1) Usa una sola base de datos para todos tus modulos. Como bien
comenta carlos, tener las tablas desperdigadas en dos o mas BDs evita
que puedas hacer uso extensivo de la integridad referencial, mientras
que por otra parte el usar varias bases de datos no te aporta
realmente ningun beneficio.
2) En cuanto al motor a utilizar, todo depende del mercado al que va
dirigido tu producto. Por lo que comentas, se deduce que tu principal
target son los pequenos negocios. En mi experiencia, este tipo de
clientes SIEMPRE usan equipos con Windows, por lo que la posibilidad
de que pierdas una venta por no tener algo que corra en Linux es poca.
E incluso en ese caso, puedes echar mano de soluciones de
virtualizacion gratuitas como Virtual Box para correr un server WinXP
virtual donde corra tu BD, todo esto dentro del servidor Linux.
3) Para el tipo de cliente al que van dirigidos tus productos, mi
recomendacion es que te vayas con SQL Server Express 2008 R2. Un
cliente tiene que generar MUCHISIMA data para superar el limite de 10
GB que te da esa BD. Yo tengo un cliente mediano que lleva mas de 5
anos corriendo un ERP sobre SQL Server Express y aun no ha llegado a
los 2 GB de espacio consumido (claro, genera poco movimiento de ventas
y compras mensuales por su tipo de negocio). SQL Server es un
producto robusto, que te da un excelente rendimiento para un ambiente
de 10 usuarios o menos que no necesitan manejar cientos de gbs de
data. Las herramientas de administracion son muy buenas y VFP se
integra mejor con SQL Server que con otras opciones como PostgreSQL.
4) Monolitico o apps separadas? mi recomendacion es que mientras menos
devision mas facil es darle mantenimiento. El tema de activar o
desactivar funciones se puede manejar de forma muy sencilla a traves
de la licencia, y el riesgo de decompilacion es el mismo tanto si
tiene una aplicacion como si las tiene todas. Sin embargo, esto
depende en gran medida del gusto de cada quien. Lo importante es que
trates de evitar COMO A LA PESTE la duplicacion de codigo.
5) Si no estas familiarizado con la OOP, AHORA ES EL MOMENTO!!! La
mejor forma de encarar un proyecto como este es aplicar al maximo la
OOP y aprovecharte de sus beneficios. Un consejo? aprende sobre Design
Patterns. Si no tienes problemas con el ingles, Steven Black ha
escrito varios articulos excelentes sobre la aplicacion de varios
Design Patterns en VFP: http://www.stevenblack.com/PTN-HookOperations.html
6) Utiliza un esquema offline. Abre la conexion con el servidor
UNICAMENTE durante el tiempo minimo necesario y luego cierrala
inmediatamente. Esto no solo ahorra recursos en el servidor (cada
conexion abierta con el servidor de datos implica una cierta cantidad
de memoria del servidor) sino que reduce al minimo los problemas por
fallas en la conexion. Esto es de VITAL IMPORTANCIA en el caso que
tengas clientes que puedan querer utilizar Internet como medio de
transporte para conectar sus sucursales.
7) Aprende sobre PL/SQL y Stored Procedures. Una de las tecnicas mas
efectivas para programar aplicaciones cliente-servidor es utilizar
EXCLUSIVAMENTE stored procedures para los accesos a las BDs. Esto
implica, por ejemplo, que en lugar de usar un INSERT directametne
sobre la BD, o utilizar DataAdapters y Remote Views, lo que haces es
invocar un stored procedure que sea especifico para lo que quieras
hacer, por ejemplo, crear un cliente o iniciar una factura de venta.
Este enfoque, aunque mas trabajoso, te brinda dos ventajas
importantisimas:
1) Al separar la presentacion (tu programa) del acceso a los datos
(los stored procedures), puedes crear rapidamente otra capa de
presentacion (por ejmplo una aplicacion Web) y reutilizar todo tu
codigo de acceso a datos.
2) Puedes realizar versiones especiales de los stored procedures que
se adapten aa las necesidades especificas de un cliente, sin necesidad
de modificar el codigo de tu aplicacion.
Bueno, ests son solo algunas recomendaciones basadas en mi experiencia
con VFP y SQL Server. Espero te sean de utilidad.
Victor Espina
> enviármelo al correo fabricio.sando...@hotmail.com
El salto que piensas hacer es bastante grande. Programar para cliente
servidor, sea con SQL Server, Firebird, MySql o el que sea, es
bastante distinto de programar para DBFs.
Dicho esto, he aqui mis recomendaciones:
1) Usa una sola base de datos para todos tus modulos. Como bien
comenta carlos, tener las tablas desperdigadas en dos o mas BDs evita
que puedas hacer uso extensivo de la integridad referencial, mientras
que por otra parte el usar varias bases de datos no te aporta
realmente ningun beneficio.
2) En cuanto al motor a utilizar, todo depende del mercado al que va
dirigido tu producto. Por lo que comentas, se deduce que tu principal
target son los pequenos negocios. En mi experiencia, este tipo de
clientes SIEMPRE usan equipos con Windows, por lo que la posibilidad
de que pierdas una venta por no tener algo que corra en Linux es poca.
E incluso en ese caso, puedes echar mano de soluciones de
virtualizacion gratuitas como Virtual Box para correr un server WinXP
virtual donde corra tu BD, todo esto dentro del servidor Linux.
3) Para el tipo de cliente al que van dirigidos tus productos, mi
recomendacion es que te vayas con SQL Server Express 2008 R2. Un
cliente tiene que generar MUCHISIMA data para superar el limite de 10
GB que te da esa BD. Yo tengo un cliente mediano que lleva mas de 5
anos corriendo un ERP sobre SQL Server Express y aun no ha llegado a
los 2 GB de espacio consumido (claro, genera poco movimiento de ventas
y compras mensuales por su tipo de negocio). SQL Server es un
producto robusto, que te da un excelente rendimiento para un ambiente
de 10 usuarios o menos que no necesitan manejar cientos de gbs de
data. Las herramientas de administracion son muy buenas y VFP se
integra mejor con SQL Server que con otras opciones como PostgreSQL.
4) Monolitico o apps separadas? mi recomendacion es que mientras menos
devision mas facil es darle mantenimiento. El tema de activar o
desactivar funciones se puede manejar de forma muy sencilla a traves
de la licencia, y el riesgo de decompilacion es el mismo tanto si
tiene una aplicacion como si las tiene todas. Sin embargo, esto
depende en gran medida del gusto de cada quien. Lo importante es que
trates de evitar COMO A LA PESTE la duplicacion de codigo.
5) Si no estas familiarizado con la OOP, AHORA ES EL MOMENTO!!! La
mejor forma de encarar un proyecto como este es aplicar al maximo la
OOP y aprovecharte de sus beneficios. Un consejo? aprende sobre Design
Patterns. Si no tienes problemas con el ingles, Steven Black ha
escrito varios articulos excelentes sobre la aplicacion de varios
Design Patterns en VFP: http://www.stevenblack.com/PTN-HookOperations.html
6) Utiliza un esquema offline. Abre la conexion con el servidor
UNICAMENTE durante el tiempo minimo necesario y luego cierrala
inmediatamente. Esto no solo ahorra recursos en el servidor (cada
conexion abierta con el servidor de datos implica una cierta cantidad
de memoria del servidor) sino que reduce al minimo los problemas por
fallas en la conexion. Esto es de VITAL IMPORTANCIA en el caso que
tengas clientes que puedan querer utilizar Internet como medio de
transporte para conectar sus sucursales.
7) Aprende sobre PL/SQL y Stored Procedures. Una de las tecnicas mas
efectivas para programar aplicaciones cliente-servidor es utilizar
EXCLUSIVAMENTE stored procedures para los accesos a las BDs. Esto
implica, por ejemplo, que en lugar de usar un INSERT directametne
sobre la BD, o utilizar DataAdapters y Remote Views, lo que haces es
invocar un stored procedure que sea especifico para lo que quieras
hacer, por ejemplo, crear un cliente o iniciar una factura de venta.
Este enfoque, aunque mas trabajoso, te brinda dos ventajas
importantisimas:
1) Al separar la presentacion (tu programa) del acceso a los datos
(los stored procedures), puedes crear rapidamente otra capa de
presentacion (por ejmplo una aplicacion Web) y reutilizar todo tu
codigo de acceso a datos.
2) Puedes realizar versiones especiales de los stored procedures que
se adapten aa las necesidades especificas de un cliente, sin necesidad
de modificar el codigo de tu aplicacion.
Bueno, ests son solo algunas recomendaciones basadas en mi experiencia
con VFP y SQL Server. Espero te sean de utilidad.
Victor Espina
carlos SALCEDO
Oct 12, 2010, 3:35:38 PM10/12/10
to publice...@googlegroups.com
Bueno
Yo te hare una serie de recomendaciones con respecto a mi
experiencia, se que algunos colegas aportaran la suya y tomaras
la mejor desicion.
1.Piensa en la mixtura de herramientas, esto significa una base de datos
que puedas manejarse de forma poderosa, independientemente del
lenguaje o sistema operativo que la consulte.
2.Hoy El desarroyo web esta en su apogeo, maxime cuando los celulares
ya pueden acceder a las paginas via navegador una base de datos que se
Trabaje facil con PHP es importante
3.Piensa en el futuro, bd como mysql,mariadb etc no tienen su futuro tan claro
4.La riquesa del lenguaje.Es en este punto donde le pondre nombre propio
a mi inclinacion en bd - POSTRESQL Y FIREBIRD, son dos bd serias maduras
free, con exelente documentacion, no son de origen windows lo que les
garantiza independencia.
En Caso de postgresql que es mi experiencia puedes escribir codigo dentro del motor con diferentes lenguajes
esto ayuda un mundo.
5.Claro no todo es bueno, la curva de aprendisaje sobre todo para los que tienen toda la experiencia en
Windows es mayor, sobres todo que la mayoria de las cosas no se hacen con un click aqui y un doble click por alla
Algunas cosas debemos escribirlas, pero te aseguro que por muy intrincada que sea la situacion ya alquien la soluciono
Esas son mis recomendaciones espero te sirvan
Bendiciones
Carlos
> Date: Tue, 12 Oct 2010 10:16:36 -0700
Yo te hare una serie de recomendaciones con respecto a mi
experiencia, se que algunos colegas aportaran la suya y tomaras
la mejor desicion.
1.Piensa en la mixtura de herramientas, esto significa una base de datos
que puedas manejarse de forma poderosa, independientemente del
lenguaje o sistema operativo que la consulte.
2.Hoy El desarroyo web esta en su apogeo, maxime cuando los celulares
ya pueden acceder a las paginas via navegador una base de datos que se
Trabaje facil con PHP es importante
3.Piensa en el futuro, bd como mysql,mariadb etc no tienen su futuro tan claro
4.La riquesa del lenguaje.Es en este punto donde le pondre nombre propio
a mi inclinacion en bd - POSTRESQL Y FIREBIRD, son dos bd serias maduras
free, con exelente documentacion, no son de origen windows lo que les
garantiza independencia.
En Caso de postgresql que es mi experiencia puedes escribir codigo dentro del motor con diferentes lenguajes
esto ayuda un mundo.
5.Claro no todo es bueno, la curva de aprendisaje sobre todo para los que tienen toda la experiencia en
Windows es mayor, sobres todo que la mayoria de las cosas no se hacen con un click aqui y un doble click por alla
Algunas cosas debemos escribirlas, pero te aseguro que por muy intrincada que sea la situacion ya alquien la soluciono
Esas son mis recomendaciones espero te sirvan
Bendiciones
Carlos
> Date: Tue, 12 Oct 2010 10:16:36 -0700
> Subject: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
> From: fabricio...@hotmail.com
> To: publice...@googlegroups.com
>
Armando Rodríguez
Oct 12, 2010, 4:14:16 PM10/12/10
to publice...@googlegroups.com
Excelente exposición Victor, muy enriquecedora.
Saludos
Armando R.
-----Mensaje original-----
De: publice...@googlegroups.com
[mailto:publice...@googlegroups.com] En nombre de Victor Espina
Enviado el: Martes, 12 de Octubre de 2010 01:57 p.m.
Para: Comunidad de Visual Foxpro en Español
Asunto: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
Miguel Antúnez
Oct 12, 2010, 5:44:09 PM10/12/10
to publice...@googlegroups.com
ahí te envió un pequeño manual de como programa vfp con sql server.
Saludos
Walter R. Ojeda Valiente
Oct 12, 2010, 11:58:37 PM10/12/10
to publice...@googlegroups.com
Hola Fabricio
Te recomiendo Firebird, no te arrepentirás.
Tiene todo lo que necesitas y aún más de lo que puedes necesitar. Es estable, fácil, poderoso, seguro, completo y ... totalmente gratis.
Te detallo algunas de sus características principales:
- Funciona en Windows, Linux, Mac, Solaris, HP-UX y varios otros UNIX-like. Hacer la migración de una plataforma a otra es demasiado fácil, sólo haces un backup y lo restauras.
- Puedes conectarte mediante ODBC, JDBC, PHP, Perl, Python, OLEDB, dbExpress, proveedor .NET y mediante llamadas directas a la API
- El tamaño máximo de una base de datos es de hasta 64 terabytes (64.000 gigabytes o 64.000.000 de megabytes), pero como puedes partir una base de datos en dos o más partes, en la práctica no hay un límite.
- Cumple totalmente con A.C.I.D. (Atomicity, Consistency, Isolation and Durability). Las mejores bases de datos SQL deben cumplir con A.C.I.D.
- Tiene la arquitectura M.G.A. (MultiGenerational Arquitecture). Lo que eso significa es: "los lectores no bloquean a los escritores y los escritores no bloquean a los lectores". O sea, no necesitas estar bloqueando registros, el Firebird se encarga de mantenerlos actualizados correctamente.
- Permite que varios clientes accedan a varias bases de datos al mismo tiempo
- Tiene procedimientos almacenados comunes
- Tiene procedimientos almacenados que pueden devolver sus resultados a sentencias SELECT. Muy útiles para las consultas y los reportes.
- Tiene triggers, para antes y después de insertar, borrar, modificar registros. También puedes tener un solo trigger que maneje todas esas operaciones.
- Puedes programarle eventos, los cuales pueden ser monitoreados desde el lado del cliente
- Tiene generadores independientes de las transacciones, eso por ejemplo te permite obtener valores únicos para columnas autoincrementales
- Tiene bases de datos de sólo lectura, útiles para programas demo o catálogos
- Control completo de transacciones. Una sola aplicación puede tener muchas transacciones, los niveles de aislamiento pueden ser controlados por el cliente, tienes bloqueo optimístico y savepoints
- Backups en línea. Puedes hacer el backup de tus bases de datos mientras los usuarios las están utilizando a full. O sea, te permite que trabajen 24/7 e igual tienes tus backups.
- Funciones externas. Te permite usar funciones escritas en C, C++, Delphi, o cualquier lenguaje que genere DLLs.
- Integridad referencial. Para no dejar registros huérfanos. Puedes actualizar en cascada.
- Acepta casi todos los lenguajes humanos (castellano, portugués, turco, chino y decenas más)
- El motor ocupa muy poco espacio. Se lo instala y se lo usa, no se debe estar configurándolo.
- No se necesita de un administrador para la base de datos, porque su uso es demasiado sencillo
- Puede utilizar todos los procesadores de la computadora donde está el Servidor
- Tiene replicación. O sea que puedes tener tus datos en varias bases de datos al mismo tiempo. Eso puede aumentar la disponibilidad y la velocidad de acceso.
- Mucha documentación
- Foros y grupos de usuarios
Particularmente le he hecho muchas pruebas, con muchas tablas y con muchos registros en cada una de ellas. Apagué las computadoras, las reseteé, desconecté el router, etc. Hice eso mientras se insertaban, borraban, modificaban y consultaban datos. Jamás encontré el mínimo problema, jamás perdí un solo registro ni encontré un índice dañado. O sea, eso me da mucha confianza en el Firebird.
En fin, deberías probarlo durante unos días antes de decidirte por éste o por otro.
Saludos.
Walter.
Te recomiendo Firebird, no te arrepentirás.
Tiene todo lo que necesitas y aún más de lo que puedes necesitar. Es estable, fácil, poderoso, seguro, completo y ... totalmente gratis.
Te detallo algunas de sus características principales:
- Funciona en Windows, Linux, Mac, Solaris, HP-UX y varios otros UNIX-like. Hacer la migración de una plataforma a otra es demasiado fácil, sólo haces un backup y lo restauras.
- Puedes conectarte mediante ODBC, JDBC, PHP, Perl, Python, OLEDB, dbExpress, proveedor .NET y mediante llamadas directas a la API
- El tamaño máximo de una base de datos es de hasta 64 terabytes (64.000 gigabytes o 64.000.000 de megabytes), pero como puedes partir una base de datos en dos o más partes, en la práctica no hay un límite.
- Cumple totalmente con A.C.I.D. (Atomicity, Consistency, Isolation and Durability). Las mejores bases de datos SQL deben cumplir con A.C.I.D.
- Tiene la arquitectura M.G.A. (MultiGenerational Arquitecture). Lo que eso significa es: "los lectores no bloquean a los escritores y los escritores no bloquean a los lectores". O sea, no necesitas estar bloqueando registros, el Firebird se encarga de mantenerlos actualizados correctamente.
- Permite que varios clientes accedan a varias bases de datos al mismo tiempo
- Tiene procedimientos almacenados comunes
- Tiene procedimientos almacenados que pueden devolver sus resultados a sentencias SELECT. Muy útiles para las consultas y los reportes.
- Tiene triggers, para antes y después de insertar, borrar, modificar registros. También puedes tener un solo trigger que maneje todas esas operaciones.
- Puedes programarle eventos, los cuales pueden ser monitoreados desde el lado del cliente
- Tiene generadores independientes de las transacciones, eso por ejemplo te permite obtener valores únicos para columnas autoincrementales
- Tiene bases de datos de sólo lectura, útiles para programas demo o catálogos
- Control completo de transacciones. Una sola aplicación puede tener muchas transacciones, los niveles de aislamiento pueden ser controlados por el cliente, tienes bloqueo optimístico y savepoints
- Backups en línea. Puedes hacer el backup de tus bases de datos mientras los usuarios las están utilizando a full. O sea, te permite que trabajen 24/7 e igual tienes tus backups.
- Funciones externas. Te permite usar funciones escritas en C, C++, Delphi, o cualquier lenguaje que genere DLLs.
- Integridad referencial. Para no dejar registros huérfanos. Puedes actualizar en cascada.
- Acepta casi todos los lenguajes humanos (castellano, portugués, turco, chino y decenas más)
- El motor ocupa muy poco espacio. Se lo instala y se lo usa, no se debe estar configurándolo.
- No se necesita de un administrador para la base de datos, porque su uso es demasiado sencillo
- Puede utilizar todos los procesadores de la computadora donde está el Servidor
- Tiene replicación. O sea que puedes tener tus datos en varias bases de datos al mismo tiempo. Eso puede aumentar la disponibilidad y la velocidad de acceso.
- Mucha documentación
- Foros y grupos de usuarios
Particularmente le he hecho muchas pruebas, con muchas tablas y con muchos registros en cada una de ellas. Apagué las computadoras, las reseteé, desconecté el router, etc. Hice eso mientras se insertaban, borraban, modificaban y consultaban datos. Jamás encontré el mínimo problema, jamás perdí un solo registro ni encontré un índice dañado. O sea, eso me da mucha confianza en el Firebird.
En fin, deberías probarlo durante unos días antes de decidirte por éste o por otro.
Saludos.
Walter.
Walter R. Ojeda Valiente
Oct 13, 2010, 12:49:11 AM10/13/10
to publice...@googlegroups.com
Hola
Tener una sola base de datos puede facilitar algunas tareas ... mientras no sea muy grande.
Pero tener una sola base de datos para todas tus aplicaciones, con cientos de tablas, cientos o miles de índices, cientos de dominios, cientos de restricciones, cientos o miles de triggers y de procedimientos almacenados, etc., pueden hacer que ésta crezca monstruosamente.
Si cuando necesites agregar o modificar algún elemento dispones de mucho tiempo y de una muy buena documentación, podría no ser problemático. Pero si tienes poco tiempo para hacerlo o una pobre documentación, puede ser un gran quebradero de cabeza.
Saludos.
Walter.
Tener una sola base de datos puede facilitar algunas tareas ... mientras no sea muy grande.
Pero tener una sola base de datos para todas tus aplicaciones, con cientos de tablas, cientos o miles de índices, cientos de dominios, cientos de restricciones, cientos o miles de triggers y de procedimientos almacenados, etc., pueden hacer que ésta crezca monstruosamente.
Si cuando necesites agregar o modificar algún elemento dispones de mucho tiempo y de una muy buena documentación, podría no ser problemático. Pero si tienes poco tiempo para hacerlo o una pobre documentación, puede ser un gran quebradero de cabeza.
Saludos.
Walter.
carlos SALCEDO
Oct 13, 2010, 9:46:50 AM10/13/10
to publice...@googlegroups.com
Walter
Que herramientas graficas maneja firebird ?
Subject: RE: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
Date: Wed, 13 Oct 2010 03:58:37 +0000
Date: Wed, 13 Oct 2010 03:58:37 +0000
Luis Mata
Oct 13, 2010, 9:39:21 AM10/13/10
to publice...@googlegroups.com
una base de datos crece o bien siendo uno solo o bien
siendo 10 o 20. Poner la informacion en varias BD no va a impedir el crecimiento
de datos y a la larga lo que ves en uno lo veras en todos tus disgregados y si
quieres hacer un corte para reiniciar la aplicacion donde vas a ver mas trabajo
en una BD o en muchas BD, logicamente una sola te da menos trabajo.
aparte que el rendimiento en VPN del sql server con mas de
medio millon de registros es muy bueno con transacciones constantes asi que una
sola BD es la que recomiendo.
Luis
----- Original Message -----From: Walter R. Ojeda Valiente
ZeRoberto
Oct 13, 2010, 10:59:59 AM10/13/10
to publice...@googlegroups.com
Firebird Maestro, buscalo en taringa XD
Saludos
El día 13/10/10, carlos SALCEDO <caros...@hotmail.com> escribió:
Luis Mata
Oct 13, 2010, 10:25:59 AM10/13/10
to publice...@googlegroups.com
?Con respecto al punto 2
Es cierto no conozco ningun sistema robusto que corra en Linux, y lo veo
dificil que haya uno, (En produccion claro) ni empresas serias donde se vea
que trabajen todos con Linux, ni cabinas siquiera la tendencia MS duela lo
quenos duela es muy fuerte, y como quien dice nadar contra la corriente es
una perdida de tiempo.
Aparte que una vez quize buscar un proveedor con sistema en Linux (ERP) vino
una empresa EGS con el cuento de implementar adempiere y nos estafo con las
mas de $ 15.000 y de ese Adempiere no tenemos ni un archivo siquiera. desde
ese dia adios codigo libre, para cosas serias MS para perder el tiempo
Linux.
- Quieres que te estafen..Codigo Libre
- Quiere quedarte sin soporte..Codigo Libre
- Quieres quedarte sin tener a nadie a quien reclamar da�os.. codigo libre
- Quieres tener clientes minoritarios .. codigo libre
- Quieres tener cliente misios que no te pueden pagar.. codigo libre (Si no
pueden pagar lo que les favorece menos te van a poder pagar a ti.)
- Quieres tener clientes llorones.. codigo libre
jejejej y muchas cosas mas.. espero no da�ar suceptibilidades.
Luis
----- Original Message -----
From: "Victor Espina" <vesp...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa�ol"
<publice...@googlegroups.com>
Hola Fabricio.
Victor Espina
> as� que quiero la ayuda y los consejos de los expertos o
> experimentados.
>
> Yo desarrollo conjuntos de sistemas, por ejemplo:
> - Contabilidad General y Emisi�n de Cheques
> - Inventarios, Facturaci�n y Cuentas por Cobrar
> - Facturaci�n de Servicios
> - Inventarios de Suministros
> - Activos Fijos
>
> Cada uno de esos sistemas o conjuntos, tienen sus propias .DBF, cada
> uno est� instalado en una carpeta aparte, todos ellos hacen referencia
> a la Contabilidad General para la interfase contable o a los sistemas
> que sean necesarios.
>
> Esto me facilita comercializar cada uno de ellos como un sistema por
> separado y llenar las necesidades espec�ficas de cada cliente en
> particular, me permite venderlos a un precio menor que en lugar de
> vender un sistema completo por un precio m�s elevado.
>
> Ahora que quiero empezar a usar SQL, me surgen las preguntas:
> - C�mo debo dise�ar mi base de datos?
> - Debo hacer una sola base de datos?
> - Puedo manejar una base de datos para cada sistema?
> - Puedo interconectar esas bases de datos entre s�?
> - Qu� es lo m�s id�neo o recomendable?
> - Cu�l es el dise�o m�s adecuado o apropiado?
>
> Espero sus valiosos comentarios al respecto
>
> Si alguno tiene alg�n documento que me sirva de referencia puede
> envi�rmelo al correo fabricio.sando...@hotmail.com
Walter R. Ojeda Valiente
Oct 13, 2010, 6:40:23 PM10/13/10
to publice...@googlegroups.com
Hola Carlos
Varias herramientas gráficas, creo que la más usada es FlameRobin. Aunque yo particularmente utilizo SQL Manager for Interbase/Firebird, ya que es muy fácil de usar, muy completa y está muy bien diseñada. Realmente me facilita muchísimo la vida.
Saludos.
Walter.
Varias herramientas gráficas, creo que la más usada es FlameRobin. Aunque yo particularmente utilizo SQL Manager for Interbase/Firebird, ya que es muy fácil de usar, muy completa y está muy bien diseñada. Realmente me facilita muchísimo la vida.
Saludos.
Walter.
Walter R. Ojeda Valiente
Oct 13, 2010, 6:46:42 PM10/13/10
to publice...@googlegroups.com
Aquí no se trata de los datos que ingresan los usuarios, sino de los metadatos o sea lo que nosotros diseñamos.
Para darte una idea:
No es lo mismo, ni remotamente, una base de datos que tiene 40 tablas y 100 índices que una base de datos que tiene 400 tablas y 1000 índices. La complicación aumenta exponencialmente. Tener una sola base de datos monstruosa puede hacerla inmanejable.
Aunque claro, como casi todo en informática ... es cuestión de gustos ... y metodología de trabajo.
Saludos.
Walter.
Para darte una idea:
No es lo mismo, ni remotamente, una base de datos que tiene 40 tablas y 100 índices que una base de datos que tiene 400 tablas y 1000 índices. La complicación aumenta exponencialmente. Tener una sola base de datos monstruosa puede hacerla inmanejable.
Aunque claro, como casi todo en informática ... es cuestión de gustos ... y metodología de trabajo.
Saludos.
Walter.
Luis Mata
Oct 13, 2010, 7:05:24 PM10/13/10
to publice...@googlegroups.com
Asi es Walter
Cuando tienes 1000 tablas que congregan tablas de los
diferentes modulos como Almacen. Ventas, Caja, Inventarios, Compras,
Contabilidad, Finanzas.. etc
En sql server hay una opcion que se llama diagramas donde
puedes crear diagramas para cada modulo o siendo mucho mas especifico para cada
proceso de tu sistema.
asi ya no te vas a buscar tabla por tabla a las 5 tablas
involucradas en el proceso de generacion de proformas digamos ,haces un diagrama
bien bonito y los relacionas y cuando se presente un problema vas directamente
al grafico y lo analizas es cuestion de ordenarse.
yo tengo N diagramas en sql uno para cada modulo y algunos
para procesos criticos.
Luis
----- Original Message -----From: Walter R. Ojeda Valiente
carlos SALCEDO
Oct 14, 2010, 8:47:22 AM10/14/10
to publice...@googlegroups.com
Hola wlater
Gracias por la informacion - mirare y probare
Gracias por la informacion - mirare y probare
Bendiciones
Carlos
From: wr...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: Como diseñar Base de Datos MS-SQL Server
Date: Wed, 13 Oct 2010 22:40:23 +0000
Reply all
Reply to author
Forward
0 new messages