database - programacion - para que sirve sqlite

¿Alguien tiene una base de datos, sugerencias de lenguaje de programación/marco para un sistema de punto de venta GUI? (5)

Java para el lenguaje (o Scala, si quieres ser "vanguardista", dependiendo de cómo pienses apoyarlo y de cómo sean tus desarrolladores, podría ser mejor, pero también peor)

H2 para la base de datos

Swing para GUI

Motivo: gratuito, portátil y bastante estándar.

Actualización: se perdió la parte donde el sistema debería ser una configuración de cliente-servidor. Mi suposición era que la base de datos y el cliente deberían ejecutarse en la misma máquina.

Nuestra empresa tiene un sistema de punto de venta con muchos extras, como la funcionalidad de pedido y recepción, historial de ventas y pedidos, etc. Nuestro problema principal es que el sistema no se diseñó correctamente desde cero, por lo que lleva demasiado tiempo realizar reparaciones y manejar solicitudes de nuestros clientes. Además, la tecnología actual que estamos utilizando (Progress 4GL para el idioma), incurre en una gran cantidad de gastos de licencia en nuestros clientes debido a los aranceles de licencia mutli-user para conexiones de bases de datos, etc.

Después de mucho debate, parece que probablemente volveremos a empezar desde cero (manteniendo el producto actual al menos por el momento). Estamos buscando un par de cosas:

Cree el sistema con una bonita interfaz gráfica de usuario (actualmente es CHUI y la aplicación no se construyó de forma que nos permita rediseñar la interfaz ... sin estratificación o separación de lógica de negocios y gui ... estremecimiento).
Cree el sistema con la capacidad de modularizar diferentes funcionalidades para que el producto no tenga que incluir todas las funciones. Esto mantendría el costo bajo para nuestros clientes actuales que desean funcionalidad básica y un precio más bajo. Las campanas y silbatos estarían disponibles para aquellos que los quisieran.
Use patrones de diseño adecuados para que el producto sea fácil de agregar o cambiar cualquier parte en cualquier momento (es decir, cambie la base de datos o cambie la interfaz sin necesidad de volver a escribir la aplicación o la mayor parte). Hoy es un problema porque el código Progress 4GL se compila directamente en la base de datos. Pequeños cambios en la base de datos requieren mucha recompilación de código.

Nuestro nuevo sistema estará basado en Linux, con la posibilidad de que una aplicación cliente proporcione funcionalidad desde uno o más cuadros de Windows.

Entonces, lo que estoy buscando es cualquier sugerencia sobre qué base de datos y / o marco o lenguaje (s) de programación alguien podría recomendar para este tipo de producto. Cualquiera que tenga experiencia en este campo podría orientarnos en la dirección correcta o incluso tener algunas ideas de qué evitar. Hemos considerado .NET y SQL Express (no necesitamos un DB de nivel empresarial), pero eso nos limitaría a Windows (por lo que sé de todos modos). He oído hablar de Mono para escribir código .NET en un entorno Linux, pero todavía no sé mucho sobre él. También hemos considerado una implementación basada en Java y MySql.

Para resumir, estamos buscando hacer lo siguiente:

Mantenga bajos los costos de licencia sobre la tecnología que utilizaremos para desarrollar el producto (Oracle, ¡gracias! MySQL, bien).
Ofrezca una solución que sea fácil de mantener y admitir.
Una solución que tiene un componente capaz de ejecutarse en hardware "antiguo" a través de una interfaz CHUI. (algunos de nuestros clientes tienen más de 40 terminales, lo que sería una tonelada de efectivo para convertir a una PC).

Las sugerencias serían apreciadas.

Gracias

[ACTUALIZACIÓN] Debo señalar que actualmente estamos realizando un análisis de costo total. Esta pregunta tiene la intención de brindarnos un par de opciones "educadas" para considerar incluir o analizar. Se agradecerá a cualquiera que pueda compartir experiencias / sugerencias sobre configuraciones de cliente / servidor (no solo aquellos que tienen experiencia con sistemas de punto de venta ... eso sería solo una ventaja).

[ACTUALIZAR]

Para cualquiera que esté interesado, terminamos con Microsoft Dynamics NAV, LS Retail (un complemento para el punto de venta y varias otras cosas) y luego hicimos algo (y estamos trabajando actualmente) en el trabajo de personalización además de eso. Esta configuración nos dio la ventaja adicional de tener un sistema de g / l completamente integrado, que carecía de nuestro sistema actual.

