In NoSQL basato su documento per creare tabelle (AFAIK) di cui ho bisogno:
Crea un numero così elevato di righe nei documenti della tabella con lo stesso campo ID (che sarà l'ID della tabella) e ogni volta è necessario impostare le colonne (per ogni documento).
Quindi per prima cosa cerchi i documenti per id (tabella) e poi cerca quello che ti serve nella selezione.
Correggi se ho capito male ... ed è sano? Come potrebbe essere veloce?
Forse. L'unico modo reale per dirlo è impostare alcuni casi di prova e misurare. Il mio sospetto sarebbe che il modo in cui si accede ai dati in termini di pattern e utilizzo è più importante.
Detto questo, pensare ai DB di documenti in termini di tabelle è generalmente controproducente. Pensa in termini di documenti.
Usa lo strumento giusto per fare la cosa giusta. I database dei documenti dovrebbero essere utilizzati per archiviare documenti, non tabelle. Se i documenti hanno le stesse colonne, un database relazionale è più appropriato per memorizzarlo o forse un database grafico.
Quello che descrivi (se ho capito bene quello che descrivi) potrebbe essere un incubo nella performance nell'aggiornare le suddette tabelle - se memorizzi ciascuna "tabella" come un singolo documento in un sistema NoSQL, e vuoi aggiornare una riga in quel "tabella", quindi è necessario aggiornare l'intero documento (potenzialmente enorme) ogni volta.
Ma se hai bisogno / vuoi una struttura rigorosa, allora perché dovresti usare i sistemi NoSQL? Per problemi di tipo SQL, i database SQL saranno più veloci e migliori. Per problemi di tipo valore-chiave, i sistemi di dati valore-chiave saranno più veloci e migliori. Per i problemi relativi al tipo di archiviazione dei documenti, i sistemi basati su documenti saranno più veloci e migliori.
Leggi altre domande sui tag nosql