Altri Linguaggi - Consiglio per corretta progettazione database di un sito per storage file

Ciao ragazzi,

spero che possiate darmi una dritta per risolvere un dubbio di progettazione.

Vi spiego meglio, sto facendo un sito per lo storage di file online e vorrei capire come muovermi per progettare un sistema per memorizzare i file di un utente. Sono partito con l'idea di progettare un database che permetta al singolo utente di accedere ai propri file. In breve, ho un database che contiene una tabella GENERALE che memorizzi tutti le info degli utenti registrati come mail, password ecc.. in più avrei l'intenzione di creare, al momento della registrazione di un utente, una tabella personale e dedicata dove egli possa salvare i propri file. Quindi il DB, tolta la tabella generale, avrebbe N tabelle che corrispondono al numero di utenti registrati. Il mio dubbio è il seguente: questo "sistema" creerebbe dei problemi, (nel caso in cui avessi un elevato numero di utenti iscritti e di conseguenza un elevato numero di tabelle personalizzate per ogni utente da gestire) oppure è qualcosa di fattibile?

Nel caso in cui questa fosse una cattiva soluzione, quali consigli potreste darmi?

Grazie dell'attenzione

Se ho capito bene, vorresti creare un database per gestire dei dati.
Nell'ambito della programmazione web, esistono dei linguaggi di programmazione lato server..
Attraverso questo linguaggi di programmazione, ad ogni evento fornito da un client vengono generati delle query in modo da prelevare delle informazioni dal database..

A riguardo, ti consiglio leggerti qualcosa su wikipedia it.wikipedia.org/wiki/…

La stai prendendo larga, il suo è un problema di progettazione, non di implementazione

Comunque, Mattia993, non penso sia una buona idea creare tabelle per ogni utente, non è questa la logica con cui funzionano i database (relazionali), per cui la cosa rischia di diventare pachidermica a ogni livello
Io farei una sola tabella files che contiene nome (eventuale) del file e una chiave esterna per l'utente a cui appartiene, più altri campi che eventualmente ti servono

Ti consiglio di studiare le forme normali dei database relazionali:

Giusto come introduzione su cosa di parla: it.wikipedia.org/wiki/…

poi ti conviene cercare ulteriore documentazione

Quelli che dici tu e quello che dice qwertj non sono necessariamente due cose opposte.
E' possibile avere un'unica tabella che riguarda i file, frammentata (orizzontalmente o verticalmente) su più tabelle diverse. La tabella generale sarebbe di fatto virtuale mentre a livello concreto esistono solo le sottotabelle che ne costituiscono i frammenti. Ciascun frammento può essere poi allocato su macchine diverse.
La frammentazione è una tecnica usata nei sistemi di database distribuiti e molti dbms commerciali la supportano, ma non so dirti di preciso quali e come.

Innanzitutto grazie delle risposte,

sono convinto che Qwertj abbia ragione a proposito del mio problema di progettazione, avere una quantità di tabelle nell'ordine del migliaio in un database è possibile, ma evidentemente nel mio caso non è consigliato.. Proverò comunque a cercare ulteriore documentazione per capire quale soluzione è quella che più si adatta alle mie esigenze.

Quoto, anche se credo non lavori (ancora) su un cluster di database XD

ciao forse mischiare più soluzioni può evitare bug e problemi in futuro
1 obbiettivo lasciare snello il db in termini di velocità visto che utenti agiscono dal web registrando solo stringhe di collegamento ai file
2 creare direttorio per ogni utente dove fisicamente confluiscono i file
3 soluzione relazionale delle tabelle come suggerito già da Qwertj
4 creare tabelle storico caricamento file per evitare di perdere i dati e le associazioni relative a tutto
quindi consultare queste in visualizzazione mentre lasciare l'altra per i caricamenti verificando il buon
esito quindi spostarli su tabella backup
5 ci vorrebbero altri dettagli per capire l'obiettivo e la finalità da raggiungere