Dovrei usare il database NoSQL (MongoDB) o SQL (postgresql) per la mia applicazione?

Naviga le tue risposte
1

Sto pianificando di creare una webapp per l'interazione con il pubblico dal vivo simile a Slido come progetto di pratica / divertimento.

Gruppi di utenti : amministratori e utenti anonimi

Amministratori :

  • login

  • creare un evento (definire il periodo dell'evento e il codice / nome dell'evento univoco)

  • modifica / elimina le domande degli utenti

  • evidenzia le domande degli utenti (fino a 3 domande per evento)

Utenti anonimi :

  • partecipare all'evento digitando il codice / nome dell'evento

  • unisciti all'evento se il periodo dell'evento corrisponde all'ora corrente

  • fai domande nella pagina dell'evento

  • vedi gli aggiornamenti in tempo reale delle domande poste da altri utenti

  • ordina le domande poste per ora / più upvote

  • può upvotare / downvotare altre domande

Per tale applicazione, NoSQL o SQL db saranno una scelta migliore?

Grazie in anticipo per i tuoi consigli.

Aggiornamenti!

Di seguito sono riportati i modelli di dati per lo schema relazionale e non relazionale che ho elaborato. piacerebbe avere un feedback su di esso:

Schema relazionale:

Gli amministratori

  • id (chiave primaria seriale)

  • login

  • Password

  • nome

Eventi

  • id (chiave primaria seriale)

  • event_name

  • EVENT_CODE

  • start_time

  • end_time

  • admin_id (riferimento a chiave esterna admin.id)

Utenti

  • id (chiave primaria seriale)

  • nome

  • e-mail

Domande

  • id (chiave primaria seriale)

  • event_id (foreign key reference events.id)

  • post_time

  • user_id (foreign key reference users.id)

  • contenuto

Question_upvote

  • id (chiave primaria seriale)

  • question_id (foreign reference reference questions.id)

  • user_id (foreign key reference users.id)

Question_highlight (utilizzato dagli amministratori)

  • id (chiave primaria seriale)

  • question_id (foreign reference reference questions.id)

Schema non relazionale:

Documento degli amministratori 

{
 uid: 
 login:
 password: 
 name:
 events: [event1, event2 ...]
}

Documento di eventi 

{
 uid:
eventName:
eventCode:
startTime:
endTime:
adminId:
users: [user1, user2, ...]
highlightedQuestions: [question1, question2, ...]
}

Documento delle domande 

{
uid:
eventId:
userId:
content:
userLikes: [user1, user2, ...]
postTime:
}

Documento utenti 

{
uid:
name:
email:
}
    
posta Jian Hao Tan 09.06.2018 - 12:15
fonte

2 risposte

2

Ci sono molte domande da considerare quando si sceglie la tecnologia DBMS all'inizio di un progetto. Ecco i primi due che mi vengono in mente:

  • Quanto è facile modellare i dati?
  • Come saranno accessibili i dati in futuro?

Sfortunatamente, le informazioni fornite qui non sono sufficienti per consigliarti. Qui tuttavia alcuni pensieri che potrebbero aiutarti.

1. Quanto è facile modellare i dati?

Dai tuoi casi d'uso, immagino le seguenti entità nel tuo modello: Users , Events , Questions (per un evento), Votes (per una domanda), e forse Answers (sebbene questo non è esplicito: nessuno risponde alle domande nella tua lista dei casi d'uso).

Questo è molto facile da modellare in uno schema relazionale, poiché i dati sembrano piuttosto strutturati, con relazioni consolidate.

Ma potrebbe anche essere facilmente modellato in un database di documenti No-SQL come MongoDB: User sarebbe ad esempio un tipo di documento e Events un tipo di documenti indipendente. Questions sarebbe quindi un elenco di sotto-documenti incorporati in Events .

Suggerimento 1: prima di scegliere la tecnologia DBMS, crea un modello del tuo dominio. Ciò ti aiuterà a comprendere le strutture dati di cui avrai bisogno e a identificare le alternative di implementazione

2. Come accedere ai dati?

Nel modello relazionale, è facile sfogliare le relazioni. Scegli qualsiasi entità e segui le relazioni finché non hai ciò di cui hai bisogno. Ad esempio, scegli un utente, trova domande correlate, trova gli eventi correlati; o iniziare da un evento, trovare le domande e gli utenti correlati. Totale flessibilità di navigazione

Nel database dei documenti, è necessario analizzare ulteriormente il percorso principale di accesso e i compromessi tra i costi di aggiornamento e le prestazioni di recupero e fare scelte progettuali. Ad esempio, con MongoDB dovresti tipicamente chiedervi se è meglio usare un modello embedded più conveniente o un modello normalizzato più performante .

Suggerimento 2: sul tuo modello identifica in che modo avrai bisogno di accedere ai dati nei diversi casi d'uso che hai identificato. Quindi immagina come lo farai nell'approccio relazionale e nell'approccio basato sul documento.

Suggerimento 3: Ora immagina che diversi utenti vogliano chiedere o aggiornare domande. Quali conflitti di aggiornamento potrebbero sorgere a causa della concorrenza? Come puoi farcela con i diversi schemi di DBMS che consideri?

Considerazioni finali

Come regola generale, il modello relazionale è molto flessibile purché i dati siano piuttosto strutturati e stabili. Personnamente, opterei per questo approccio come prima scelta nel tuo caso, ma non ho argomenti validi per giustificarlo.

I motori "no-sql" (infatti il DBMS non relazionale, perché SQL è solo il langage della query) sono una scelta migliore se i dati sono meno strutturati, se la struttura si evolve molto spesso, o in caso di specializzazione strutture di dati.

A questo proposito, tieni presente che esistono diversi tipi di No-SQL , anche se i negozi di documenti come MongoDB sembrano essere i più usato comunemente. Ci sono anche database di grafici, tuple-store, negozi di colonne, ecc ... Come vedi, ogni tipo corrisponde ad alcune esigenze specifiche riguardanti i dati o il modo per accedervi. Riconosceresti una tale necessità per il tuo dominio? Rispondere a questa domanda dovrebbe darti la risposta che stai cercando.

    
risposta data 09.06.2018 - 16:07
fonte
-2

Poiché questo è per la pratica (e potrebbe essere di potenziale utilizzo in un colloquio di lavoro), potresti prendere in considerazione l'implementazione di una versione non relazionale e relazionale. In questo modo quando qualcuno chiede.

Basandoti sul tuo profilo Un modello relazionale si adatterebbe meglio dato che i dati sono piccoli e molto strutturati. Se lavori sul modello di dati, potresti probabilmente montare la maggior parte se non tutto il database in memoria che lo renderebbe molto veloce.

Questo è anche un piccolo grande progetto per giocare con una versione non SQL. Ho sentito parlare di diversi progetti che utilizzano NoSQL in quanto non richiede l'apprendimento di SQL per la modellazione dei dati.

    
risposta data 09.06.2018 - 14:35
fonte

Leggi altre domande sui tag

Come rafforzare la separazione dei moduli? Gestisci diverse procedure