Le sugiero que primero investigue sus limitaciones un poco más: hizo una referencia de aprobación a un cliente que usa un tipo particular de terminal, esto puede limitar sus opciones, a menos que el cliente acepte actualizarse.

Necesitas hacer mucho más trabajo en esto. Es genial obtener opiniones de los foros web, pero no podemos conocer su entorno tan bien como usted.

Mi consejo más amplio sobre los golpes sería apuntar a una tecnología ampliamente utilizada. De esta forma, la experiencia en la plataforma es más económica que las tecnologías de "nicho", y será más fácil obtener ayuda si chocas contra una pared de ladrillos. Por supuesto, seguir este consejo puede no ser posible si ya tiene una tecnología no negociable en los clientes.

Mi segunda sugerencia sería completar un plan de proyecto completo, con especificaciones detalladas y estimaciones de costos adecuadas, antes de ir con la opción "reescribir desde cero". En este momento, estás diciendo que sería más barato reescribir el sistema que mantenerlo, y realmente no sabes cuánto costaría volver a escribir.

Que es CHUI? Carácter-UI, como en terminales VT? O incluso el estilo 3270?

Parece que necesita un sistema de 3 niveles: el backend de la base de datos, una capa intermedia que ejecuta la mayor parte de los procesos de negocio back-end y una capa de front-end para CHUI / GUI / data-gateway.

Las tres capas pueden residir en una máquina; o puede distribuir los niveles a varios servidores. La capa de front-end controlaría los terminales reales, ya sean terminales VT, o un navegador web, o una aplicación ''cliente'' escrita a medida.

Asegúrese de haber considerado las necesidades de hardware aquí. ¿Va a tener escáneres de códigos de barras, cajones de efectivo, terminales de débito / crédito de punto de venta, etcétera? Si está utilizando un navegador estándar, puede ser difícil integrar esos elementos de manera confiable. (Por lo menos, es probable que tenga que escribir aplicaciones especiales para manejarlas).

Finalmente, considere la posibilidad de una tecnología de cliente ligero en Windows. Simplifica en gran medida la administración del sistema, ya que solo tiene que actualizar el software de forma central. Las PC Thin-client son baratas, sub $ 200.

Le sugiero que use el navegador para la interfaz de usuario.

Organice su aplicación como una aplicación web.

Hay muchas opciones para el back-end. Puede usar Java + MySQL. El backend de Java lo salvará del debate de Windows / Linux, ya que se ejecutará en ambas plataformas. No tendrá ningún costo de licencia para Java y MySQL. (Editar: Definitivamente hay muchos otros lenguajes que tienen tiempos de ejecución para Linux y Windows incluyendo PHP, Ruby, Python, etc.)

Si sigue esta ruta, también puede considerar Google Web Toolkit (GWT) para crear el front-end basado en navegador de forma modular.

Sin embargo, una palabra de precaución. Los navegadores pueden ser molestos cuando se trata de la administración de la memoria. En nuestra experiencia, este fue el desafío más importante al hacer POS basado en navegador. Es posible que desee verificar Adobe Flex que se ejecuta en el navegador, pero podría ser más civil en su administración de memoria.

Golden Code Development (ver www.goldencode.com) tiene una tecnología que hace la conversión automatizada de Progress 4GL (el esquema y el código ... la aplicación completa) a una aplicación Java con un back-end de base de datos relacional (por ejemplo, PostgreSQL). Actualmente soportan un entorno CHUI muy completo y refactorizan el código. Por ejemplo, la conversión separa la IU, el modelo de datos y la lógica comercial en clases de Java separadas. El resultado completo es un reemplazo directo que es compatible con el original (los usuarios no necesitan volver a formarse, los procesos no necesitan ser modificados, los datos también se migran). Esto es posible porque proporcionan un servidor de aplicaciones y un conjunto de clases de tiempo de ejecución que brindan esa compatibilidad. El resultado de la conversión automatizada no es algo que necesite más edición antes de poder compilarlo y ejecutarlo. Se incluye soporte de terminal verdadero para que los terminales de hardware sigan funcionando (se requiere una pequeña biblioteca JNI para acceder a NCURSES desde Java). Todo el resto del código en el tiempo de ejecución es puro Java. No se usa la tecnología de Progress Software Corp en el sistema resultante y se ejecuta en Linux.

Al menos un sistema convertido ya está en producción, ejecutando un entorno de misión crítica 24 por 7. Es un sistema ERP convertido que su cliente piloto de tamaño mediano usa para administrar todo su negocio.