Generazione chiave come firma del record

[caezan]

Buongiorno, avrei bisogno di generare un valore di chiave che mi rappresentasse univocamente un record.
La situazione è la seguente:
- ho una serie di campi di tipo numerico, testuale (fino a 256 char) e data che mi identificano univocamente un record;
- la concatenazione dei valori dei campi darebbe un valore troppo lungo; inoltre un campo chiave di tipo timestamp o incrementale non sarebbe adeguato in quanto l'istante temporale è indipendente dai valori dei campi, mentre un progressivo è soggetto a potenziali rigenerazioni (ovvero ripartenze da 1);
- vorrei una funzione che codificasse i valori di questi campi verso un valore unico (testuale o numerico) in modo da farlo diventare un valore chiave; è come se fosse un CRC del record, oppure una funzione di hash.
Ho già una soluzione però volevo sentire se qualcuno ha affrontato e risolto il problema in precedenza per non reinventare la ruota.
Grazie

[BFS]

premesso che non uso access come BE..
ma il vecchio campo contatore non fa il caso tuo?

BFS

[caezan]

> > Buongiorno, avrei bisogno di generare un valore di chiave che mi rappresentasse univocamente un record.

> premesso che non uso access come BE..
> ma il vecchio campo contatore non fa il caso tuo?

Purtroppo no perché non riesco a garantire l'univocità del record.
Il campo contatore potrebbe essere soggetto a rinumerazioni in futuro, quindi è troppo rischioso utilizzarlo per identificare un record.
La firma di un record mi permette di individuarlo precisamente e per sempre, ovvero di evitare le eventuali manipolazioni dei suoi valori e di decidere se è nuovo oppure già storicizzato.
Farlo con un valore di chiave simil CRC è molto efficiente.

[BFS]

Il 05/02/2024 09:27, caezan ha scritto:
>>> Buongiorno, avrei bisogno di generare un valore di chiave che mi rappresentasse univocamente un record.

> Il campo contatore potrebbe essere soggetto a rinumerazioni in futuro, quindi è troppo rischioso utilizzarlo per identificare un record.

questa mi è nuova
come fai a rinumerare un campo contatore?
andrebbero in malora tutte le relazioni con le altre tabelle


credo che il contatore si ri-azzeri solo nel caso di tabelle vuote, db
compattato e nessuna relazione

BFS

[caezan]

Ma non è vero, dipende da come lo usi e se non usi solo Access.
Io programmo oramai applicativi che vedono sempre 3 attori in gioco: Access , SQL Server e MySQL (o altro).
Talvolta ho la necessità di distruggere e ricostruire indici e/o chiavi, pertanto ho bisogno di un secondo campo chiave per scopi specifici di cui avere il pieno controllo, per esempio per identificare univocamente un record come previsto da alcune normative o procedure di automazione industriali.
Cmque ho trovato su internet un tentativo di soluzione cercando "ms access calculate a checksum for a record" ma preferisco farmi una soluzione, credo che attingerò dagli algoritmi per le funzioni hash oppure dal CRC-16-CCITT : https://it.wikipedia.org/wiki/Cyclic_redundancy_check

[BFS]

Il 05/02/2024 10:26, caezan ha scritto:
> Talvolta ho la necessità di distruggere e ricostruire indici e/o chiavi

ah beh...
senza questa informazione era dura capire il motivo

BFS

[RobertoA]

Il 05/02/2024 10:26, caezan ha scritto:

https://nolongerset.com/createguid/

[caezan]

> > Cmque ho trovato su internet un tentativo di soluzione cercando "ms access calculate a checksum for a record" ma preferisco farmi una soluzione, credo che attingerò dagli algoritmi per le funzioni hash oppure dal CRC-16-CCITT : https://it.wikipedia.org/wiki/Cyclic_redundancy_check
> https://nolongerset.com/createguid/

Grazie. Volevo far fare il lavoro a SQL Server con l'istruzione CHECKSUM ma non è sicuro e può produrre collisioni:
https://sqlserverrider.com/2013/02/23/checksum-and-checksum-function-sql-server/
https://weblogs.sqlteam.com/peterl/2010/08/19/checksum-weakness-explained/
Meglio ragionarci sopra per trovare una soluzione su misura e poi eventualmente generalizzarla.

