Accesso a SQL dalla rete

[_mike_]

Ciao a tutti,
vorrei chiedervi un parere su come risolvere un problema di connessione a un database SQL presente su una rete internet, da un sito web presente in una rete diversa. Mi spiego:
Ho a mia disposizione un Web server con un mio sito web.
Questo sito web dovrà essere composto da 2 parti:
- una parte globale ( a cui potranno accedere tutti )
- una parte riservata ( in cui ogni utente registrato avrà il suo profilo personale)
Un cliente accederà al sito web visualizzando la "parte globale" dove saranno presenti dei report (visualizzazioni) che potranno essere acquistati.
Questi report, una volta acquistati, saranno disponibili per il cliente nella sua "parte riservata".
Fin qui tutto chiaro. Il problema nasce perchè il report fa riferimento a dei dati presenti in un DB di Sql Server.
Questo DB non è presente sul mio Web Server e nella mia rete ma in quella del cliente che si è collegato alla pagina Web.
Di conseguenza io dovrei collegarmi da questa pagina web presente sul mio web server al DB Sql presente sulla rete/macchina locale del cliente avendo a disposizione il nome dell'istanza, l'username, la password e il nome del DB con le relative tabelle.
Naturalmente il cliente si collegherà sempre e solo dalla propria rete in modo che avrà sempre a disposizione il collegamento diretto al proprio DB.
La mi domanda è: come faccio, tramite sito web, a collegarmi su un db di una macchina esterna alla mia rete nelle condizioni che vi ho descritto?
Fatemi pure esempi in qualsiasi linguaggio di programmazione o ditemi se c'è qualche tool o qualcosa del genere.
Grazie anticipatamente!

 

[vbs]

A mio parere quello che hai descritto ti crea non pochi problemi coi "client" in quanto se devi leggere il db dell'utente dalla macchina dell'utente devi confrontarti anche con delle impostazioni sui loro router per l'apertura di porte dedicate...diventa un pasticcio controproducente...

Io ho fatto un sistema simile ma in un certo senso capovolto...ovvero è il cliente che manda delle istruzioni al server "centrale" tramite un applicativo che sta in mezzo, sulla macchina del client. In pratica ho un piccolo sw che legge le modifiche nel database locale ogni "tot minuti" e poi manda in blocco le query di aggiornamento al db remoto...in pratica fa una sincronizzazione completa in entrambi i lati. E' più facile così in quanto l'ip dell'utente è molto più ballerino rispetto a quello del server (nonostante i dyndns, forward e impostazioni varie).

Cosa risolvi con questo metodo? Riduci i grattacapi lato utente (e credimi, alcuni sono davvero utonti) e di conseguenza anche tuoi, ma dall'altro lato della medaglia ti si allungano un pochettino i tempi di sviluppo in quanto realizzare una sincronizzazione di due database con dati che più utenti possono sovrascrivere diventa una menata...mi riferisco al caso in cui 2 o più utenti aggiornano lo stesso campo nel db centrale (anche se questi incidenti non devono mai esistere).

L'approccio che ti ho descritto l'ho usato per fare un sistema completamente automatico per un'attività di distribuzione merci nel quale ci sono gli agenti sul territorio che inseriscono gli ordini dei clienti assegnati ad ognuno (chi usa una chiavetta umts, chi il wi-fi del suo cliente, ecc ecc...) in un database centrale dal quale vengono "scaricati" nel server interno alla ditta per la contabilità e viceversa per gli ordini evasi o parziali...

 

[_mike_]

A mio parere quello che hai descritto ti crea non pochi problemi coi "client" in quanto se devi leggere il db dell'utente dalla macchina dell'utente devi confrontarti anche con delle impostazioni sui loro router per l'apertura di porte dedicate...diventa un pasticcio controproducente...

