Después de un intenso trabajo de refundición, recopilación, y poda despiadada, he establecido la que, de momento, es la estructura "definitiva" del proyecto Intriga.

La tenéis en esta imagen:


Estas son las tablas con relación. A ellas hay que sumar otras 9 tablas sin relación de las que ya se hablará luego.
El concepto de estas entidades y relaciones, en seudo-código sería (en negrita el nombre de las tablas):
 Una empresa tiene usuarios que son personas que están en sedes.
Los usuarios tienen equipos adscritos
Los equipos envían datos al colector que levanta alertas que tienen categorías y umbrales asociados a acciones a tomar.

         Si hay software propio en la empresa entonces:
 
Los programas (incluido el propio Intriga, claro) tienen una jerarquía de permisos asociados a sus usuarios que controla sus capacidades dentro de los mismos
Los programas registran sesiones que tienen alertas que tienen categorías y umbrales asociados a acciones a tomar.
Los programas registran un log de actividades realizadas por los usuarios.

He tenido que simplificar mucho la estructura original y en caso de empresas complejas habría, quizá que retocar algo, pero de momento, para empezar a levantar la carpa del circo, vale.
Hay cositas que pulir aún y saldrán a la luz pero hay una que me trae un poco de cabeza porque no se me ocurre cómo hacerlo:
Si os fijáis hay un "corte" en la estructura de las relaciones: La tabla colector, que recibe los datos de los equipos, debería estar relacionada con la tabla equipos... pero no se me ocurre cómo. Es decir: ¿Cómo identificar unívocamente un equipo... teniendo en cuenta que casi todo (nombres, piezas, etc.) puede cambiarse? Si le pongo el número de serie del disco, por ejemplo, el usuario puede cambiarlo por avería o mejora y ya se fastidió, lo mismo con las memorias, la placa base, el hostname o lo que sea. ¿Un fichero camuflado en la tripas del SO? con la frecuencia de actualización del sistema y la afición al cambio de distros... tampoco vale ¿Una combinación de varias cosas? quizá pero ¿cuales?
En principio me incliné por el número de serie de la placa base pero la forma de obtenerlo que conozco (el comando dmidecode) no siempre la ofrece...
A ver qué se os ocurre.

Saludos.

---

En el caso del Autónomo que tiene clientes, el autónomo es la Empresa, los clientes son los Usuarios. La titularidad de las máquinas sería "Externa" y el nivel de datos a recibir por el colector habría, quizá que limitarlo... más o menos.

• Un certificado digital creado a partir de los datos del usuario. Pero eso identifica al usuario, no al hardware.
  
• Un certificado de fecha en la que se instaló el hardware inicialmente o se asignó ese hardware (la máquina) a la empresa o al usuario.
  
• Un identificador UUID aleatorio, pero que nunca se repite, guardado en un fichero escondido o algo así
  

Generador de claves UUID

No se me ocurre otra cosa, salvo hacer lo mismo que el punto 3, pero a partir del UID del HD o de otro hardware

Saludos

En el caso del Autónomo que tiene clientes, el autónomo es la Empresa, los clientes son los Usuarios. La titularidad de las máquinas sería "Externa" y el nivel de datos a recibir por el colector habría, quizá que limitarlo... más o menos.

Pero ¿y si el autónomo tiene técnicos contratados? Pues esos técnicos gestionarían máquinas de clientes y el "jefe" gestionaría máquinas de sus técnicos y de clientes también. Ese caso es bastante común

Pero ¿y si el autónomo tiene técnicos contratados? Pues esos técnicos gestionarían máquinas de clientes y el "jefe" gestionaría máquinas de sus técnicos y de clientes también. Ese caso es bastante común

Esos técnicos son los usuarios de Intriga. Intriga es regido por sus propias normas y no se diseñó para ser usado sólo por una persona (De hecho éramos tres). Estos usuarios pueden tener también limitados sus derechos dentro del programa, por ejemplo, pueden tener acceso a la parte de las máquinas y las alertas pero no a la de las empresas y usuarios, etc. etc.

Saludos

Si os fijáis hay un "corte" en la estructura de las relaciones: La tabla colector, que recibe los datos de los equipos, debería estar relacionada con la tabla equipos... pero no se me ocurre cómo. Es decir: ¿Cómo identificar unívocamente un equipo... teniendo en cuenta que casi todo (nombres, piezas, etc.) puede cambiarse? Si le pongo el número de serie del disco, por ejemplo, el usuario puede cambiarlo por avería o mejora y ya se fastidió, lo mismo con las memorias, la placa base, el hostname o lo que sea. ¿Un fichero camuflado en la tripas del SO? con la frecuencia de actualización del sistema y la afición al cambio de distros... tampoco vale ¿Una combinación de varias cosas? quizá pero ¿cuales?
En principio me incliné por el número de serie de la placa base pero la forma de obtenerlo que conozco (el comando dmidecode) no siempre la ofrece...
A ver qué se os ocurre.