[Bruno Campanini]

caezan explained :

Qui da noi il Venerdì c'è un mercato rionale in cui trovi un po'
di tutto: le uova con due tuorli, le banane con buccia d'arancio
(vanno a ruba fra i programmatori di Access!) e tante altre cose
che nemmeno la coglioneria umana riesce ad immaginare.
Vi troveresti senz'altro qualcosa d'interessante.

Bruno

[RobertoA]

Il fatto che a te non sia mai servita una funzione un po' particolare,
come quella richiesta, non significa che questa funzione sia inutile
Questo commento potevi risparmiartelo

[Bruno Campanini]

RobertoA wrote on 05-02-24 :

Se mi spieghi la sua utilità pratica, cioè quella non relativa alle
mestruazioni dell'OP, e ne predisponi la programmazione,
avrai le mie scuse e i miei risarcimenti.

Bruno

[RobertoA]

Che io ti spieghi oppure no e' perfettamente inutile
Come pure le tue scuse lo sono
Utile sarebbe che portassi rispetto verso chi sta chiedendo un aiuto
Che a te sembri un quesito semplice, o di nessuna utilita', non ha
nessuna importanza
Non sei tu che puoi decidere se una domanda e' lecita oppure no

[caezan]

Evito di rispondere alle offese gratuite, piuttosto dico che la questione è affrontata da ogni DBMS che sia MySQL, SQL Server, PostgreSQL, ecc. con comandi specifici tipo CHECKSUM ( * | expression [ ,...n ] ) https://learn.microsoft.com/it-it/sql/t-sql/functions/checksum-transact-sql?view=sql-server-ver16
E' un argomento complesso che necessita di essere studiato da menti esperte...
Un esempio di utilità è per il trattamento affidabile dei dati utili all'Industria 4.0, talvolta estratti in CSV e potenzialmente soggetti a cambiamenti nel corso del tempo (anche sul campo chiave, a volte inesistente...), ma non sto a spiegare la pappardella perché non siamo al mercato delle "banane all'arancia", la cui esistenza è a me sconosciuta perché non frequento certi ambienti ;-)

[RobertoA]

Come pure nello scambio dati tra db distribuiti, quando due basi di dati
distinte non 'si parlano' e saltuariamente si scambiano dati, uno dei
sistemi e' piazzare un guid su un campo di ogni record per capire quale
record di un db corrisponde ad un record altro db
Ma non e' questo il punto

[caezan]

> Come pure nello scambio dati tra db distribuiti, quando due basi di dati
> distinte non 'si parlano' e saltuariamente si scambiano dati, uno dei
> sistemi e' piazzare un guid su un campo di ogni record per capire quale
> record di un db corrisponde ad un record altro db
> Ma non e' questo il punto

E' esattamente questo di cui necessito, salvataggio dati in locale e (a)sincronizzazione verso DBMS remoto (anche su Cloud) del differenziale quando la rete è disponibile.
Per un periodo puoi arrangiarti con query e Group By tra record storicizzati e nuovi, ma la soluzione col checksum è formalmente piu corretta.
Vorrei averne il pieno controllo con un algoritmo robusto rispetto ad utilizzare i comandi CHECKSUM basati su hashing, che non garantiscono l'assenza di collisioni anche se di bassa probabilità, tutto qui.
Tolgo il disturbo.

[RobertoA]

Non hai capito, dicevo "non e' questo il punto" nel senso che non serve
individuare una qualche utilita' pratica per discutere di una qualsiasi
parte di codice che risolve un problema

L'astrazione di un problema e' un sistema perfettamente lecito di porre
una questione e chiedere aiuto per al soluzione del problema

Per costruire un algoritmo di bubble sort non e' necessario aver bisogno
di ordinare qualcosa, e' sufficiente descrivere il problema e sara'
possibile aggredirlo e risolverlo anche senza trarne poi una qualche
utilita' o aver l'applicazione adatta che lo impiega