If What we are developing is "just a prototype", Hence we could skip making the tables unrelational for the meantime?
My problem is our PM isn't even looking over what we are doing. The database solution we have to a QA type system we have the answers prebuilt already (you just hve to choose).
For now we have it like this
`` and more answers onward. (we don't know how many questions there will be.)
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.
My question is - it's not going to be a big system, but should we already optimize for that early on? Then based on your experience how hard could it be given we are using a simple framework.
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.
This is what I hate about development. LOL . development AND working with people who don't seem to know what they're really doing.
This question is marked "community wiki".
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.
answered Jan 31 '12 at 04:28
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?"
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.
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.
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.
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?
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
answered Dec 08 '11 at 09:53