Lo que buscas se llama:
cat /etc/machine-id
https://www.freedesktop.org/software/sys...ne-id.html
Saludos.

Después de un intenso trabajo de refundición, recopilación, y poda despiadada, he establecido la que, de momento, es la estructura "definitiva" del proyecto Intriga.

Feedback:

• Los nombres de los campos con acentos NO
  
• Los nombres en castellano NO
  
• Hay mucha información redundante, por ejemplo una persona tiene una sede y esa sede tiene una provincia listo, veo innecesario vincular una persona a una sede y una provincia, porque una sede jamas estará en dos o mas provincias ergo es redundante.
  

Adjunto un ejemplo SQL de como yo nombro los campos y como relacionar las tablas un poco mas eficientemente.


Para relacionar computadora con colector podes usar id-machine que viene en todas las ditros modernas.
Estos son los nombres que propongo:

Cada table tiene los mismos campos base y todos los campos son diferentes en toda la base porque cada tabla tiene una letra que esta siempre al principio de cada campo, esto evita problemas y simplifica las consultas SQL al no tener que poner el nombre en la forma tabla.campo.

Código:

BEGIN TRANSACTION;
CREATE TABLE IF NOT EXISTS "usrs" (
    "uidx"    INTEGER,
    "uname"    TEXT UNIQUE,
    PRIMARY KEY("uidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "firms" (
    "fidx"    INTEGER,
    "fname"    TEXT UNIQUE,
    PRIMARY KEY("fidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "states" (
    "qidx"    INTEGER,
    "qname"    TEXT UNIQUE,
    PRIMARY KEY("qidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "picker" (
    "didx"    INTEGER,
    "dname"    TEXT UNIQUE,
    PRIMARY KEY("didx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "alerts" (
    "yidx"    INTEGER,
    "yname"    TEXT UNIQUE,
    PRIMARY KEY("yidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "alertscls" (
    "zidx"    INTEGER,
    "zname"    TEXT UNIQUE,
    PRIMARY KEY("zidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "logon" (
    "sidx"    INTEGER,
    "sname"    TEXT UNIQUE,
    PRIMARY KEY("sidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "levels" (
    "tidx"    INTEGER,
    "tname"    TEXT UNIQUE,
    PRIMARY KEY("tidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "partners" (
    "ridx"    INTEGER,
    "rname"    TEXT UNIQUE,
    PRIMARY KEY("ridx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "actions" (
    "xidx"    INTEGER,
    "xname"    TEXT UNIQUE,
    PRIMARY KEY("xidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "offices" (
    "oidx"    INTEGER,
    "oname"    INTEGER UNIQUE,
    "ostate"    INTEGER,
    PRIMARY KEY("oidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "staff" (
    "pidx"    INTEGER,
    "pname"    TEXT UNIQUE,
    "poffice"    INTEGER,
    "puser"    INTEGER,
    PRIMARY KEY("pidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "devices" (
    "bidx"    INTEGER,
    "bname"    TEXT UNIQUE,
    "buser"    INTEGER,
    PRIMARY KEY("bidx" AUTOINCREMENT)
);
CREATE TABLE IF NOT EXISTS "membership" (
    "midx"    INTEGER,
    "mname"    INTEGER UNIQUE,
    "mdevice"    INTEGER,
    "muser"    INTEGER,
    FOREIGN KEY("mdevice") REFERENCES "devices"("bidx"),
    FOREIGN KEY("muser") REFERENCES "usrs"("uidx"),
    PRIMARY KEY("midx" AUTOINCREMENT)
);
COMMIT;

Saludos.

Lo que buscas se llama:
cat /etc/machine-id

Sí... y no. Ese machine-id está atado al SO y no sobrevive a una reinstalación del sistema, cosa muy normal en las empresas sobre todo porque no hay tiempo de ir haciendo pequeñas upgrades y así te encuentras con máquinas que corren con versiones del SO muy antiguas a las que hay que instalar la versión nueva desde cero. Ahí ese machine-id habría que ser transportado desde la BD a la máquina, no al revés porque habría que retocar todos los logs, cosa "ilegal". Imagino que un sudo nano machine-id sería suficiente. Si no hay limitación para ese cambio manual de machine-id, podría valer.
 

• Los nombres de los campos con acentos NO
  
• Los nombres en castellano NO
  

Lo de los nombres inglesizados... no me gusta... puede valer como convención pero de alguna manera oscurece el código a mis hispánicos y viejunos ojos. En principio parece que mola, por aquello del público internacional y todo eso... pero si pones los pies en la realidad de las expectativas de tu programa puede ser un trabajo innecesario (me refiero a que el código ya está hecho en español y la perspectiva de que algún día un anglo se interese por él para no sé qué se me hace muuuy lejana). No es que no lleves razón, es que no me gustó nada la experiencia de "inglesizar" el soprano, que aparte de lo que me costó, generó mogollón de bugs... aún así no lo descarto. Empezaré a toquetear y subir a Git código y veré si la inglesización no me es demasiado penosa...

Es curioso cómo las BB.DD. se van aplicando en adaptarse a todos los idiomas y cómo los programadores se van aplicando en adaptarse al inglés...
 

Hay mucha información redundante, por ejemplo una persona tiene una sede y esa sede tiene una provincia listo, veo innecesario vincular una persona a una sede y una provincia, porque una sede jamas estará en dos o mas provincias ergo es redundante.

Una persona tiene una dirección particular cuya provincia debe ser normalizada a efectos de mailing, teletrabajo y demás. Una sede, es decir su centro de trabajo presencial, tiene su propia provincia que también ha de ser normalizada a los mismos efectos. No hay redundancia ahí.
Una persona no se puede relacionar directamente con una sede porque puede tener distintos roles(usuario) dentro de la empresa y estar adscrito, por tanto, en distintas sedes.
El tema de los roles y los entornos es una de las cosas que tuve que simplificar porque el que se aplicaba a mi empresa era absolutamente peculiar y no estandarizable.

Por otra parte es cierto que hay redundancias. Muchas fueron puestas intencionadamente para ahorrar trabajo en las consultas SQL. Por ejemplo, para saber dónde está un equipo ubicado tienes que pasar de la tabla equipos->equipos_adscripcion->usuarios.sede... y eso porque le dejé a la sede el nombre como clave primaria. Si hubiese tenido un rowid de clave, sería equipos->equipos_adscripcion->usuarios->sede. Redundando el campo sede y dejando el nombre como clave primaria, sólo tienes que ir de equipos->equipos adscripción.
Es un fallo por cuanto para eso están las vistas... pero uno no siempre firmaría hoy lo que hizo ayer.
 

Cada table tiene los mismos campos base y todos los campos son diferentes en toda la base porque cada tabla tiene una letra que esta siempre al principio de cada campo, esto evita problemas y simplifica las consultas SQL al no tener que poner el nombre en la forma tabla.campo.

Sí... si te los sabes y los recuerdas y si se los saben los demás programadores y los recuerdan. Ese tipo de atajos está bien cuando el código no sale de tus manos y cuando lo estás haciendo y lo tienes claro en la cabeza. Tres años después tienes que modificar algo y el esfuerzo es doble. El par Tabla.Campo (más aún, el trío BD.Tabla.Campo, cosa que en intriga se usa bastante cuando se relaciona con las distintas bases de datos de los distintos programas que se coordinen con el sistema) no da lugar a dudas y no precisa habilidad nemotécnica alguna.


Gracias por el feed-back


Saludos

---

El check verde que has colocado sobre el campo sede de la tabla colector... llevas toda la razón. Es un remanente de los viejos tiempos pre-VPN, donde el acceso se hacía a través de LAN distintas y routers y demás. En ese campo se recogía, creo recordar, el nombre del servidor local. La vpn lo dejó obsoleto. Ahora sobra ahí.

Saludos

Muy cauto yo, he probado con una máquina virtual y sí, se puede retocar el machine-id sin problemas.
Aprobado el cambio, pues, usaremos machine-id como identificador de la máquina.
No obstante, según la página que enlazaste más arriba, no es una información que deba rularse por ahí... mejor usamos algo así como crypt(file.load("/etc/machine.id") ¿no?
O quizá sean paranoias de seguridad raras... porque me surge una duda, dada mi ignorancia en el tema de encriptaciones y claves de dirección única: ¿crypt devuelve siempre la misma cadena independientemente de la máquina, momento, lugar y fase de la luna en que se ejecute? Mientras no se garantice eso, quizá sea mejor usar el machine-id tal cual... creo.

Saludos

crypt(file.load("/etc/machine.id") ¿no?

En los ejemplos que vi en stack overflow usan sha256sum para crear una id a partir del machine-id que siempre es el mismo ya que la fras que se usa es la machine-id.
[code]
Saludos.

También se puede hacer con el crypt de gambas y una frase propia:

Código:

Public Sub claveEquipo()

    Return Split(Crypt.SHA256(File.Load("/etc/machine-id"), "madeinintriga"), "$").Last
    
End

No se si vale la pena tanto rollo, en serio. Lo que hay que almacenar como clave de equipos es el machine-id tal cual y el encriptado es sólo para ser transmitido... pero no olvidemos que estamos en ambiente encriptado ya de por sí por la VPN.


Saludos