Código:

CREATE TABLE "workgroups" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "users" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "hash"    TEXT,
    "perm"    INTEGER,
    "active"    INTEGER,
    "expires"    TEXT,
    "wrkgrp"    INTEGER,
    "phone"    TEXT,
    "email"    TEXT,
    FOREIGN KEY("wrkgrp") REFERENCES "workgroups"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "states" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "countries" (
    "idx"    INTEGER,
    "code2"    TEXT NOT NULL UNIQUE,
    "code3"    TEXT NOT NULL UNIQUE,
    "name"    TEXT NOT NULL,
    "nameiso"    TEXT,
    "capital"    TEXT,
    "remark"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
INSERT INTO "countries" VALUES (1,'XX','XXX','None','','None','');
INSERT INTO "countries" VALUES (2,'KR','KRO','Kronos','','First City','');
INSERT INTO "countries" VALUES (3,'VK','VUL','Vulcan','','ShiKahr','');
CREATE TABLE IF NOT EXISTS "cities" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "remark"    TEXT,
    "country"    INTEGER,
    FOREIGN KEY("country") REFERENCES "countries"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "contacts" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "phone"    TEXT,
    "mobile"    TEXT,
    "email"    TEXT,
    "company"    INTEGER,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "owners" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "alias"    TEXT,
    "title"    TEXT,
    "phone"    TEXT,
    "cell"    TEXT,
    "fax"    TEXT,
    "email"    TEXT,
    "logo"    TEXT,
    "address"    TEXT,
    "country"    INTEGER,
    "city"    INTEGER,
    FOREIGN KEY("country") REFERENCES "countries"("idx"),
    FOREIGN KEY("city") REFERENCES "cities"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "customers" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "phone"    TEXT,
    "email"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "categories" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "vatrates" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "rate"    REAL,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "receipts" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    REAL,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "companies" (
    "idx"    INTEGER,
    "company"    TEXT NOT NULL UNIQUE,
    "taxid"    TEXT,
    "vatrate"    INTEGER,
    "receipt"    INTEGER,
    "phone"    TEXT,
    "mobile"    TEXT,
    "address"    TEXT,
    "city"    TEXT,
    "state"    TEXT,
    "zip"    TEXT,
    "remark"    TEXT,
    FOREIGN KEY("vatrate") REFERENCES "vatrates"("idx"),
    FOREIGN KEY("receipt") REFERENCES "receipts"("idx"),
    FOREIGN KEY("city") REFERENCES "cities"("idx"),
    FOREIGN KEY("state") REFERENCES "states"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "vendors" (
    "idx"    INTEGER,
    "vendor"    TEXT NOT NULL UNIQUE,
    "name"    TEXT,
    "lastname"    TEXT,
    "phone"    TEXT,
    "mobile"    TEXT,
    "email"    TEXT,
    "website"    TEXT,
    "address"    TEXT,
    "state"    INTEGER,
    "zip"    TEXT,
    "city"    INTEGER,
    "remark"    TEXT,
    "category"    INTEGER,
    "discount"    REAL,
    "company"    INTEGER,
    "contact"    INTEGER,
    FOREIGN KEY("city") REFERENCES "cities"("idx"),
    FOREIGN KEY("state") REFERENCES "states"("idx"),
    FOREIGN KEY("category") REFERENCES "categories"("idx"),
    FOREIGN KEY("company") REFERENCES "companies"("idx"),
    FOREIGN KEY("contact") REFERENCES "contacts"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "families" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "subgroups" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "composites" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "sizes" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "mod1s" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "mod2s" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);

CREATE TABLE "units" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "materials" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    "code"    TEXT UNIQUE,
    "family"    INTEGER,
    "sgroup"    INTEGER,
    "compo"    INTEGER,
    "msize"    INTEGER,
    "mod1"    INTEGER,
    "mod2"    INTEGER,
    "price"    REAL,
    "unit"    INTEGER,
    FOREIGN KEY("family") REFERENCES "families"("idx"),
    FOREIGN KEY("sgroup") REFERENCES "subgroups"("idx"),
    FOREIGN KEY("compo") REFERENCES "composites"("idx"),
    FOREIGN KEY("msize") REFERENCES "sizes"("idx"),
    FOREIGN KEY("mod1") REFERENCES "mod1s"("idx"),
    FOREIGN KEY("mod2") REFERENCES "mod2s"("idx"),
    FOREIGN KEY("unit") REFERENCES "units"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "tools" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    "price"    REAL,
    "qty"    REAL,
    "unit"    INTEGER,
    FOREIGN KEY("unit") REFERENCES "units"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "tasks" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    "price"    REAL,
    "qty"    REAL,
    "unit"    INTEGER,
    FOREIGN KEY("unit") REFERENCES "units"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "equipments" (                    -- An equipment is a device
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,                        -- Usually is a human readable name that include relevant information, ie: Self Tapping Screw CSK Phillip 4x25mm inox.
    "json"    TEXT,                        -- The definition of the equipment in json format. It is more flexible to define any kind of equipment
    "price"    REAL,
    "qty"    REAL,
    "unit"    INTEGER,
    FOREIGN KEY("unit") REFERENCES "units"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "budgets"
(
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "desc"    TEXT,
    "state"    INTEGER,
    "contractor"    INTEGER,
    "client"    INTEGER,
    "address"    TEXT,
    "creation"    TEXT,    
    FOREIGN KEY("state") REFERENCES "states"("idx"),
    FOREIGN KEY("client") REFERENCES "customers"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "bom" (
    "idx"    INTEGER,
    "hash"    TEXT NOT NULL UNIQUE,
    "material"    INTEGER,
    "budget"    INTEGER,
    "qty"    REAL,
    FOREIGN KEY("material") REFERENCES "materials"("idx"),
    FOREIGN KEY("budget") REFERENCES "budgets"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "accounts" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "owner"    TEXT,
    "desc"    TEXT,
    PRIMARY KEY("idx" AUTOINCREMENT)
);
CREATE TABLE "transactions" (
    "idx"    INTEGER,
    "name"    TEXT NOT NULL UNIQUE,
    "time"    TEXT,
    "desc"    TEXT,
    "account"    INTEGER,
    "operator"    INTEGER,
    "category"    INTEGER,
    "tags"    TEXT,
    "state"    INTEGER,
    "outflow"    REAL,
    "inflow"    REAL,
    "remark"    TEXT,
    FOREIGN KEY("operator") REFERENCES "users"("idx"),
    FOREIGN KEY("category") REFERENCES "categories"("idx"),
    FOREIGN KEY("state") REFERENCES "states"("idx"),
    FOREIGN KEY("account") REFERENCES "accounts"("idx"),
    PRIMARY KEY("idx" AUTOINCREMENT)
);

---

Esta en desarrollo pero mas o menos puede gestionar lo necesario para un programa de gestión de almacén.

---

Este método de trabajo  lo uso desde hace unos años, y en base a esta sentencia SQL de creación de la base de datos (SQLite) permite recrear la base de datos y desplegandola en Sqlite.
Pero al momento del primer arranque crea un archivo con el SQL para recrear la base en otros motores de BBDD como PostgreSQL y MySQL.
Podrían crearse mas módulos como por ejemplo para MS-SQL Server (que corre en Linux, ¿Increíble no?)

Bueno, acompaño en la desición y ayudaré en lo que pueda. Necesitamos un director de projecto, quien se postula???

acompaño en la decisión y ayudaré en lo que pueda

Estoy ordenando los "bloques de código" para armar el programa de gestión.
Para mantener una separación de los procesos internos (y poder repartir el trabajo) decidí re implementar en forma de clases algunas cosas que manejaba con colecciones (mejor tarde que nunca)
Por ejemplo para ingresar al sistema es necesario contrastar que el usuario exista en la base de datos.
En la base de datos no esta guardada la contraseña sino un hash que fue generado a partir de esta y cosas así.
Lo he resuelto así:

Código:

' Gambas class file

Export

Property Read Name As String        '' User name
Property Read Active As Integer     '' User active = 1 , non active = 0
Property Read Level As String       '' User access level.
Property Read Phone As String
Property Read Email As String
Property Read Idx As Integer
Property Read Hash As String
Property Read Data As Data

Property View As String             '' Mode
Property Table As String            '' Table name, current table

Private $Name As String
Private $Hash As String
Private $Expire As String
Private $Level As Integer
Private $Active As Integer
Private $Phone As String
Private $Email As String
Private $Idx As Integer

Private $View As String
Private $Table As String            '' Table name
Private $Data As Data

Public Sub _new(sName As String, sPwd As String, dt As Data, sHide As String)
  $Data = dt
  $Name = sName
  $Hash = Crypt.SHA256(sPwd, sHide)
End

Private Function View_Read() As String
  Return $View
End

Private Sub View_Write(Value As String)
  $View = Value
End

Private Function Name_Read() As String
  Return $Name
End

Private Sub Name_Write(Value As String)
  $Name = Value
End

Private Function Table_Read() As String
  Return $Table
End

Private Sub Table_Write(Value As String)
  $Table = Value
End

Private Function Level_Read() As String
  Return $Level
End

Private Function Email_Read() As String
  Return $Email
End

Private Function Idx_Read() As Integer
  Return $Idx
End

Private Function Hash_Read() As String
  Return $Hash
End

Private Function Data_Read() As Data
  Return $Data
End

Private Function Active_Read() As Integer
  Return $Active
End

Private Function Phone_Read() As String
  Return $Phone
End

El nombre Session creo que ya existe en gambas así que le puse Logon.class la idea es que todos los datos relativos a l usuario estén ahí.
No se si es la manera correcta de manejar estas cosas.
Se aceptan ideas.

El nombre Session creo que ya existe en gambas así que le puse Logon.class la idea es que todos los datos relativos a l usuario estén ahí.
No se si es la manera correcta de manejar estas cosas.

Pues para bases Sqlite, es decir locales, sí puede ser la manera... aunque no entiendo muy bien el enrevesamiento si ya dispones de la Bd. Para bases compartidas en tiempo real con otros usuarios, no. Almacenar datos que no se estén modificando en el momento en local es alejar la información disponible de la existente en la BD. La información del usuario, salvo cuando lo creas o modificas, es algo innecesario y peligroso mantenerla en local. Otro usuario o él mismo puede estar modificándo esa información mientras dura nuestra sesión y entrar en contradicciones.
Así: abres la sesión utilizando un nombre de usuario genérico (este tipo de usuario es muy común aunque yo me opongo radicalmente a su uso) digamos el usuario "Contabilidad", y mientras estás trabajando en la contabilidad otro usuario cambia la contraseña, por ejemplo. Eso deja tu hash local obsoleto y si en algún momento quieres volver a validarlo o quieres regrabar los datos que leiste de la BD, ya estás en problemas.

Los únicos datos que se deben almacenar en local de manera más o menos continuada en el tiempo son aquellos de los que seamos propietarios... pero sigue sin tener mucho sentido hacerlo disponiendo de la BD.

De todas formas, hay algunos datos que no pueden ser cambiados (como los id autonuméricos que identifican al usuario, los fijos del usuario, como el nombre y apellidos y otros propios de la sesión que deben tener efecto a lo largo de la misma, como los permisos de usuario) que sí pueden almacenarse en local por razones de velocidad mientras dure la sesión.

En este sentido os ofrezco una versión simplificada de la clase Usuario que se usaba en mi empresa.

Código:

' Gambas class file

Property idusuarios As Integer Use $idusuarios
Property nick As String Use $nick
Property idpersona As Integer Use $idpersona
Property nombre As String Use $nombre
Property permisos As String Use $permisos
Property clave As String Use $clave

Public Function valida(snick As String, pass As String) As Boolean

  Dim reg As Result
  Dim Conn As New Connection 'Se abre una nueva conexión que se cierra después porque el usuario no puede validarse a sí mismo. Eso lo hace el usuario Administrador.

  Conn.type = "mysql"
  Conn.host = "mihost"
  Conn.user = "Admin"
  Conn.Password = "PUFGVng¡bVZ4ZzJWG2RsV-9GMlI¡" 'En la empresa se usaba un sistema de encriptación propio. Si no es el caso, aquí se puede descargar del servidor un archivo con la clave vía ssh o algo así y comparar después.
  Conn.Name = "MiBD"
  Conn.Open
  If Not Conn.Opened Then
    Message.Error("No se pudieron abrir las bases de datos. Compruebe su conexión a Internet.")
    Return False
  Else
    reg = Conn.exec("select * from Usuarios where nick = &1 and activo=True", snick)
    If reg.Available Then
      If pass = reg!clave Then
        $idusuarios = reg!idusuarios
        $nick = reg!nick
        $idpersona = reg!idpersona
        $nombre = reg!nombre
        $clave = pass
        $permisos = reg!permisos
        Conn.Close
        Return True
      Endif
    Endif
    Return False

  Catch
    Message("Error: " & Error.Text & "\nEn: " & Error.where)

End

Saludos

Hola

Veo que ya se están publicando códigos y esquemas de bases de datos, pero no he visto realmente un croquis, diagrama o planteamiento de qué programa se va a realizar, cuáles son sus funciones y cómo abordarlo de forma ordenada.

Por lo que he visto hasta ahora, parece una especie de gestor para una empresa de jardinería o algo así, pero no estoy seguro. Creo que primero se debería discutir cómo debe ser el enfoque, las necesidades, los formularios implicados, si hay una APIRest para servir a dispositivos remotos, en general habría que trabajar mucho sobre el papel antes de ir planteando códigos.

Por otra parte, gracias a unos cursos que tincho y yo estamos siguiendo, yo tiraría para una base de datos postgres en un contenedor Docker, porque así es muy fácil levantarla, replicarla y poder trabajar localmente sin romper la del servidor, etc. Hoy día, en desarrollos profesionales es la manera preferida de trabajar. ¿Qué os parece?

Saludos

Yo soy un jubileta apoyado en la valla, pero me parece perfecto. Como creo haber dicho antes, lo primero es decidir qué programa se quiere hacer y después la creación de roles que conllevan la creación de "autoridades" dentro del proyecto. Si el encargado de Contabilidad dice que así, pues así, pero si cada uno tira por un lado... caos, caos, caos...

Saludos

Pues para bases Sqlite, es decir locales, sí puede ser la manera... aunque no entiendo muy bien el enrevesamiento si ya dispones de la Bd. Para bases compartidas en tiempo real con otros usuarios, no. Almacenar datos que no se estén modificando en el momento en local es alejar la información disponible de la existente en la BD. La información del usuario, salvo cuando lo creas o modificas, es algo innecesario y peligroso mantenerla en local. Otro usuario o él mismo puede estar modificándo esa información mientras dura nuestra sesión y entrar en contradicciones.
Así: abres la sesión utilizando un nombre de usuario genérico (este tipo de usuario es muy común aunque yo me opongo radicalmente a su uso) digamos el usuario "Contabilidad", y mientras estás trabajando en la contabilidad otro usuario cambia la contraseña, por ejemplo. Eso deja tu hash local obsoleto y si en algún momento quieres volver a validarlo o quieres regrabar los datos que leiste de la BD, ya estás en problemas.

No estoy hablando de guardar nada en local, los datos siempre se guardan en la base de datos, sea la que sea.
La clase Logon.class es para el trabajo interno en el programa gambas.
Por ejemplo para que un formulario muestre unos controles o no de acuerdo al nivel de acceso del usuario, o cuando el programa cliente envie datos al programa servidor estos datos puedan firmarse con los datos que están en las propiedades de la clase y cosas por el estilo.

---

yo tiraría para una base de datos postgres en un contenedor Docker, porque así es muy fácil levantarla, replicarla y poder trabajar localmente sin romper la del servidor, etc. Hoy día, en desarrollos profesionales es la manera preferida de trabajar. ¿Qué os parece?

Cuando "el programa" este en producción estoy de acuerdo en usar un verdadero motor de bases de datos como PostgreSQL pero el el modeo depuración, es decir en el momento de moldear la base de datos etc, con sqlite es suficiente. Pero luego el programa Servidor, que es el que se comunica con la base de datos, simplemente lo hacemos apuntar a otra base de datos (prosgresSQL) y listo. Lo de SQLite es muy practico para desarrollar e ir adaptando la base de datos, ya que en el caso de motores de bases de datos es un poco mas trabajoso cambiar la base de datos a medida que el software lo va necesitando.
Referente a los curdos que comentas están orientados a el lado cliente y es justamente por este motivo que me interesa que hagamos la parte servidor en gambas y la parte cliente luego puede implementarse en varios lenguajes, que que lo que hagamos en gambas+BBDD presentara una interfase de dialogo o API, no estoy seguro del todo como se implementa esto en gambas y si API es el termino correcto pero la idea esta.

---

...pero no he visto realmente un croquis, diagrama o planteamiento de qué programa se va a realizar...

ok, preparo algo en ese sentido y lo propongo por este medio así lo discutimos.

No estoy hablando de guardar nada en local, los datos siempre se guardan en la base de datos, sea la que sea.

Me he explicado mal usando "almacenar". No hablo de guardar en disco. Una colección de datos en memoria ram también es local. Si conectamos nuestro supuesto programa a las 9 de la mañana, cargando los datos en esa colección y no lo vamos a cerrar hasta las 14 horas que nos vamos a casa, estamos guardando en local los datos durante 5 horas. Si luego usamos esos datos, estamos cinco horas desfasados con respecto al resto de usuarios.
 

yo tiraría para una base de datos postgres en un contenedor Docker, porque así es muy fácil levantarla, replicarla y poder trabajar localmente sin romper la del servidor, etc. Hoy día, en desarrollos profesionales es la manera preferida de trabajar. ¿Qué os parece?

Es lo más correcto... pero es un poco matar moscas a cañonazos, creo.  La Base de Datos se crea antes que el código. Eso quiere decir que para cuando os sentéis a programar todo lo relativo a la BD debería estar ya solucionado y ésta creada. Si hay algún desarrollador que no tenga internet en su ordenador... pues que se ubique en un museo porque eso no pasa hoy en día.
Con la base creada y la gente con capacidad de conectarse con ella no hace falta replicarla para nada y, desde luego, crear una BD en SQLite para hacer un programa de prueba que luego haya que reprogramar para que se adapte a la BD "buena", es una pérdida de tiempo, recursos y algo completamente inútil.

Otro tema es PostgreSql versus MaríaDB o MySQL. Postgre es el mejor, el más grande, el más potente... y el menos conocido, el menos utilizado y el menos aprovechado para desarrollos pequeño-medianos. Todos hemos tocado, más o menos, MySQL pero ¿Quién ha trabajado alguna vez con PostGre?

Si yo tuviese voto, votaría por MariaDB o MySQL en un servidor "normalito" de esos de 7€ al mes (2€ si contratas un montón de meses) y ya. Si alguien quiere una copia en local basta con hacer click en los repositorios e instalar MySQL desde ahí. Como la BD se alcanza vía IP, basta con cambiar ésta en el fichero de configuración de la aplicación para usar la copia local o la remota. No se modifica nunca la copia Local. Si hay que modificar la estructura que se acordó, se pide al encargado de la BD.

No olvidemos que la idea es crear, probar y pulir un equipo de desarrollo en el foro, no hacer algo que esté a la ultima y que nadie, al final, entienda ¿Quién sabe montar un docker? (¿quién sabe qué es un docker, si a eso vamos?) ¿Qué servidor y qué potencia se necesita para montar uno que resuelva relativamente bien el tema? (En mi anterior empresa, cuando montamos un docker tuvimos que comprar un super ordenata (2.500€, me dice mi vieja memoria) para manejarlo con fluidez), etc. etc.

Por otra parte hay una cosa que se llama la "Curva de aprendizaje grupal", que es la misma que la personal pero para el equipo. Habrá gente que esté aburrida de manejar BBDD y otra que nunca en su vida lo ha hecho, habrá gente que configure servidores desde 0 antes de desayunar y otra para la que eso sea un escollo insalvable. Si esto fuese una empresa departamental, no problema. Se asigna a cada uno el rol que mejor cuadre a su background (como se dice ahora) y a los demás les importa un pepino cómo o qué hace dentro de él. Sólo importan los resultados. Pero, repito, esto es un desarrollo de prueba entre amigos y colegas sólo por divertirse y probarse y creo que todo interesa a todos... más o menos por lo que entrar en honduras sobre instalación de servidores y BBDD mega potentes, etc, me parece un error.

Y por último decir que creo que me estoy pasando de mensajitos y propuestas estando, como estoy, al otro lado de la valla. Señor, señor, si es que soy un vicioso...

Saludos

Bien, lo que planteo es lo siguiente
Construir una aplicación de gestión de informacion de una empresa que tenga:

• Control de stock de almacén, por ejemplo: Tornillos, herramientas, etc.
  
• Proyectos & Fabricación de productos, por ejemplo: Maquina de cerveza 50L (que el programa tenga un cometido noble no? ), Parrilla de carbón con tapa, etc.
  
• Gestión de la contabilidad interna.
  
• Gestión de horas de trabajo de los empleados.
  
• Etc. pueden agregarse mas cosas, pero no tiene que afectar a la estructura básica del programa
  

Para hacerlo propongo la siguiente estructura:

Server es una aplicación escrita en Gambas 3 que:

• Corre en un servidor Linux, no necesariamente con GUI, es decir un servidor "ciego"
  
• Dialoga con una base de datos: SQLite, PostgreSQL, MySQL (primera etapa lo hacemos con SQLITE para moldear la base de datos luego escalamos por supuesto ya que sqlite no es multi usuario)
  
• Escucha las peticiones de los programas Cliente, que pueden estar escritos en varios lenguajes diferentes: Gambas, Dart, JS, Etc.
  
• Autenticación de usuarios de los programas Cliente contra la base de datos
  

Client es una aplicación que se comunica con Server a través del protocolo HTTP, HTTPS:
Corre en y esta programado en:

• Linux - Gamabas3
  
• Navegadores Web - Javascript,
  
• Smartphones Android - Flutter Dart.
  

Algo como esto:


Etapas de trabajo:

1. Crear un programa servidor de terminal, es decir, sin entorno gráfico GUI.
   
2. Crear programa cliente des escritorio para Linux en gambas 3 con GUI.
   
3. Comunicar ambos programas
   
4. Crear la base de datos (SQLite) con la que hable el servidor.
   
5. Agregar, alterar, borrar registros de la base de datos desde un programa cliente
   
6. Establecer algún sistema de autenticación segura.
   
7. Diseñar los formularios del programa cliente
   
8. Desplegar un motor de bases de datos de producción, crear la base de datos.
   
9. Cambiar el archivo de configuración del programa servidor para que se comunique con la base de datos del motor de producción.
   
10. Crear un programa cliente en otros Frameworks / Lenguajes
    

Trabajo repartido entre los desarrolladores:

D1: Crear las clases para comunicaciones cliente / servidor. [ ? ]
D2: Crear la base de datos [Tincho]
D3: Crear las clases para manejar las tablas de la base de datos en gambas (en el servidor). [ ? ]
D4: Crear los formularios para los diferentes flujos de trabajo contra la base de datos [ ? ]
D5: Crear y adaptar iconos para los formularios [Tincho]
D6: Preparar plantillas SVG para imprimir informes, facturas etc.[ ? ]

La idea subyacente es desarrollar todo el sistema de forma flexible en cuanto a los programas Cliente y de forma estandarizada respecto a la base de datos el Servidor y el protocolo de comunicación.

Nota: Si algún concepto esta equivocado, obsoleto o simplemente hay una idea mejor, no duden en proponerla.

---

Con la base creada y la gente con capacidad de conectarse con ella no hace falta replicarla para nada y, desde luego, crear una BD en SQLite para hacer un programa de prueba que luego haya que reprogramar para que se adapte a la BD "buena", es una pérdida de tiempo, recursos y algo completamente inútil.

Yo tengo hechos unos métodos y clases que permiten desarrollar y probar el programa con sqlite de forma fácil para el programador ya que puede agregar campos o modificar la estructura de la base en en solo lugar en el archivo .sql que esta en el proyecto del programa. luego cada vez que el programa corre en depuración crea automáticamente la sentencia query para crear la base de datos en PostgreSQL y MySQL. De esta manera se puede trabajar en la programación de los algoritmos sin tener que tocar nada del código cuando se cambia algo en la query.sql.

---

¿Quién ha trabajado alguna vez con PostGre?

Yo

---

Si hay que modificar la estructura que se acordó, se pide al encargado de la BD.

Ese es el problema, no es nada practico "acordar" una BD y tirar para adelante cuando la aplicacion se esta creando ya que en el desarrollo surgen muchas modificaciones a la BD y el que la maneje en este caso me auto asigne ese trabajo, estará todo el tiempo toqueteando la base de datos.
Cuando el desarrollo logre cierta estabilidad en cuando a los datos si que hacemos el pase a PG o MY

---

No olvidemos que la idea es crear, probar y pulir un equipo de desarrollo en el foro, no hacer algo que esté a la ultima y que nadie, al final, entienda ¿Quién sabe montar un docker? (¿quién sabe qué es un docker, si a eso vamos?) ¿Qué servidor y qué potencia se necesita para montar uno que resuelva relativamente bien el tema? (En mi anterior empresa, cuando montamos un docker tuvimos que comprar un super ordenata (2.500€, me dice mi vieja memoria) para manejarlo con fluidez), etc. etc.

Creo que cuando Jesús se refiere a Docker lo hace pensando en un servicio en la nube de Google, Amazon o algun otro. Pero eso es para la etapa de producción.

---

Por otra parte hay una cosa que se llama la "Curva de aprendizaje grupal", que es la misma que la personal pero para el equipo. Habrá gente que esté aburrida de manejar BBDD y otra que nunca en su vida lo ha hecho, habrá gente que configure servidores desde 0 antes de desayunar y otra para la que eso sea un escollo insalvable. Si esto fuese una empresa departamental, no problema. Se asigna a cada uno el rol que mejor cuadre a su background (como se dice ahora) y a los demás les importa un pepino cómo o qué hace dentro de él. Sólo importan los resultados. Pero, repito, esto es un desarrollo de prueba entre amigos y colegas sólo por divertirse y probarse y creo que todo interesa a todos... más o menos por lo que entrar en honduras sobre instalación de servidores y BBDD mega potentes, etc, me parece un error.

Yo lo veo mas como pensamiento lateral. Claro que unos manejan cosas mejor que otros y justamente es bueno eso, porque se establece un dialogo (a veces un poco tenso jeje, Terco sabe de lo que hablo) pero en el camino vamos aprendiendo e influyendo unos en otros.
Como programadores y quiero pensar que como personas también, seremos mejores.

En cuanto a la comunicación con la base de datos, independientemente de la que se elija, es que nunca se debe acceder directamente a ella en remoto, nunca. Para eso se crea un interfaz en gambas que acepte y devuelva resultados en base a una API(Rest) que esté asegurada con una autenticación cliente/servidor. Es decir, el programa cliente nunca accede directamente a la base de datos, sino que ejecuta peticiones http(s) a la API que dialoga directamente con la BD en el mismo servidor pero sólo tras autenticarse con el cliente.

Hacerlo de otra forma es abrir una enorme brecha de seguridad.

En cuanto al despliegue de Docker, es algo trivial y barato en términos de procesamiento, si sólo quieres una BD de desarrollo en una máquina local, de manera que cuando llegue el momento de producción, se migre a un servidor cloud junto con la aplicación gambas con mucha facilidad.





Saludos