¿bases De Datos O Ficheros Propios ?

[Capiflash]

 Pues eso , estoy empezando el desarrollo de una aplicacion de facturacion/contabilidad en C# , y uno de mis mayores dilemas q aun no he conseguido solucionar es este . Si usar bases de datos para todo , o ficheros con formato propio , la verdad es que primero pense en las bases de datos , pero luego me imagine a algún empleado algo entrometido quizas abriendo esos archivos y vete a saber q carajo hace, por eso me pare también a pensar en ficheros con formato propio , ¿ cuál es vuestra opinión ?
Si deciis bases de datos , ¿ Acces , MySQL..... ?

Gracias de antemano , y bueno , esto no es un motor , pero ...... perdonadme por aburriros  :P  

[zupervaca]

 te recomiendo odbc y que el usuario escoja la base de datos

saludos

[senior wapo]

 Evita en lo posible servidores de bases de datos, odbc y cualquier otra cosa que requiera meter mano. Dependerá de si los datos han de ser accesibles por varios usuarios a la vez desde distintas máquinas, claro está.

Lo que te interesa es pocos quebraderos de cabeza por mantenimiento. Por mucho que se cabree nuestro orgullo informático, olvidate del rendimiento (sacrilego! a la hoguera!). Que haga su cometido, no haga preguntas raras y no de problemas. Si va lento o requiere un montón de memoria no se acordarán de tu familia, si falla, o es un coñazo de manejar, si.

Un fichero plano de texto, comprimido con zlib muchas veces va de lujo. Aunque lo cargues entero en memoria y ordenes con un qsort guarro, sin indices en disco ni nada.
Y si no, usa sqlite (www.sqlite.com)
Y si necesitas acceso multiusuario (poco), access.
Y si no, te metes con mysql.

Las oficinas de muchas pymes han funcionado (y aun lo hacen) con aplicaciones xbase que comparten los datos a traves de una carpeta compartida de windows (LEEENTO) y la gente no se queja. El contaplus mismo está hecho en Clipper.

PD: No te compliques la vida, hagas lo que hagas saldrá un "experto" poniendote verde el programa igualmente. Es lo que tiene ser informático o futbolista en España.  (twist)  

[ethernet]

 La conclusión en este tipo de preguntas es lo mismo: haz lo que te dicte la imaginación (apoyada por tus conocimientos), el caso es que funcione y te saque del aprieto.

[ajmendoza]

 No nombres a acces como una base de datos decente, sacrilego! .. (es que me ha dolio un ojo al verlo :P).

Depende de tu aplicacion. Si es algo grande utiliza una base de datos. Si sabes diseñarla, que seguro que si, te da seguridad y optimizacion. Yo te diria, que para este caso que te comento, oracle, caro, pero yo diria que la mejor.
Si es una aplicacion pequeña, con una bd opensource (que maneje transacciones, hay algunas que no lo hace) vas sobrao xD. No me imagino a un empleado corriente intentando siquiera encontrar archivos de una bd del sistema (no, que acces no es una opcion).

Un saludo

[Buffon]

 joer la engineria del software siempre recomienda usar base de datos.

y si algun empleado mira dentro de la base de datos es su problema, tu no das soporte tecnico para tal cosa! solo das soporte tecnico para los fallos de tu programa.

que no contraten a becarios, pagandoles una mierda!!!!! que luego se vengan de esta manera! xD

[Capiflash]

 En este caso , seria una aplicacion para un servidor y 4 clientes , osea , que muy grande tampoco va a ser . Lo que si es cierto es que necesito multiusuario .

Gracias por las respuestas

[Vivael13h]

 Como dijo Buffon, la ingeniería de soft recomienda bases de datos... y también que el usuario no toque NADA de esos datos mientras no sea a través de tu programa. Si lo hace, es cosa suya. He visto varios programas de gestión que junto al archivo de la BD guardan uno de texto que pone: "por favor, no borre esta carpeta ni modifique su contenido", o algo parecido, para que no te metan mano ahí.

La elección del sistema de almacenamiento debería ser un pilar básico, pero como ya te han dicho, en la práctica sólo te tienes que preocupar de que el programa funcione bien, el resto imagínate que es transparente para el usuario. Si pones, por ejemplo, un archivo .mdb y luego el usuario lo borra, pues se siente. Hay que intentar proteger al usuario para que no meta la pata, pero milagritos tampoco se pueden. Conozco el caso de un paisano que entró en el disco C e intentó borrar la carpeta windows, porque como no sabía lo que era, supuso que no le hacía falta (suerte que le pillé a tiempo).

La primera ley de la ingeniería del software debería ser: "ántes de hacer nada, asegúrate de que tu cliente se apunta a una academia a hacer un cursito, aunque sea básico, de informática".

Yo siempre intento tirar hacia bases de datos. Tú decides cuál, en función del número de usuarios, el volumen de datos, la complejidad de las consultas, transacciones, etc. Y no usaría access a menos que fuera un programa monousuario con un volumen pequeño de datos. En caso contrario (que es casi siempre), me iría a sistemas mejores (que son casi todos los demás  :P ), como MySQL, Oracle...

[Lord Trancos 2]

 Yo te recomiendo usar una BBDD, aunque sea de las sencillitas. Ademas, en muchas puedes especificar usuario y contraseña para que los datos esten cifrados y no te los toquen.

Reinventar la rueda siempre ha sido mala idea en la programacion de software y en especial en la programacion de aplicaciones de gestion.

[Capiflash]

 Creo que al final me habeis convencido , y optare por una base de datos . La que mas he usado es MySQL , asi que creo que me pondre con ella . Voy a buscar informacion a ver como trabaja C# con MySQL . Muchas gracias a todos . Cualquier sugerencia más es bien recibida , un saludo , y gracias de nuevo .

[Calantra]

 Enas, yo tambien estoy trabajando en un programito para la empresa onde curro, al igual que tu necesitaré multiusuario aunque todavia no he llegado a ello.

Yo he optado por una base de datos de formato propio y muy simple, tanto que se edita con un edit, el porque de esto es mu sencillo, yo trabajo alli y si veo a un zarpas meterle mano a mi Bd le corto los brazos a la altura las cejas, asin que para que me voy a complicar con otras cosas raras.

El tema de multiusuario en mi imaginacion no es ningun problema, el programa original en pascal (del 97) tenia soporte para multiusuario, como comentaron mas arriba compartiendo una carpeta con los datos de la BD a acceder desde un programa cliente en otro punto.El cliente se encargaba de comprobar cuando el fichero maestro quedaba libre, para poder actualizar los datos introducidos desde el cliente, pues el problema surge en la escritura y no en la lectura.

Esto mismo de una manera mas eficiente seria utilizando una conexion ip, enviar datos a pelo al programa servidor con una cabezera que le indique para que son o para donde van estos datos y el programa servidor que los vaya manejando y metiendo donde deva.

Un ejemplo seria este:
Uno de los clientes solicita del servidor un numero para un albarán,primero se identifica enviando datos del usuario y el puesto desde donde se solicitan los datos.
El servidor le da el 00001 como numero de albaran.
El programa cliente solicita datos del cliente (Fiscal) pej. , el servidor se los envia.
Asi sucesivamente hasta que se crea en el cliente la estructura de los datos del albaran, una vez que se conforman estos datos y se opta por incluirlos en la base de datos,el cliente envia el mensaje al servidor algo asin como:

Cliente:Pepito (donde el servidor sabe que ip corresponde a pepito en la LAN.
Albaran:00001
Cliente :332002 (Codigo del cliente (Fiscal), esto si usamos codigos de cliente.)
Datos del albaran: Referencias,cantidades,precios etc,etc.
Etiqueta de Fin.

El servidor recive los datos y le dice al cliente que OK.
El servidor ahora comprueba el estado de la base de datos y si no esta ocupada registra la entrada.

Ya os contare cuando llegue a esto.

Salu2.



 

[Capiflash]

 Tampoco es mala idea que el servidor lo gestione todo , y q los clientes " le pidan permiso" a el para todo , es otra opcion si señor , a ver si esta proxima semana termino de detallarlo todo y decidirme por unas cosas o otras , y empiezo a desarrollar , q sino se me viene el tiempo encima

[Vicente]

 Hola,

decías que es en C# la aplicación no? Yo iría a por una BD, aunque solo sea por las miles de facilidades que te da el Framework para manejarlas. Contra MySQL no se que tal va, pero nosotros en el curro trabajamos contra MSQLS y Access (si ese :P) y si lo quieres para algo pequeño no se porque el Access no te va a valer...

Un saludo,

Vicente

[Calantra]

Hola,

decías que es en C# la aplicación no? Yo iría a por una BD, aunque solo sea por las miles de facilidades que te da el Framework para manejarlas. Contra MySQL no se que tal va, pero nosotros en el curro trabajamos contra MSQLS y Access (si ese :P) y si lo quieres para algo pequeño no se porque el Access no te va a valer...

Un saludo,

Vicente

Dudo que acces pueda servir para la parte de la Facturacion, para la contabiblidad puede ir bien. MySql creo que sería lo mas apropiado y lo mas profesional. Pero desde luego no lo mas sencillo, que es crear una bdd propia.

Una Bdd no es mas que una estructura de datos que van asociados/relacionados entre si, tampoco es nada del otro mundo para tener que usar programas de otros, si ademas lo hemos hecho un millon de veces cuando creamos nuestros juegos, donde la posicion de los enemigos en la pantalla o en el mundo ya es una base de datos relacionada con la posicion del Heroe.


En un programa de facturacion manejaremos almenos 3 datos :
tipo+nº de Documento (Factura,albarán o documentos propios (docuementos para movimientos de mercancias entre almacenes,documentos de prestamo provisional, Documentos de Deposito, y los que se nos puedan ocurrir)
Ej: F32421 - Factura nº32421, A32421-Albaran nº 32421.

Datos del cliente (Direccion,Cif,Forma de Pago,descuentos,etc etc)

Datos de lo que se factura: Referencias, Conceptos, Precios.

Estos 3 datos estan asociados a 3 bases de datos:
Documentos: Contiene los documentos creados o anulados.
Clientes: Contiene los datos de los clientes.
Stock de Almacen/es: Contiene la totalidad de los productos que vendemos,  los Stocks de los mismos en nuestro/s almacen/es y los PVP.

Y ya ta , ya tenemos la estructura de un BDd para nuestro porogy de Facturacion, pensado a lo Grande y hecho a lo pequeño.

SAlu2.

[Vicente]

 Hola,

yo veo bastante más complicado crear una bbdd propia (una que funcione bien vamos, no tres ficheros que guardan datos) que usar una que ya te dan hecha. Además, el Framework te hace ya mucho curro, por ejemplo, te permite transformar los datasets a xml y viceversa sin ningún problema (por si quisieras usar XML como formato de datos y podrías usar XSD para validar que tus XML son válidos, etc etc).

Pero vamos, que no le veo el sentido a reinventar la rueda cuando ya está inventada y encima te lo dan mascado mascado. Otra cosa sería que access no valga (por la razón que sea), MySQL funcione mal con .NET y no haya ninguna otra BD disponible. Pues entonces nada, a hacerse una propia... Pero vamos, teniendolas ya hechas...

Un saludo!

Vicente