Io ho fatto un sistema simile ma in un certo senso capovolto...ovvero è il cliente che manda delle istruzioni al server "centrale" tramite un applicativo che sta in mezzo, sulla macchina del client. In pratica ho un piccolo sw che legge le modifiche nel database locale ogni "tot minuti" e poi manda in blocco le query di aggiornamento al db remoto...in pratica fa una sincronizzazione completa in entrambi i lati. E' più facile così in quanto l'ip dell'utente è molto più ballerino rispetto a quello del server (nonostante i dyndns, forward e impostazioni varie).

Cosa risolvi con questo metodo? Riduci i grattacapi lato utente (e credimi, alcuni sono davvero utonti) e di conseguenza anche tuoi, ma dall'altro lato della medaglia ti si allungano un pochettino i tempi di sviluppo in quanto realizzare una sincronizzazione di due database con dati che più utenti possono sovrascrivere diventa una menata...mi riferisco al caso in cui 2 o più utenti aggiornano lo stesso campo nel db centrale (anche se questi incidenti non devono mai esistere).

L'approccio che ti ho descritto l'ho usato per fare un sistema completamente automatico per un'attività di distribuzione merci nel quale ci sono gli agenti sul territorio che inseriscono gli ordini dei clienti assegnati ad ognuno (chi usa una chiavetta umts, chi il wi-fi del suo cliente, ecc ecc...) in un database centrale dal quale vengono "scaricati" nel server interno alla ditta per la contabilità e viceversa per gli ordini evasi o parziali...

Intanto grazie della risposta molto articolata.
Comunque si in effetti forse il metodo che hai utilizzato tu è meglio. Però c'è un problema: io dovrei creare un sito web dove ognuno può accedere e su questo ogni cliente avrà uno spazio web dedicato per i report che scarica. Quindi se dovessi fare come mi hai descritto non si tratterebbe più di un sito web ma di un app presente nella loro rete che potranno vedere solo loro. Non so se mi sono spiegato.

Grazie mille.

 

[vbs]

Allora ho capito male...
Se devi fare un sito web nel quale ognuno ha la sua area riservata nella quale può aggiornare delle info e scaricare i suoi report allora non ti serve nulla di ciò che avevo scritto... io avevo capito che dovevi risolvere una situazione simile a quella di una ditta che fa vendita tramite agenti sparpagliati sul territorio ed i dati vengono accumulati in un unico punto (che sia un sito web o un server interno ad una ditta)...

In questo caso ti serve solo il sito web col suo db, ma niente db sul lato utente...mi spiego: il db del sito avrà le sue tabelle nelle quali avrai gli id degli utenti (ovviamente collegati con un sistema di login), i permessi utente nonché i loro dati che possono aggiornare da soli ed i report che possono scaricare da soli (esempio: id utente 12 ha i report id 18, 32 e 44, mentre id utente 13 ha i report 19, 35, 45 e 61)...ma tutto avviene solo lato web.

Spero di non aver capito male anche stavolta ;)

 

[_mike_]

Allora ho capito male...
Se devi fare un sito web nel quale ognuno ha la sua area riservata nella quale può aggiornare delle info e scaricare i suoi report allora non ti serve nulla di ciò che avevo scritto... io avevo capito che dovevi risolvere una situazione simile a quella di una ditta che fa vendita tramite agenti sparpagliati sul territorio ed i dati vengono accumulati in un unico punto (che sia un sito web o un server interno ad una ditta)...

In questo caso ti serve solo il sito web col suo db, ma niente db sul lato utente...mi spiego: il db del sito avrà le sue tabelle nelle quali avrai gli id degli utenti (ovviamente collegati con un sistema di login), i permessi utente nonché i loro dati che possono aggiornare da soli ed i report che possono scaricare da soli (esempio: id utente 12 ha i report id 18, 32 e 44, mentre id utente 13 ha i report 19, 35, 45 e 61)...ma tutto avviene solo lato web.

Spero di non aver capito male anche stavolta ;)

No stavolta ci sei :asd: grazie mille del consiglio e spero di riuscire a fare così a questo punto... grazie mille ancora e al massimo ci risentiamo :)