¿Qué base de datos de código abierto es la mejor opción para un sistema relacionado con la contabilidad? [cerrado]

StackOverflow https://stackoverflow.com/questions/411976

Pregunta

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 código abierto para la parte de almacenamiento de datos y soy consciente de dos bases de datos sólidas que son ampliamente compatibles: MySQL y PostgreSQL.

Para un sistema que requiera transacciones, procedimientos almacenados, funciones y seguridad, ¿existen opiniones sobre cuál de estas dos bases de datos sería 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 la licencia.

Permítame agregar: Esta no es una necesidad contable como Quickbooks o Peachtree. Este es básicamente un sistema que administra la contabilidad de un servicio comercial específico que brindamos. Es posible que haya dos o tres sistemas que satisfagan esta necesidad, tengan 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 de forma interna.

También, si bien aprecio el argumento Comprar contra construir , me gustaría alejarme de esa pregunta religiosa en particular porque ya se tomó la ruta de Compra y el proveedor fracasó estrepitosamente. A veces solo necesita hacer el trabajo usted mismo y este proyecto y presupuesto en particular lo justifican.

Gracias por las respuestas de todos hasta ahora.

¿Fue útil?

Solución

Hay cuatro sistemas principales de gestión de bases de datos relacionales de código abierto que pueden ser adecuados para este tipo de aplicación: Postgresql, MySQL, Firebird e Ingres. Hay otros sistemas como SQLite, pero no tienen este tipo de arquitectura y no están realmente diseñados para esto Tipo de carga de trabajo. Existen otros sistemas de gestió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 un compromiso aparente del proveedor. Un ejemplo de un sistema que tiene este tipo de problema es SAP-DB.

Postgresql tiene el mejor conjunto de funciones de cualquiera de las bases de datos de código abierto y soporte para transacciones XA, que probablemente deseará 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.

Se han construido varias variantes comerciales de PostgreSQL a lo largo de los años, como Illustra, Greenplum y EnterpriseDB. Illustra fue un lanzamiento comercial de PostgreSQL que posteriormente fue comprado por Informix. Greenplum es una versión mofificada diseñada para aplicaciones de almacenamiento de datos. EnterpriseDB es una compañía que proporciona versiones comerciales compatibles de PostgreSQL con algún software de valor agregado.

MySQL 5.x tiene un conjunto de funciones que admite una sección transversal razonable de capacidades, pero no es tan rico en características como PostgreSQL. Tiene una aceptación generalizada más generalizada y sería el más fácil de los sistemas de administración de bases de datos de código abierto para reclutar desarrolladores calificados. Aunque las versiones anteriores no tenían un soporte robusto para transacciones, los motores de almacenamiento transaccional como InnoDB han estado disponibles por algún tiempo. La actual política que rodea la adquisición por Sun ha generado código forks y el paisaje de MySQL es un tanto 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 gestión de bases de datos de código abierto. solo uno con un importante reconocimiento de marca 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 XA, pero estaría bien si su aplicación estuviera configurada 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 admitía el protocolo XA . La documentación implica que el controlador JDBC tiene soporte para confirmaciones de dos fases.

Una variante interesante en este sistema es Fyracle , que está diseñado para ofrecer un título de compatibilidad con Oracle. Originalmente, fue desarrollado para su uso como back-end de Compiere , que se creó en contra de Oracle y se unió bastante a it.

Ingres ahora está disponible con una licencia de código abierto, pero ha sido recibido con un poco de colectivo Bostezo por la comunidad de código abierto. Sin embargo, es bastante rico en características y muy maduro. Conozco a personas que estaban haciendo aplicaciones de INGRES en 1990, y se remonta a la década de 1980.

Otros consejos

Mi consejo? No lo hagas Mejor comprar uno. Las personas que saben más sobre contabilidad han escrito buenos paquetes que ya tratan con GAAP. Tienen una base de usuarios más grande que la que usted tendrá, lo que descubrirá defectos más rápido. Este es un clásico "comprar contra construir". No hay una ventaja competitiva para su empresa al escribir su propia cuenta. Si lo está haciendo porque le preocupan los costos de las licencias, yo diría que no ha contabilizado correctamente el tiempo de desarrollo. Esa es la única forma en que podría justificar esto en la empresa.

Dicho esto, si le preocupan los costos de licencias de SQL Server, recomendaría PostgreSQL primero o MySQL segundo como la base de datos de su elección.

Estoy totalmente de acuerdo con las respuestas de duffymo y tuinstoel y otros. Reconsidere su construcción contra la decisión de compra. Déjame contarte una historia:

Mientras trabajaba en una empresa mediana (ingresos internacionales, > $ 100M / año), el CFO decidió reemplazar los sistemas financieros con Oracle Financials. Solo ese paquete no coincidía exactamente con las prácticas contables utilizadas por esta empresa.

El CFO contrató a un equipo de programadores contratados y les pagó para personalizar Oracle Financials a las prácticas contables preferidas. Ella perdió 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 ellos habían querido reemplazar.

