OsvaldoLaviosa ha scritto:
Non so se sia più appropriato postare questo argomento al Bar dei programmatori piuttosto che qui: se ci sono problemi posso cancellarlo.
Non ho un problema da risolvere, ma mi piacerebbe soltanto aprire una discussione serena, magari il più possibile da vari utenti e punti di vista.
Mi è capitato una volta di guardare un database completo di tutto il Policlinico del mio paese messo in piedi da un dipendente programmatore. Il database era vastissimo ed efficentissimo e assolveva davvero a tutti compiti, dai Dipendenti ai Pazienti, Referti, Parte commerciale, ecc...di tutto e di più. Guardando dentro il database era ovviamente pieno di tabelle, altrettante maschere, ma non una query, soprattutto neanche una relazione. Tutto, ma proprio tutto era regolato solo ed esclusivamente da listoni di codice Visual Basic. Confesso che la cosa mi ha scioccato moltissimo.
Confesso che prima di espormi con un giudizio su un lavoro che non ho visto ... ci penso su 3 volte...
mi permetto di rispondere tuttavia alle domande che poni in quanto sono concettuali e queste non hanno patria...!
OsvaldoLaviosa ha scritto:
Vorrei sapere:
1. Le relazioni in Access sono soltanto un utile interfaccia per l'utente?
Le relazioni non sono uno strumento di ACCESS, ma il metodo STANDARD con cui si strutturano i DATABASE in genere... e direi che non sono affatto un'interfaccia utente, anzi per l'utente il tutto non esiste.
Ci sono tuttavia visioni alternative di COME si intendono le relazioni.
La relazione tra 2 Tabelle può esistere a prescindere dal DISEGNO in QBE, le righette con le frecce per capirci...!
OsvaldoLaviosa ha scritto:
2. Questo signor programmatore, non conosce l'anima di Access, ma benissimo VBA tale da poterlo applicare ovunque indiscriminatamente?
Le 2 cose non si escludono a vicenda... ci sarebbe non solo da fare un'analisi approfondita, ma anche da parlare con lo sviluppatore... di base chi lavora con i DB deve prima di tutto conoscere come si STRUTTURA in DB secondo le 5 regole di NORMALIZZAZIONE, poi e solo poi il CODICE si usa per gestire verso l'utente il dato...!
Chi predilige il CODICE verso il lavoro SERVER_SIDE probabilmente attua concetti alternativi ma da ascoltare, anche perchè JET come DB non offre gli stessi vantaggi che un vero RDBMS può offrire... quindi ci sono delle varianti importanti al tema.
OsvaldoLaviosa ha scritto:
3. Agli esperti di VBA: ma ne è valsa la pena aver prodotto tutto ciò ignorando le basi di un programma?
Intendi le basi di strutturazione di un DB relazionale...?
Fai attenzione che le relazioni si possono gestire anche senza il DISEGNINO nel QBE... SQL SERVER ad esempio rende disponibili i TRIGGER che consentono di intercettare le variazioni e poter mettere in atto azioni condizionate... questo significa gestire INDICIZZAZIONI con CODICE(se usi ACCESS che non ha TRIGGER) oppure con StoredProcedure lanciate da TRIGGER su RDBMS....
OsvaldoLaviosa ha scritto:
Immagino che il signor programmatore avrà lavorato 4 volte in più per mettere in piedi tutto quel mostro di database: vero?
Probabilmente immagini MALE, i programmatori, con la P maiuscola, hanno strutture funzionali precostituite che RICICLANO, e più sono bravi più riciclano... anche a scapito del PERFEZIONISMO STRUTTURALE.
Ribadisco che è difficile fare il programmatore, ma ancora di più riuscire a comprendere il lavoro di altri in quanto affetto da MOLTE VARIABILI che possono sfuggire(anche se il caso che esponi potrebbe realmente essere in linea con le tue idee...)