Approach to design database tables - mysql

I am new here as well as new in coding. I always get confused when it comes to database designing. Let me try to explain this.
If I need to create a functionality like this (Stackoverflow) website, More specific If I just want simple Question (posting, upvote, downvote) and Answer(posting, upvote, downvote) feature in my website I could follow two approaches.
First
create a table question in which I will save question.
create a table votes in which I will save votes(up and down).
To fetch a question will need to join these two table and get the question and there votes(up and down)
Second
Create a table question in which I will save question and votes count(tow more column to store count up and down votes)
Create a table votes in which I will save votes(up and down).
This time we can get the data from one tablw without join.
I always want to know which one I should use.
I know that in first approach we need to put more joins if we add more feature like (Share,View,Answer,etc).
And if i used second approach we need to take care of consistency and we also need to insert more times as in first approach.
I don't know someone who can answer this. That's why i am asking my question here.
Any help would be appreciated, Thanks.

You will learn a lot by looking at the Stack Exchange Data Explorer.
https://data.stackexchange.com/
In addition to seeing the schema and being able to type interactive queries, you can view, execute, and modify the excellent library of useful queries other people have contributed.
It's a wonderful way to learn from a real-world site.

Related

Nesting table inside each row

I'm new to web design and I am making a niche social media site. I just want some general advice on the best way to design SQL database. I am using my sql and currently plan on having a profile table, that stores basic profile information (username, password, random other facts like location).
My question is can a cell serve as it's own separate table? I'm imagine each profile row will have a friends table inside of it that list all of the friends for that profile.
Is this the right way to go about designing? While not likely, i'd like a design good enough to scale in case I get thousands of users. Any advice would be greatly appreciated.
My question is can a cell serve as it's own separate table?
By "cell" I assume you mean a single value in a row. You cannot nest another table inside a row value. You could do something similar using an XML value, but more than likely what you are trying to accomplish is easily done using a foreign key in the friends table which references the primary key of the parent profile row. This known as normalization.
As for your other questions, those are too broad to be appropriate here. You should read through a basic tutorial/primer on database design. There are mountains of content someone could fill an answer with just to cover the basics of database design. "Database Normalization" and "database design best practices" are good starting Googles.

Creating a Poll application. Need advice on database structure for the vote count

I'm writing an application to allow users to create a Poll. They ask a question and set n number of predefined answers to the question. Other users can vote on the answers provided for that question.
Current structure
I have designed the database like this:
Storing the vote count
Current thinking is, I create a new column called vote_count on the link table and every time that answer gets voted, it updates the record.
This works. But is it right? I'm new to database systems, so I can't imagine I'm doing much right. What are some more efficient ways to achieve this?
As far as it goes yes that's OK. However these tables will be incomplete. When your second quiz is created, you'll have to extend the QUESTIONS table. If this second quiz's Q1 also has a yes/no answer, you're going to have to extend the LINK/VOTES table.
You also have to think about how it's going to be queried and design indexes to support those queries.
Cheers -

survey with answer options referring to master table, like cities

I'm creating a small questionnaire, with below database design; following the schema from this thread made by Michael Durrant, with slight modification.
Now, for some questions, I must provide cities as options of answers; which already there in master_cities table.
Eg: Which city do you reside now?
Answer will be in dropdown format which derived from a master_city table.
I shouldn't copy the whole content of master_cities_table into option_choices table, should I???
Any ideas are greatly appreciated.
Edit: I'd like to clarify the question.
This question is totally unrelated with UI/UX, pure db design.
The goal I'm trying to achieve is to avoid data redundancies such as copying master table records into options_choices.
Since it's a survey system, all the choices of answers must be
database-driven, like A. Strongly agree, B. Neutral, C. Totally
disagree. Which could be reused to answer other questions, like
"Where were you born?" or "Which cities have you lived before?"
Master_cities table here is only one of the master tables (and the
biggest) that I need to refer to provide choices of answers.
Hope that clears the confusion.
Current approach:
I removed the referral_table field in options_choices table and put it
inside the options_group table instead,
set option_choice_id in answers table as NULL-able,
and save the master_cities primary key as text in answers_text field.
That seems to work.
But, there maybe a better approach out there, so you're welcome to share your insights, oh db experts!
Don't know. Usability would suggest that too long a drop down list won't be a good user experience.
Another approach would be to try type ahead, similar to what Google does when you start typing terms in the search text box, to look up city names. Once the user types a letter into the text box, you can narrow the query down and only present city names that match.

How do I properly structure my relational mySQL database

