Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > Tablas planas
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

 
 
Herramientas Buscar en Tema Desplegado
  #31  
Antiguo 25-10-2007
cacho22 cacho22 is offline
Registrado
 
Registrado: oct 2007
Posts: 6
Poder: 0
cacho22 Va por buen camino
Delphius:

Me parece muy importante tu opinion y mucho mas al saber que trabajaste o trabajas como DBA, yo igualmente soy DBA en mi empresa, y actualmente estoy en el proceso de analisis de un nuevo sistema para el manejo de caja y como tu dices uno no es dueño de la verdad, sin embargo tu opinion es muy respetable y me abre muchas ideas alternativas para solucionar los problemas q a futuro se puedan presentar.

Respecto a lo que citaste:
Cita:

Imponer una restricción (que el cliente no pueda cambiar su razón social ha dejado de ser un requisito, ahora en tu concepto es una restricción) podría provocar cambios en el modo de operar tu sistema. Una restricción nunca debería cambiar a lo largo del ciclo de vida, por tanto condiciona al sistema (entendido a este como el todo: el software, la base de datos, etc) muy fuertemente y lo sujeta a un modelo rígido de la realidad.
de nuevo tienes toda la razon, por q si bien uno pone esta restriccion en todo el ciclo de vida del software o programa, puede ser q por ordenes superiores se te obligue a modificar la tabla citada, en este caso la razon_del_cliente, entonces todo el analisis ya no funcionará y esto llevará a inconsistencias futuras.

Por eso como tu dices, imponer esta restriccion haria el modelamiento de la realidad demasiado rigido (segun el caso, o la comprension q uno tenga).

Por tanto, sabiendo q en un futuro se tenga necesariamente que cambiar el nombre de ciertos clientes (yo creo q seran muy pocos en el transcurso de los años) el planteamiento q tu sugieres seria realizar los reportes de ventas cruzando la tabla de historico de clientes (h_cliente) con la tabla ventas?, claro q como decias:
es el precio que se paga cuando se elevan los "requisitos". Sin embargo el resultado es "obtener una información coherente y sin incosistencias" q es lo que uno busca.

Me parece que este diseño lo deben utilizar el servicio de impuestos internos de mi pais, por q en sus reportes t dan una información muy coherente de todo lo que hiciste en un lapso de tiempo prolongado.

Me es muy importante saber tu opinion, o plantear otra solución alternativa a las dos q se estan analizando de este caso en específico, gracias por tu colaboracion.

Saludos
cacho22

Última edición por cacho22 fecha: 25-10-2007 a las 22:04:35. Razón: no se ve muy bien
Responder Con Cita
 


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Combinar información de dos tablas ContraVeneno SQL 2 04-08-2005 18:20:14
Mas informacion sobre ECO II... Epachsoft Noticias 1 01-07-2005 19:15:10
informacion sobre estructura de tablas paradox e indice px chuley Tablas planas 2 06-04-2005 03:42:37
Recuperacion de informacion Tablas paradox andresenlared Tablas planas 1 14-08-2004 13:08:10
Información sobre Rx bbjb OOP 2 13-01-2004 19:13:49


La franja horaria es GMT +2. Ahora son las 08:29:15.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi