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
te recomiendo odbc y que el usuario escoja la base de datos
saludos
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)
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.
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
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
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
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...
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.
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 .
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.
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
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
Cita de: "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
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.
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
realmente no entiendo por que no usais odbc ya que es el mejor sistema para gestionar bases de datos sin saber cuala se usara, por mi experiencia profesional no a todos los clientes les gusta mysql, muchos usan oracle, ademas de que si usas odbc no tienes que realizar conversiones de una base de datos a otra, pero bueno tu mismo, yo te recomiendo odbc por su flexibilidad y rapidez
saludos
Cita de: "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
Pues el unico sentido que le veo al usar base propia es el siguiente:
Empresa contrata a prgramador A, :) , en practicas, le paga 4 duros al mes para que le diseñe programa que meneje base de datos con formato estandar (acces,sql etc,etc), una vez creado el programa el empresario se enfada, (grrr) , con el empleado, :lol: , que le pide aumento del sueldo, despues de demostrada su valia, el empresario, (twist) , se niega al aumento o despide sin mas a tan osado empleado, O_O , este se va, se lleva su programa alegando sus derechos de autor que en ningun momento le han pagado, (grrr) , (te pagan por desarrollar la aplicacion, no por los derechos de la misma, ojo con lo que firmamos), contratan a otro aprendiz, (genial) , programador B, por cuatro duros y continua con el trabajo sobre la base de datos con Formato "to quisqui me conoce". Programador "A", :( , esta al paro y no recive un duro por su programa, programador b, lleva el mismo camino.
Programador C , :ph34r: ,creó su base de datos con formato propio con tres ficheros, pero viendo el percal, codificó los datos ascii sumandole uno a cada valor CHR de los mismos (chr(a)+1 = letra b, Pedro seria = Qfeop), despues pidió un aumento de sueldo, B) y como tenia agarrado al Empresario, por los cataplines, no solo consiguio el aumento, sino que tuvo tiempo para en el futuro desarrollar codigo para portar los resultados de su programa (no la BDD) a tropecientos formatos que estan super explicados en inet.
Salu2.
Ese caso es tan estúpido e irreal que en el que caso de que fuera posible a los programadores A,B,C no les interesaría trabajar con alguien así.
La gente no se da cuenta que lo primero que debe mirar al buscar un trabajo es que el que lleva el negocio tenga 2 dedos de frente y el del hipotetico ejemplo no los tendría. Hay prácticas en empresas por miles, tenemos para elegir.
Cita de: "ethernet"Ese caso es tan estúpido e irreal que en el que caso de que fuera posible a los programadores A,B,C no les interesaría trabajar con alguien así.
La gente no se da cuenta que lo primero que debe mirar al buscar un trabajo es que el que lleva el negocio tenga 2 dedos de frente y el del hipotetico ejemplo no los tendría. Hay prácticas en empresas por miles, tenemos para elegir.
Pues ya ves, los empresarios de multinacionales no tienen dos dedos de frente, cierran factorias en España para irse a los paises del Este o de Oriente, donde la mano de Obra ta tirada, serán ignorantes. Ya volveran, ya y cuando lo hagan nos vamos a negar a trabajar para ellos, ademas es mas digno vender helados y refrescos por las playas a los guiris.
Tienes razón, yo nunca trabajaría para por ejemplo una Fijutsu, que si tienen perdidas un año despiden a 4000 empleados, las empresas del País de las casas de chocolatina y calles de caramelo, no hacen eso.
Ademas, de que nos tenemos que preocupar, si hay un monton de trabajo, seguro que esos 2.007.100 de parados del año pasado no saben hacer ni la o con un vaso.
Salu2.
Para Vicente
No habia oid nada de que MySQL fuese mal con .Net , la verdad , es en la que habia pensado si optaba por bases de datos , que creo que es lo que finalmente hare , como han dicho por ahi , no hay por que reinventar la rueda .
Para Calantra
El ejemplo que has puesto de la base de datos es una verdad como un templo , otra cosa es que el cliente quiera más campos ( Domicilio , y mil chorradas que se le puedan pasar por la cabeza ).
¿ Alguno ha tenido problas con MySQL y C# como decía Vicente ?
Lo cierto esque no le veo problema a añadir mas campos a una base propia existente, si por ejemplo tenemos una base de datos donde cada elemento consta de 3 campos y queremos que sea de 6 pues seria algo asin:
Camposantiguos=3
total de lineas en del fichero=18 ( 6 elementos )
ficherodbantiguo=baseantigua
ficherodbnuevo=basenueva
contador = 1
repite
si contador=camposantiguos entonces escribo tres lineas en blanco en ficherodbnuevo
y sumo tres a camposantiguos
leecampo de ficherodbantiguo
escribe en ficherodbnuevo
incremento contador
hasta que contador sea = a total de lienas en fichero
He leido una a una las lineas y las e copiado a otro fichero nuevo y cada tres lineas leidas, he añadido 3 lineas mas en blanco al nuevo fichero.
Ya tengo mi bd con el nombre "basenueva" con 6 campos, 3 que ya usaba y tenia definidos y 3 mas en blanco para lo que yo quiera, el siguiente paso es definirlos en el programa para que sean leidos y escritos.
si tengo una variable de tipo Elemento compuesto de:
variable Nombre
variable Direccion
variable Provincia
pues solo seria añadirle las 2 variables nuevas que yo quiera a continuacion.
Creo que el formato de la Bd esta claro, 1 linea por campo, pa no complicarnos la vida.
Ej.
Linea 1 = Nombre
Linea 2 = Direccion
Linea 3 = Provincia
Liena 4 = Nombre ... Y asi sucesibamente hasta el final.
Espero que se entienda.
Salu2.
P.d. por cierto, que quede claro que yo no quiero convencer de nada a nadie, cada uno desarroya como le da la gana y lo que a mi me parece bien a otros tantos les parece mal. Desde mi punto de vista el fin justifica los medios, si algo funciona "bien" como si esta hecho en basic, mientras haga lo que tiene que hacer como nosotros queramos.
Cita de: "Calantra"Pues ya ves, los empresarios de multinacionales no tienen dos dedos de frente, cierran factorias en España para irse a los paises del Este o de Oriente, donde la mano de Obra ta tirada, serán ignorantes. Ya volveran, ya y cuando lo hagan nos vamos a negar a trabajar para ellos, ademas es mas digno vender helados y refrescos por las playas a los guiris.
Tienes razón, yo nunca trabajaría para por ejemplo una Fijutsu, que si tienen perdidas un año despiden a 4000 empleados, las empresas del País de las casas de chocolatina y calles de caramelo, no hacen eso.
Ademas, de que nos tenemos que preocupar, si hay un monton de trabajo, seguro que esos 2.007.100 de parados del año pasado no saben hacer ni la o con un vaso.
Salu2.
Yo cuando hablo de trabajo hablo de trabajo para gente que piensa, me explico, una empresa de meter tornillos en botes no necesita gente preparada, sin embargo una empresa que hace satélites necesita, ingenieros a expuertas (teleco, informáticos, electronicos, físicos....) y en países subdesarrollados no existen.
2 millones de parados.. de los cuales hay una tasa de temporalidad (andalucía rocks), paro friccional, gente que está trabajando y que además está en el paro (legalmente es posible hacerlo) los que lo hacen ilegalmente, los que no están dispuestos a moverse de su casa para currar, los estudiantes que están apuntados para dar cursos. El que quiere trabajar, trabaja y mucho más si vale.
He leído diferentes opiniones sobre bases de datos estándar y propias. Voy a dar la mía bajo mi experiencia profesional y desde un punto de vista práctico y lógico:
Lo primero a tener en cuenta para decidirse en este sentido es saber qué cantidad de información necesitará gestionar el programa, qué cantidad a almacenar en los ficheros, y cuántos usuarios concurrentes.
Algo a tener también muy en cuenta es del tiempo del que dispones para desarrollar la aplicación.
Los problemas entre base de datos y lenguaje de programación creo que es lo de menos, ya que el driver correspondiente es el que hace el trabajo (a menos que exista algún tipo de incompatibilidad, tal vez con la tecnología .NET ¿? )
Si va a ser una aplicación relativamente pequeña puedes usar ficheros propios y olvidarte de la base de datos.
Si vas a necesitar una considerable cantidad de información (no más de 5000 registros en alguna tabla, por mi experiencia) te puedes quedar con Access, siempre y cuando la aplicación sea para un sólo usuario.
Si va a haber mucha información no aconsejo una base de datos propia a menos que dispongas del tiempo suficiente para su desarrollo, teniendo en cuenta que deberá tener un mínimo de velocidad. El que estemos programando un programa de gestión no quiere decir que tenga que ser lento. Muchísimos programas de este tipo requieren un acceso a la información muy rápido.
En caso de que vaya a haber una cantidad de datos realmente importante (base de datos de más de 50 MB) lo mejor es SQL Server, MySQL o Postgree.
Lo bueno de MySQL o Postgree es que son gratuitos. Pero también tienes una versión gratuita de Microsoft SQL, y es Microsoft Desktop Engine (MSDE), cuyas especificaciones indican que admite hasta 5 usuarios concurrentes, aunque en la práctica he llegado a ver hasta 20. El MSDE es el motor SQL que instalarías en el equipo donde vaya a estar la base de datos. Esta base de datos la puedes crear con cualquier otro gestor gratuito y luego convertirla, o simplemente generar los ficheros .sql y luego ejecutar las instrucciones desde tu aplicación en un proceso de instalación o puesta a punto.
Si la aplicación va a ser muy grande, potente y con una cantidad de información exagerada, la solución es Oracle, siempre y cuando el cliente esté dispuesto a pagar una licencia, y a menos que sea una empresa a la que le sobre mucho dinero, dudo que la compre. De hecho con muchas aplicaciones se distribuye MSDE para evitar que el cliente compre una licencia de SQL Server.
Y hablando de otros temas... es muy diferente hacer un formato propio de fichero a hacer un nuevo gestor de bases de datos. Un formato de fichero para una aplicación pequeñita, vale. Pero dudo mucho que alguien se ponga a desarrollar un gestor de bases de datos para una aplicación de una empresa en la que podemos durar dos telediarios (a menos que nos contraten para eso).
Y a parte de eso, si al programador C lo echan y contratan a un D, revisando el código fuente podrá ver el formato del fichero (aunque le lleve su tiempo).
Por otra parte, si a mi me dicen que tengo que hacer un programa en 6 meses con total libertad para elegir el formato en el que se guarden los datos, creo que lo más importante es acabar el proyecto, y no ponerme a reinventar la rueda (como ya han dicho) para tardar más tiempo del que me debería de llevar mi trabajo.
Además, si estamos aprendiendo, lo más importante es eso, aprender y coger experiencia. Y si tuviera la oportunidad de trabajar en Fujitsu aunque me echen a los 6 meses, tal vez la aprovecharía. Hay nombres que quedan muy bien en un currículum. Aunque eso ya es algo más personal, y dependería mucho de la situación y las espectativas de cada uno.
Pensemos con lógica, deberíamos estar acostumbrados a eso, somos programadores ;)
(esta frase me la apunto para la firma (uoh) )
P.D.: las empresas del País de las chocolatinas también hacen eso, si tienen pérdidas echan a los currantes que sobran. Una empresa es una empresa, y está para ganar dinero, si la forma de ganarlo es echando a los curritos... nos tocará la china. Yo he estado en más de una cercana a los mundos de Yupi, y te aseguro que también ocurre (asco)
Hola TonyJ . No conocia msde , he buscado en microsoft , y veo que hay para la descarga , una version "sql server 2005 express" , quizas en esta version no hayan problemas con .Net como han comentado , aunque nadie ha hablado todavia de los problemas que tenia MySQL con .Net .
Ya habia comentado que me estaba decantando por una base de datos , y teniendo una version gratuita de microsoft , quizas me decante por msde ,asi quizas no haya problemas de compatibilidad ( ambos son productos del mismo padre ...... )
Hay algunas tablas que contienen cerca de 10000 registros , asi que access descartado . Muchas gracias por las opiniones/experiencias de todos , un saludo
Cierto. De hecho, si nos fijamos en las especificaciones, necesita .NET Framework 2.0, y se integra con Visutal Studio 2005, por lo que no debería haber ningún problema.
Además, parece ser que es gratuito, o al menos eso me ha parecido ver (si no lo he traducido mal B) ) Será porque es una Beta.
Creo que es una buena solución para tu proyecto.
Suerte. (ole)
Hola,
lo del MySQL lo decía como ejemplo, no tengo ni idea de si va bien o mal ;) Yo he usado .NET contra Access y MSQLS, pero vamos, supongo que contra cualquier otro proveedor irá perfectamente. Pero vamos eso, que solo era un ejemplo, no verdad, lo siento si no me he expresado muy bien. Un saludo!
Vicente
Hola,
y respecto al net 2.0 y el Visual 2005. Nosotros en nuestra empresa a pesar de estar en beta lo usamos, y va muy bien la verdad. Del SQL Server Express 2005 no te puedo comentar nada porque ese no lo tocamos, pero el Visual Studio 2005 (la beta de diciembre, la del Team System, no la nueva que han sacado hace poco Professional) y el Framework 2.0 son una gozada, se trabaja muy rápido (generics rock) y el IDE es cómodo cómodo (y eso que yo curro en VB.NET que no trae muuuchas pijadas que si trae C#).
Un saludo!
Vicente
Para BD échale un ojo a FireBird
Me parece de locos que estéis plantearos reinventar la rueda en uno de los pilares de la informática, una BD. Creéis además que un sistema de ficheros "artesanal" va a tener más seguridad que uno de BD?, por no hablar de cómo lo vas a montar (nooo)
PD: Contabilidad y Facturación?, no veo el próximo ContaPlus y FacturaPlus sin Base de Datos :D
CitarEl contaplus mismo está hecho en Clipper.
Jeje, sí, pero Clipper precisamente para manejar directamente la BD, que es DBase ( creo :P )
PD: La próxima versión es C# + FireBird
Bueno, como veo que capiflash ya se ha decantado por usar una base de datos predefinida creo que no le daremos mas vueltas ¿no?
Algunos dicen que crear una base de datos propia es reinventar la rueda, pero cada empresa se ha creado la suya a partir de que?¿ ¿o son todas iguales? ¿o unas se pueden portar a otras? Lo cierto es que no estaria de mas que alguien mas "rienventara la rueda en cuanto a sistmas operativos" asi tendriamos mas donde elegir, pero bueno teniendo a Guindous que nos lo hace todo, para que queremos mas.
Yo seguiré con mi base en un fichero plano de texto, conteniendo casi 1000 registros ya, que ha generado decenas de megabytes de informacion sencilla y entendible desde el año 97, ofreceindo velocidad y solidez. Y como comenté en realtos anteriores "si algo funciona bien para que voy a cambiarlo", simplemente un lavado de cara y algunas mejoras y 10 años mas dando caña (uoh).
El dia que tenga una base con tropecientos megabytes y vaya lento, pues la cargare en memoria antes de iniciar la aplicacion en bloques donde los datos estan ordenados de a la "a" a la "j" y asi sucesivamente para optimizar mas aun la velocidad en la busqueda y el acceso será igual que si utilizara un fichero.
Salu2.
Salu2.
Uhm... Calantra, qué sabes de Bases de Datos?
Bueno Calantra , si te funciona con txt pues por que cambiarlo , eso es verdad . Desde mi punto de vista prefiero empezarlo todo partiendo como base con una BD ( habra mas de 10000 registros en algunas tablas ) se me hace un poco pesado dejar eso en un txt . Pero bueno , para gustos colores , miestras funcione , todos conentos ,
Cita de: "Grugnorr"Uhm... Calantra, qué sabes de Bases de Datos?
¿Que hay que saber Grugnorr?
http://www.google.es/search?hl=es&lr=&oi=d...e:Base+de+datosEso es lo que yo se, mas menos todas las definicioens dicen lo mismo.
"Si algo es bueno y breve es dos veces bueno asin que me quedo con esta"
"Conjunto de datos organizados de modo tal que resulte fácil acceder a ellos, gestionarlos y actualizarlos. Una guía telefónica es un ejemplo de una base de datos "
Por que, NO, señores la definicion de Base de Datos no es Acces,Dbase,Sql,FoxPro,firebird,Oracle o como quiera que lo llamen = que, la definición de Sistema operativo no es Windows, Linux,Unix,os2,MacOs etc,etc.
Capiflash me parece estupendo que hayas optado por una Bd, como puse en un post anterior me parece lo mas profesional, es como elegir entre escribir los telefonos de los amigos en una agenda o acerlo en una libreta cuadriculada, de lo que no cabe duda es que ambos metodos cumplirán su cometido.
Por cierto, hoy he presentado en sociedad mi proyecto y no ha funcionado del todo bien :D , pero depués de explicar las virtudes y milagros que se podrán hacer con el programilla cuando esté acabado, han sido todo elogios. Y he de ser autocritico y decir que en el equipo de la prueba se notaba algo de pereza al al acceder a los datos de la base de los clientes, que es la que comentaba tenía ya cerca de 1000 entradas. Lo tengo muy claro y se de sobra que no ira bien si se le añaden muchas mas entradas, asín que tendre que empezar a plantearme precargar la base de datos en memoria y acceder a ella de esta manera, estoy seguro de que esta es la solución a este problema. (El equipo de la prueba es un Piii a 450Mhz con 64mb de Ram,8 gb de hd, bajo Win98 :lol: )
Salu2.
Si te puedo ayudar en algo no dudes en postear que lo haré.
P.d. Los programas que he desarroyado para la empresa han sido con el fin de ayudar a mis compañeros en su trabajo y nunca he buscando un lucro personal, por lo que no he recibido un duro, pero me siento feliz por dos motivos 1º el poder desarrollar programillas que ayuden y el 2º la gratitud de mis compañeros, ojala este mundo no se moviera por tanto $ y tanta marca, tal vez seriamos todos un pelin mas =.
De bases de datos es preferible no saber nada, lo interesante es saber modelar que eso es lo que da pasta y no se aprende en un curso de 30 horas XD
Pues yo pienso que es mas importante tener talento,habilidad,creatividad, más que el saber, se puede saber mucho de una cosa, pero sin imaginacion y talento no se consigue hacer nada bueno.La pasta luego viene sola o no, quien sabe, muchos grandes artistas de la historia palmaron más pobres que una rata.
Salu2.
Prefiero no perder el tiempo explicándote qué es una Base de Datos Relacional, ya que según tú lo sabes perfectamente y, sobretodo, queda claro que, como tienes talento( o eso dices ), unas cuantas décadas de avance en la informática por varios millones de personas no se acercan ni de lejos a tu super sistema de búsqueda de datos en un fichero...
PD: Me encantaría ver tu solución para, simplemente, recoger los datos relacionados de unas 7 tablas, ordenados, agrupados, con funciones de agregación y filtrados por unos cuantos campos...
Hay un refran que dice "nada hay tan valiente como la ignorancia" y creo que se puede aplicar aqui, vale que haya unos pocos casos muy concretos en los que un archivo a lo csv te sirva para una aplicacion, sobretodo si es de caracter personal, pero como solucion profesional, es una irresponsabilidad y tener ganas de reinventar la rueda, los ejes y el abs.
No solo reinventas las funciones de acceso a datos, sino las de su mezclado, filtrado y si quieres que tu aplicacion sea minimanente fiable, además debe de ser capaz de recuperarse de pequeñas inconsistencias en el archivo, etc... No gracias, un archivo ascii puede valer para casos muy concretos pero a poco que una aplicacion demande, va a ir mucho mejor una bbdd, y si no quieres un sgdb completo, y prefieres algo mas ligero tienes desde berkleydb, cloudscape,sqllite, etc.. como soluciones empotradas y ligeras.
incluso dao que es lo mas sencillo que existe (mdb) y tienes editor visual que es el access
saludos
Al final cuchilladas. xD
El tema era otro y el chaval ya parece decidido, qué tal otro post en offtopic sobre "rehacer cosas hechas"?
Un saludor
Una cosa es reimplementar... yo qué sé, una Hashtable y otra es una Base de Datos, y mucho más cuando la solución evidentemente no es ni un 5% .
Pero vamos, sin acritudes :)
Bueno , bueno , el chaval ( osea yo :P ) ya se ha decidido , que corra el aire que no hayan agresiones :D
Gracias a todos por las respuestas , un saludo , ya volvere a molestaros con preguntas sobre c#