Dijo que si tuviera que hacerlo otra vez, compraría el paquete comercial, pero adaptaría los hábitos contables de la empresa a los valores predeterminados admitidos por el software. Eso sería mucho más fácil, más rápido y más probable que tenga éxito.

Considere el costo de construir su propio paquete personalizado. También considere el costo continuo para su compañía de mantenimiento, depuración y mejora para ese software. Incluso si compra un paquete comercial de seis cifras, probablemente sea menos costoso que pagarle a los programadores para que desarrollen y mantengan ese sistema.

Para responder de manera más directa a su pregunta, 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 seguir con eso.

Me gustaría ofrecer un recordatorio obligatorio de no usar tipos de datos inexactos como FLOAT o DOUBLE PRECISION para datos financieros.

Para cualquier aplicación que quiera usar una base de datos de código abierto, la respuesta es Postgres. Es MUCHO más " listo para la empresa " que MySQL, sin mencionar que sigue el estándar SQL mucho mejor. MySQL ha mejorado mucho con sus versiones posteriores, pero Postgres aún lo supera en todas las categorías.

Existen sistemas libres de contabilidad de código abierto. Como osFinancials. ¿Realmente no puedo entender por qué quieres construir tu propio sistema?

Para tu aplicación, realmente no importará. Cualquier cosa desde sqlite a MySQL a Postgres probablemente funcionaría bien. Elige el que te resulte más familiar.

Si está familiarizado con MySQL, utilícelo. Pero seleccione el motor de base de datos adecuado en lugar de MyISAM predeterminado

Lista de motores de almacenamiento

Honestamente, cualquier de los sospechosos habituales hará el trabajo. Mantener el plan de cuentas y las tablas de datos relacionadas es el problema raíz que impulsó la mayor parte del modelo relacional. De hecho, si piensa en la vista general del diario de un sistema contable, 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 y importe, cuenta de crédito y importe. Todo lo que haces es un SELECCIONAR sobre esos.

Dicho esto, sin embargo, hay tantos paquetes financieros perfectamente adecuados, bien probados y aceptados, incluidas las versiones gratuitas de código abierto (como en la cerveza), que, a menos que lo diga para un estudio, un proyecto de estudio , Me esforzaría en buscar en Google y seleccionar una.

Vio su actualización. La cuestión es que este es un problema que, en su mayorí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? He construido sistemas en torno a ambos en los últimos años, y los requisitos de fiabilidad y disponibilidad son los más decisivos: PostgreSQL se ocupa de las actualizaciones simultáneas de una sola fila de manera más efectiva, al aplicar la atomicidad de las filas y serializar las actualizaciones concurrentes. Por otro lado, MySQL parece tratar con bases de datos realmente grandes mejor. Sin embargo, una tercera pregunta es la copia de seguridad, una de ellas (no recuerdo cuál en este momento) más o menos requiere algún tiempo de inactividad para la copia de seguridad.

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 de código abierto, y no libre, y Seaside como el marco web. También conocido como GLASS.

Para una aplicación interna, se verá limitado el esfuerzo del desarrollador. La piedra preciosa, como imagen pequeña, proporciona la mejor productividad para desarrolladores con diferencia. Su soporte para migrar objetos al cambiar su definición permite un desarrollo iterativo real. Seaside reemplaza las plantillas por un lenguaje específico de dominio bien diseñado para crear aplicaciones web.

Construyo software de contabilidad en PostgreSQL. Funciona muy bien. Lo recomendaría altamente De hecho (descarado), puede considerar trabajar con nosotros para mejorar nuestro proyecto y usarlo como punto de partida.

Hay un par de razones en particular:

  1. LISTEN / NOTIFY le permite conectar otros programas a su base de datos de contabilidad cuando algo cambia sin tener que revisar las tablas de vez en cuando.
  2. Hemos encontrado un rendimiento extremadamente bueno con la mayoría de las consultas complejas.

Firebird e Ingres le brindarán una solución relacional muy sólida. MySQL No lo recomendaría porque en realidad solo lo está vinculando todo a una aplicación que puede escribir en la base de datos (sql mode soup 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, obtiene una plataforma de desarrollo extensible de primera categoría en un cuadro. El ritmo de desarrollo es alto. Es una roca sólida. Las funciones avanzadas son muy útiles. No te decepcionará. No hemos estado.

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 muy difícil trabajar con él.

Ya que no necesita procedimientos almacenados, elimínelo de la lista.

Estarás mucho más contento poniendo la lógica empresarial en el código, no en la base de datos. Si tienes la oportunidad de comenzar " limpio " ;, entonces utiliza la base de datos para lo que tenga más sentido: la persistencia no el procesamiento.

Una vez que tome esa decisión, las diferencias sutiles entre MySQL y PostgreSQL desaparecerán. Ambos son motores relacionales que manejan SQL casi idéntico. Enfócate en las cosas que hacen mejor.

Recomendación : haga que su aplicación sea independiente de cualquier peculiaridad de la base de datos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top