I'm referencing a closed stack overflow post,
Database design for a survey
The top answer in the post gives a great overview of the tables to use for a survey database, with a good table-relationship view. My question piggybacks on the survey tables, particularly the table which stores the top level survey records. For surveys which are given in specified periods (initial survey, 6 month after, 12 month after, etc.), if the survey does not have different questions and answers (just a duplicate of the initial survey), would it make more sense to create different surveys in the top level survey table as different survey records, or would it be better to add a field in the completed survey table as a secondary identifier.
For example, if a survey (let's call it "Health assessment") has an initial survey, then one 6 month after, which would be the better solution:
make two records in the survey table - "Health assessment - initial" and "Health assessment - 6 month", so that in the completed survey table the surveyID would be different for both surveys. This would, I suppose, require records for both surveys in other tables (survey_question and survey_question_answer). Seems like a lot of duplication.
make one record in the survey table - "Health assessment", and add an additional designation in the completed survey table (answer) where the user could put "Initial" or "6-month".
Hopefully that makes sense. I think either solution might work; I just want the more optimal solution.
Keeping to this existing design; Assuming SurveyID is a unique Primary Key, the first suggestion, as you already recognized, will cause redundant data unless the intention is for the questions to change over time. The second option is not great either because I believe it would invalidate the purpose of the StartDate, EndDate, and IsOpened fields on the Survey table.
What about creating a Survey_Instance table? The Survey table would hold the Survey ID and description and the new table would hold the Start, End, and IsOpened properties for each time the survey posted. The responses could be linked via "SurveyInstanceID" and the questions could be linked to the Survey table. This has the added benefit of linking responses to a specific time frame so you could observe how the responses might change over time.
Related
I have a table [Team] in my Database. Many other tables require a many to many relationship with this table. This is mostly due to various records in my other table having authorisation settings based on which team the current user is in.
For example a record in my [User] table can be linked to many teams and a team can be linked to many [Ticket] records. If the teams overlap that user now has permission to view the [Ticket].
I am considering two options, firstly have a seperate table for each [UserTeam] and [TicketTeam] e.g ticket team will have the following columns Id,TicketId,TeamId.
My second option is to store the data for both in the same table. To do this I would create a [AuthorisationRecord] table with one Id column and a [AuthorisationRecordTeam] table with Id,AuthorisationId,TeamId. I would also then need an extra column on my [Ticket] and [User] tables AuthorisationRecordId. This has the downside of needing an extra column and every time we create a record we also have to create an [AuthorisationRecord] record.
If it was just these two tables I think it would make sense to have a seperate many to many table for each. However as there are many tables needing this same relationship with the [Team] table and the potential for many more in the future I am leaning toward my second option, as this will simplfy the devlopment process as every time we add a new feature that needs authorisation based on the Team we will not have to add another many to many table but simply add one extra column with a relationship to my [AuthorisationRecord] table.
My question is weather this is a good scaleable idea? It seems like it will greatly simplfy my database as instead of potentialy hundreds of many to many tables with my [Team] table there will be just one. However I can't find resources online about this potential method so I think it might be a bad idea.
I am fairly new to SQL queries. I want to display the same product that has been serviced at three different labs or service stations.
I want to list and display the macbook represented by the id at the three different stations (or more) being displayed too.
Ok, so normally on stackoverflow, people tend to show what they tried and why it didn't work. In fact this question will probably be closed as too broad, but I empathize with starting with sql. But I will match the broadness of your question with a broad answer.
You should splt the tables up. I might try to have three tables:
A table describing each product with unique id
A table describing each service location with a unique id
A table describing each transaction with a unique id consisting of product ID and location id
Then when you need the data you would perform a join which would return the table containing the information you want.
I have an app where users can log comments related to any specific entity that the system has and I wanted to know if there is a "best practice" way to handle the design of the db for this kind of feature.
For example: Three current entities (tables) deal are Question, Documentation, ReferenceMaterial (self explanatory what each hold). The user can leave a comment on any one of those particular items and all comments are simply a varchar field, user id, and date of comment. EDIT: Comments can also belong to more than one entity. For example, all Question entities belong to a Quiz or Test entity. Each of those (Quiz and Test), can also have comments associated with themselves. So you could run a report to see all comments left for a test and easily just query the Comment table for every record with that test foreign key, or you could limit your query to just the comments left for questions in that test, or a particular question itself. It offered a lot of flexibility END EDIT
Right now the way that I hvae this is one Comment table with a foreign key relationship with each of the other entity tables (i.e. fkQuestion, fkDocumentation, fkReferenceMaterial, etc). So all comments in the system are stored in this table and based on what page the user is on, I conduct the join to that particular entity's records.
Is there a best practice way of doing this?
Thanks in advance for any help.
I am working on a VB.net (VS-2010, Win XP Pro 2 SP3), Employee Management Project. I need to keep track of Employee Leave Attendance and also each Equipment assigned to an Employee. How can I achieve this using SQLlite.
It will be very useful if you could provide me with examples as I am completely new to the field of SQL and VB.net
I think this can be done with two tables where one has the primary key while the other has a foreign key, but I am not sure. Also how many tables will I need for storing data in Leave and Equipment Form.
I went through other questions but I was unable to figure out a solution for my problem.
(Sorry, I cannot provide with images as this site prevents me from posting images without 10 reps)
Most problems are only as complex, and as simple as you make them. Out of habbit, nearly all tables end up with a unique ID field. There are exceptions, which I will call "link" tables, eg, ones that provide connection details between two data tables.
Now, in your senario
You would need a "holiday" table, where each row will contain the employee unique ID and either a start/finish date, eg, if they take half a day, it needs to be visible, or, just a year and value, eg in 2011, I booked, 2 lots of 35 hours, and 1 lot of 4 hours eg, Ive taken 2 weeks and half a day.
For the equipment, you would need a data table, since an item can only got to 1 employee, it depends if you're going to use this for booking or not, but if its just like a library, eg I currently have a loaner laptop, then you can just have an employee field in the equipment table. If you need a booking system, then you would require link tables and more complex.
Best way to work out your tables is to try and group your data, and then write the items on peices of paper and see how you as a human do it. After a while you end up able to do so in your head.
I'm a total newbie when it comes to SQL. I'm making a site in ASP.NET for doing surveys. A privileged admin user will be able to build a survey. Then lots of other people will respond to the survey.
Once I have the set of questions for a new survey, what is the best way to automatically construct a table and an INSERT query to store the responses?
UPDATE
Thanks for the quick responses! I'm still a little unclear on how survey responses would best be stored in this scenario. Would each respondent get a row of the table? And if so, would the columns be "answer given for question k of the survey identified by the entry in column 1"?
You dont want to build a new table for each survey.
Create a surveys table (SurveyID, UserID, Name, etc)
Create a Questions Table (QuestionID, SurveyID, QuestionText, SortOrder, etc)
optionally, Create an Options table, assuming you have multiple choice type questions (OptionID, QuestionID, OptionText, etc)
Then when someone creates a survey, you insert into the Surveys Table, referencing that person's UserID as the foriegn key, then get the newly inserted SurveyID,
Then for each question they add, insert it into the Questions table, using the above SurveyID as the foriegn key.. and so on.
EDIT to answer your edit:
Sorry I should have followed through to cover storing answers as well.
You would want another table called SurveyResponses (ResponseID, Name, etc)
And another table I'll call ResponseAnswers(ResponseAnswerID, SurveyID, ResponseID, QuestionID, AnswerText/AnswerID) Where SurveyID and ResponseID are foriegn keys to thier respective tables, and depending on wether users have multiple choice, or enter an answer, you would either store thier answer as text(varchar) or as another foriegn key to the options table.
You probably don't want to be programatically generating the schema.
Instead, have a table for surveys, for questions (which belong to surveys), for response sets (one per user), and question responses (which belong to the response sets).
I'd think of a couple of options:
Create a one-to-many Survey table and Question table, where each Question has a column DataType that has a code of the response data-type we're expecting, and optionally some other columns / related table of available options, a column that specifies if this question is multi/single choice, mandatory/optional question etc. The Answer table's Answer is serialized/desieralized/indexed/formatted etc. according to the question data-type
Consider using NoSql database to store the survey data in a similar manner
You wouldn't automatically construct the table. The table would be predefined, and the answers would be added to them. I think the best way to get started with ASP.NET these days is to dive into MVC & Linq (http://asp.net/learn)