I am planning to build a live audience interaction webapp similar to Slido as practice/fun project.

User groups: admins and anonymous users


  • login

  • create event (define event period and unique event code/name)

  • edit/delete user questions

  • highlight user questions (up to 3 questions per event)

Anonymous users:

  • join event by keying in event code/name

  • join event if event period matches current time

  • ask questions in the event page

  • see live updates of questions asked by other users

  • sort questions asked by time/most upvote

  • can upvote/downvote other questions

For such an application, will NoSQL or SQL db be a better choice?

Thanks in advance for your advices.


Below are the data models for relational and non-relational scheme that i came up with. would love to have feedback on it:

Relational scheme:


  • id (serial primary key)

  • login

  • password

  • name


  • id (serial primary key)

  • event_name

  • event_code

  • start_time

  • end_time

  • admin_id (foreign key reference admin.id)


  • id (serial primary key)

  • name

  • email


  • id (serial primary key)

  • event_id (foreign key reference events.id)

  • post_time

  • user_id (foreign key reference users.id)

  • content


  • id (serial primary key)

  • question_id (foreign key reference questions.id)

  • user_id (foreign key reference users.id)

Question_highlight (used by admins)

  • id (serial primary key)

  • question_id (foreign key reference questions.id)

Non-relational scheme:

Admins document

 events: [event1, event2 ...]

Events document

users: [user1, user2, ...]
highlightedQuestions: [question1, question2, ...]

Questions document

userLikes: [user1, user2, ...]

Users document

  • 1
    There's nothing in these requirements that would require or rule out a relational data model. However, your data will probably fit very easily into a relational schema. Going NoSQL will not bring any advantages here. So just use whatever you are familiar with.
    – amon
    Commented Jun 9, 2018 at 11:52

2 Answers 2


There are plenty of questions to consider when choosing the DBMS technology at the beginning of a project. Here are the first two that come to my mind:

  • How easy can the data be modelled ?
  • How will the data be accessed in the future ?

Unfortunately, the information you provide here is insufficient to advise you. Here nevertheless some thoughts that could help you.

1. How easy can the data be modelled ?

From your use cases, I imagine the following entities in your model: Users, Events, Questions (for an event), Votes (for a question), and perhaps Answers (although this is not explicit: nobody answers questions in your use case list).

This is very easy to model in a relational scheme, since the data seems rather structured, with well established relationships.

But it could as well be very easily modelled in a No-SQL document database such as MongoDB: User would for instance be one kind of document, and Events an independent kind of documents. Questions would then be a list of sub-documents embedded in Events.

Hint 1: Before choosing the DBMS technology, make a model of your domain. This will help you to understand the data structures that you'll need and identify the implementation alternatives

2. How will the data be accessed ?

In the relational model, it's easy to browse through the relations. Pick any entity and follow the relations until you have what you need. For example, pick a user, find related questions, find related events; or start from an event, find the related questions and users. Total navigation flexibility.

In the document database, you need to analyse further the main path of access, and trade-offs between update cost and retrieval performance, and make design choices. With MongoDB for example, you would typically wonder if you'd better use a more convenient embedded model or a more performant normalized model.

Hint 2: On your model identify how you'll need to access the data in the different use-cases you've identified. Then imagine how you'll do it in the relational and in the document-based approach.

Hint 3: Now imagine that several user want to ask or update questions. What update conflicts could arise due to concurrency ? How could you cope with it in the different DBMS schemes that you consider ?

Final thoughts

As a rule of thumb, the relational model is very flexible as long as the data is rather structured and in a stable fashion. Personnally, I'd opt for this approach as first choice in your case, but I have no valid argument to justify it.

The "no-sql" engines (in fact the non-relational DBMS, because SQL is just the query langage) are a better choice if the data is less structured, if the structure evolves very often, or in case of specialized data structures.

In this regard, be aware that there are different kind of No-SQL, even if document stores like MongoDB seem to be the more commonly used. There are also graph databases, tuple-stores, column stores, etc... As you see, each kind correspond to some specific needs regarding the data or the way to access it. Would you recognize any such need for your domain ? Answering this question should give you the response you're looking for.

  • Thank you so much for your reply, its extremely helpful. i personally am more comfortable with RDMS (postgresql) so i tend to view the data in a relational scheme from the beginning. Another reason why i am asking this is because i noticed most chat app (functions somewhat similar to this app i am building) tutorials uses non-relational DBMS (mongoDB) instead of RDMS. Is there any reason why this is so?
    – jaanhio
    Commented Jun 9, 2018 at 18:20
  • A chat is a sequential list of messages exchanged by a group of users. With a document db, the chat document can embbed individual messages in a list. You could delete the full chat very easily. If you add a message, it will be in the correct order. Finally, most of the accesses use the sequential browsing through the list. Doing same with relational db requires keeping track of the chat, & a sequence number within the chat. So removing a chat or adding new messages requires to browse through all related messages. It's feasible as well but requires more application logic.
    – Christophe
    Commented Jun 9, 2018 at 23:00

Since this is for practice (and could be of potential use in a job interview), you might consider implementing a non relational and a Relational version. This way when someone asks .

Based on your on your outline A relational model would fit better as you data is small and is very structured. If you work on the data model, you could probably fit most if not all of the database into memory which would make it very fast.

This is also a great little project to play with a nonSQL version. I’ve heard of several project using NoSQL as it doesn’t require learning any SQL is data modeling.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.