Databse design question

Personally I would probably separate the answers from the questions, so as to easily adjust later when you need to enhance the system or it becomes bigger. :) In this design there's no difficulty in getting the answers anyway as it would be a simple join :D

If What we are developing is "just a prototype", Hence we could skip making the tables unrelational for the meantime?

Sometimes. Sometimes making "just a prototype" or proof of concept involves writing what's essentially "throw-away" code.

On the other hand, sometimes a prototype is written to verify/validate certain assumptions—including technical assumptions such as, "Can this proposed data model or schema handle our application's domain model and persistence requirements?"

My problem is our PM isn't even looking over what we are doing.

Contrary to what you think, the PM is not supposed to be looking over what you're doing. That's not the PM's job. The PM's job is to ensure that the entire project is running smoothly, on time, under budget, with the given resources. At any point in time, when the project is at risk or resources/deliverables are blocked, then it's the PM's job to remove those blockages, and/or, if necessary, adjust the project's timelines and shareholder expectations.

The job of looking over your shoulder should be the technical lead or architect's job. Performing design and code reviews, identifying possible performance, security, or general engineering problems and recommending solutions—that's all technical and not something the PM should be expected to do.

Now, on to your technical question.

It's basically a table of question with out a corresponding relationally linked answer table, the answer is already there in the same table of the question.

If every question will have exactly the same number of corresponding answers (say, 4), then a single table with the question and all its answers in one row will suffice. It's still in normal form.

If a question can have only 3 possible answers, or more than 4 (thus requiring 5 answer columns) then the table ceases to be in normal form and so, yes, I would refactor it into two tables with a one-to-many relationship.

It's not about projected system/database size. It's not about (premature) optimization.

It's about keeping a simple, logical and coherent database design that will make it easier and more efficient to use and maintain as the project progresses and the application grows.

Whether you use raw SQL queries, or whether you use an ORM layer like ActiveRecord or JPA/Hibernate—an improperly designed schema will cause problems for you later on.

Right now I'm thinking Maybe i'll just develop two versions, one for the optimized tbl_question and tbl_answer for the future, and the other for the ineffecient tbl_question.

Then you've just done twice the work for no appreciable gain. If I were your PM, now I'd be concerned because then it ceases to be a technical matter and turns into a resource allocation matter.

This is what I hate about development. LOL .

First off—this is what software development is all about (exploring and evaluating different approaches to problems) and if you hate that part, then I'm afraid you might want to reconsider your choice of vocation.

Perhaps you'd consider taking a job in project management?

My problem is our PM isn't even looking over what we are doing.

Understand that not all PM's have technical background and in such situations a technical lead must be part of your team to oversight the technical aspects of the project.

It is your PM's role to find that technical resource in the case that current developer/s can't resolve such issues. Hence, I suggest you inform your PM about the need.

On the other hand, your PM might be depending on you to make that technical leadership. This is your time to "shine" so step up and make that initiative to put things in order now.