database - sistemas - software para empresas gratis
¿Qué base de datos de código abierto es la mejor opción para un sistema relacionado con la contabilidad? (13)
Estoy en las primeras etapas de planificación y diseño de una aplicación de contabilidad personalizada para mi empresa. Mi objetivo es utilizar una base de datos relacional de fuente abierta para la parte de almacenamiento de datos y conozco dos bases de datos sólidas que son ampliamente compatibles: MySQL y PostgreSQL.
Para un sistema que requerirá transacciones, procedimientos almacenados, funciones y seguridad, ¿hay alguna opinión sobre cuál de estas dos bases de datos sería la más adecuada para una aplicación de contabilidad o hay otra base de datos que me falta?
Estoy más familiarizado con MySQL y MS SQLServer 2005, pero estoy tratando de alejarme de este último debido a los costos de licencia.
Permítanme agregar: esta no es una necesidad de contabilidad como Quickbooks o Peachtree. Esto es básicamente un sistema que maneja la contabilidad de un servicio comercial específico que brindamos. Existen tal vez dos o tres sistemas que satisfacen esta necesidad, tienen un precio en el rango de seis cifras antes de cualquier personalización, y requerirían que mi pequeña empresa esté casada con un proveedor a largo plazo. Por lo tanto, estamos construyendo la aplicación internamente.
Además, si bien agradezco el argumento de Comprar vs. Construir , me gustaría alejarme de esa cuestión religiosa en particular porque ya se tomó el camino de Comprar y el vendedor falló miserablemente. A veces solo necesitas hacer el trabajo tú mismo y este proyecto en particular y tu presupuesto lo justifican.
Gracias por las respuestas de todos hasta ahora.
¿Mi consejo? No lo hagas Mejor comprar uno. Las personas que saben más sobre contabilidad han escrito buenos paquetes que ya se ocupan de los PCGA. Tienen una base de usuarios más grande que nunca, lo que revelará los defectos más rápidamente. Este es un clásico "comprar versus construir". No hay una ventaja competitiva para su empresa al escribir la suya propia. Si lo hace porque le preocupan los costos de la licencia, diría que no ha contabilizado el tiempo de desarrollo correctamente. Esa es la única forma en que podrías justificar hacer esto en casa.
Dicho esto, si le preocupan los costos de licencias de SQL Server, recomendaría PostgreSQL primero o MySQL como la base de datos de su elección.
Como no necesita procedimientos almacenados, elimínelos de su lista.
Serás mucho más feliz al poner la lógica de negocio en el código, no en la base de datos. Si tiene la posibilidad de comenzar a "limpiar", utilice la base de datos para lo que sea más lógico: persistencia no procesada.
Una vez que tome esa decisión, desaparecerán las sutiles diferencias entre MySQL y PostgreSQL. Ambos son motores relacionales que manejan SQL casi idéntico. Enfócate en las cosas que mejor hacen.
Recomendación : haga que su aplicación sea independiente de las peculiaridades de la base de datos.
Estoy totalmente de acuerdo con las respuestas de duffymo y tuinstoel y otros. Reconsidere su decisión de construir contra comprar. Dejame contarte una historia:
Mientras trabajaba en una empresa mediana (ingresos internacionales,> 100 millones de $ / año), el director financiero decidió reemplazar los sistemas financieros por Oracle Financials. Solo ese paquete no coincidía exactamente con las prácticas de contabilidad utilizadas por esta empresa.
Entonces, el CFO contrató a un equipo de programadores por contrato y les pagó para personalizar Oracle Financials a las prácticas contables preferidas. Se hundió 12 meses de tiempo, $ 1 millón en salarios de programador, más el costo inicial del software, solo para duplicar el sistema de contabilidad que tenían la intención de reemplazar.
Ella dijo que si tuviera que volver a hacerlo, compraría el paquete comercial, pero adaptaría los hábitos de contabilidad de la empresa a los valores predeterminados que admite el software. Eso sería mucho más fácil, más rápido y más probable que tenga éxito.
Así que considere el costo de construir su propio paquete personalizado. También considere el costo continuo para su empresa de mantenimiento, depuración y mejora para ese software. Incluso si compra un paquete comercial de seis cifras, probablemente sea menos costoso que pagar a los programadores para desarrollar y mantener dicho sistema.
Para responder a su pregunta planteada más directamente, no creo que haya una diferencia significativa entre PostgreSQL y MySQL que sea relevante para su proyecto. Como te sientes cómodo con MySQL, también puedes hacerlo.
Me gustaría ofrecer un recordatorio obligatorio de no utilizar tipos de datos inexactos como FLOAT o DOUBLE PRECISION para datos financieros.
Firebird - http://www.firebirdsql.org/
Hay sistemas de contabilidad gratuitos de fuente abierta. Como osFinancials. Realmente no puedo entender por qué quieres construir tu propio sistema?
Honestamente, cualquiera de los sospechosos habituales hará el trabajo. Mantener el cuadro de cuentas y las tablas de datos relacionadas es el problema raíz que impulsó a la mayoría de todos los modelos relacionales. De hecho, si piensa en la vista general del diario de un sistema de contabilidad, todo lo que tiene es el plan de cuentas y el diario general, compuesto por número de transacción, fecha, descripción, cuenta de débito e importe, cuenta de crédito y cantidad. Todo lo demás que haces es un SELECCIONAR sobre esos.
Dicho esto, sin embargo, hay tantos paquetes financieros perfectamente adecuados, bien probados y aceptados, incluyendo versiones gratuitas de código abierto (como en la cerveza), que a menos que lo diga por un estudio, un proyecto de estudio, pondría mi esfuerzo en googlear y seleccionar uno.
Vi tu actualización. La cuestión es que este es un problema que en su mayoría va a estar determinado por requisitos no funcionales. ¿Va a distribuir la base de datos en más de un servidor? ¿Cuánta carga esperas? ¿Transacciones por segundo o transacciones por día? Creé sistemas en los dos últimos años y, por lo general, los requisitos de confiabilidad y disponibilidad son los más decisivos: PostgreSQL se ocupa de las actualizaciones concurrentes de una sola fila de manera más efectiva al imponer la atomicidad de filas y serializar las actualizaciones concurrentes. Por otro lado, MySQL parece tratar mejor con bases de datos realmente grandes. Sin embargo, una tercera pregunta es la copia de seguridad, una de ellas (no recuerdo cuál es ahora) requiere más o menos tiempo de inactividad para realizar una copia de seguridad.
Para cualquier aplicación que quiera usar una base de datos de código abierto, la respuesta más simple es Postgres. Es MUCHO más "listo para la empresa" que MySQL, sin mencionar que sigue mucho mejor el estándar SQL. MySQL ha mejorado mucho con sus versiones posteriores, pero Postgres aún lo supera en todas las categorías.
Para su aplicación, realmente no importará. Cualquier cosa desde sqlite a MySQL a Postgres probablemente funcionaría bien. Elija el que le resulte más familiar.
Si está familiarizado con MySQL, úselo. Pero seleccione el motor de base de datos adecuado en lugar de MyISAM predeterminado
Si se trata de una aplicación de escritorio, es posible que desee ver SQLite. Es muy conocido, en el dominio público, y no es terriblemente difícil trabajar con él.
Para una aplicación de contabilidad interna basada en la web, es posible que esté mejor con Gemstone como una base de datos de objetos libres pero no de código abierto y Seaside como el marco web. También conocido como GLASS.
Para una aplicación interna, el esfuerzo del desarrollador será limitado. Gemstone, como una imagen smalltalk, proporciona la mejor productividad de desarrollador con diferencia. Su soporte para migrar objetos al cambiar su definición permite un desarrollo iterativo real. Seaside reemplaza las plantillas por un lenguaje de dominio específico bien diseñado para crear aplicaciones web.
Hay cuatro sistemas principales de administración de bases de datos relacionales de código abierto que pueden ser apropiados para este tipo de aplicación: Postgresql, MySQL, Firebird e Ingres. Existen otros sistemas, como SQLite, pero no tienen este tipo de arquitectura y no están diseñados para este tipo de carga de trabajo. Existen otros sistemas de administración de bases de datos de código abierto de este tipo, pero no parecen ser muy viables por alguna razón, como la falta de compromiso aparente del proveedor. Un ejemplo de un sistema que tiene este tipo de problema es SAP-DB.
Postgresql tiene el mejor conjunto de características de cualquiera de las bases de datos de código abierto y soporte para transacciones XA, que probablemente desee si su aplicación es un sistema de tres niveles y admite transacciones de complejidad no trivial. En particular, deseará esto si desea realizar transacciones que abarquen más de una llamada a la base de datos.
Varias variantes comerciales de PostgreSQL se han construido a lo largo de los años, como Illustra, Greenplum y EnterpriseDB. Illustra fue una publicación comercial de PostgreSQL que luego fue comprada por Informix. Greenplum es una versión modificada diseñada para aplicaciones de almacenamiento de datos. EnterpriseDB es una empresa que ofrece versiones comerciales compatibles de PostgreSQL con algún software de valor agregado.
MySQL 5.x tiene un conjunto de características que admite una sección transversal razonable de capacidades, pero no es tan rico en funciones como PostgreSQL. Tiene una aceptación generalizada más generalizada y sería el sistema de administración de bases de datos de código abierto más fácil de contratar para desarrolladores expertos. Aunque las versiones anteriores no contaban con soporte robusto para transacciones, los motores de almacenamiento transaccional como InnoDB han estado disponibles por algún tiempo. La política actual en torno a la adquisición por parte de Sun ha generado códigos y el panorama de MySQL es algo desordenado, con controversia sobre problemas de calidad en la versión 5.1. Sin embargo, MySQL es, con mucho, el más popular y conocido de los sistemas de administración de bases de datos de código abierto y es el único con un reconocimiento de marca significativo fuera de los círculos de código abierto.
Firebird es una versión de código abierto de Interbase. La última vez que miré, no tenía soporte para XA, pero estaría bien si tu aplicación se configurara como un sistema cliente-servidor de dos niveles. Actualización: no puedo encontrar una especificación definitiva sobre esto, pero la documentación indica que tiene soporte para la confirmación en dos fases, pero lo que pude encontrar no fue específico sobre si era compatible con el protocolo XA. La documentación implica que el controlador JDBC tiene soporte para confirmaciones de dos fases.
Una variante interesante de este sistema es Fyracle , que está diseñado para ofrecer un grado de compatibilidad con Oracle. Esto fue desarrollado originalmente para su uso como un back-end para Compiere , que fue construido contra Oracle y muy unido a él.
Ingres ahora está disponible con una licencia de fuente abierta, pero ha sido recibido con un poco de bostezo colectivo por parte de la comunidad de código abierto. Sin embargo, es bastante rica en funciones y muy madura: conozco personas que estaban haciendo aplicaciones de INGRES en 1990, y se remonta a la década de 1980.
Construyo software de contabilidad en PostgreSQL. Funciona muy bien. Lo recomendaría muchísimo. De hecho (plug desvergonzado), puede considerar trabajar con nosotros para mejorar nuestro proyecto y usarlo como punto de partida.
Hay un par de razones en particular:
- ESCUCHAR / NOTIFICAR le da la capacidad de enganchar otros programas en su base de datos contables cuando algo cambia sin tener que verificar las tablas de vez en cuando.
- Hemos encontrado un rendimiento extremadamente bueno con la mayoría de las consultas complejas.
Firebird e Ingres te darán una solución relacional muy sólida. MySQL no lo recomendaría porque realmente estás atando todo a una sola aplicación que puede escribir en el db (la sopa en modo sql significa que las relaciones son básicamente una API privada en lugar de la API pública que están en PostgreSQL, Firebird e Ingres), y esto significa menos flexibilidad en el camino.
Sin embargo, con PostgreSQL, obtienes una plataforma de desarrollo extensible de primer nivel en una caja. El ritmo de desarrollo es alto. Es sólido como una roca Las funciones avanzadas son muy útiles. No te decepcionará. No hemos sido