I am making a database that is for employee scheduling. I am, for the first time ever, making a relational mySQL database so that I can efficiently manage all of the data. I have been using the mySQL Workbench program to help me visualize how this is going to go. Here is what I have so far:
What I have pictured in my head is that, based on the drawing, I would set the schedule in the schedule table which uses references from the other tables as shown. Then when I need to display this schedule, I would pull everything from the schedule table. Whenever I've worked with a database in the past, it hasn't been of the normalized type, so I would just enter the data into one table and then pull the data out from that one table. Now that I'm tackling a much larger project I am sure that having all of the tables split (normalized) like this is the way to go, but I'm having trouble seeing how everything comes together in the end. I have a feeling it doesn't work the way I have it pictured, #grossvogel pointed out what I believe to be something critical to making this all work and that is to use the join function to pull the data.
The reason I started with a relational database was so that if I made a change to (for example) the shift table and instead of record 1 being "AM" I wanted it to be "Morning", it would then automatically change the relevant sections through the cascade option.
The reason I'm posting this here is because I am hoping someone can help fill in the blanks and to point me in the right direction so I don't spend a lot of hours only to find out I made a wrong turn at the beginning.
Maybe the piece you're missing is the idea of using a query with joins to pull in data from multiple tables. For instance (just incorporating a couple of your tables):
SELECT Dept_Name, Emp_Name, Stat_Name ...
FROM schedule
INNER JOIN departments on schedule.Dept_ID = departments.Dept_ID
INNER JOIN employees on schedule.Emp_ID = employees.Emp_ID
INNER JOIN status on schedule.Stat_ID = status.Stat_ID
...
where ....
Note also that a schedule table that contains all of the information needed to be displayed on the final page is not in the spirit of relational data modeling. You want each table to model some entity in your application, so it might be more appropriate to rename schedule to something like shifts if each row represents a shift. (I usually use singular names for tables, but there are multiple perspectives there.)
This is, frankly, a very difficult question to answer because you could get a million different answers, each with their own merits. I'd suggest you take a look at these (there are probably better links out there too, these just seemed like good points to note) :
http://www.devshed.com/c/a/MySQL/Designing-a-MySQL-Database-Tips-and-Techniques/
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
http://www.sitepoint.com/forums/showthread.php?66342-SQL-and-RDBMS-Database-Design-DO-s-and-DON-Ts
I'd also suggest you try explaining what it is you want to achieve in more detail rather than just post the table structure and let us try to figure out what you meant by what you've done.
Often by trying to explain something verbally you may come to the realisations you need without anyone else's input at all!
One thing I will mention is that you don't have to denormalise a table to report certain values together, you should be considering views for that kind of thing...

Simple survey database design

I'm creating a survey for visitors of my event.
However it's been a while since I created a database. So I need some help.
I found some solutions but they are way to extensive and that is something I don't need.
Visitors need to stay anonymous but they can leave their email behind (seperate table Emails that isn't linked to anything atm).
They have about 20 questions, some are open, some are one option(radio) and some are multiple options (checkboxes).
The questions need to be reusable.
That's about it.
I just don't know how to go beyond the many-to-many in the diagram you see below.
How do I go from here? An Answers table needs to have a relationship with? The Surveys_have_Questions, or with Questions?
Edit:
As the answer in the following links mentions, most surveys are based upon classic design patterns. Mine is one of those surveys. More info in the link below:
What mysql database tables and relationships would support a Q&A survey with conditional questions?
I would probably model the event of a user taking a survey, perhaps a table called "User_Answer_Session", which has links to the survey and the user; and then "User_Answers", which are tied to the session and the question and include the actual blob of the answer. How exactly I modeled the answers would depend on a few things (mainly how robustly I wanted to be able to look them up). For instance, do I want to be able to index multiple-choice answers for extremely rapid reporting? If so, then you need to model for that. This may include creating a "Question_Options" table, which is a one-to-many between a question and the available options...
This should get you thinking along a good path. :-)
well i dont see reason why you need all these tables ! i think it can be much simpler than that.
surverys
desc VarChar
startDate timestamp
endDate timestamp
isOpen boolean
survery_questions
survery_id int (FK)
question Text
vote_count unsigned INT
user_survery
user_id
survery_id
unique key (user_id_survery_id) #to ensure no duplicate votes
That all :).
when ever a user vote just run
insert into user_survery (user_id,survery_id) VALUES (1,1);
update survery_questions set vote_count = vote_count+1;
when u need to get a survery result
select * from survery_questions where survery_id = X;
etc.