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.
Related
(Table Relationships)
I'm developing a travel agency database, and I've got a table for contacts (people), a table for trips, and a junction table, people_has_trips. "Trip" refers to a table whose identity is mostly many-to-many relationships with various optional travel elements such as hotel, flight, etc. (I have doubts about this structure, but that's an issue for another question).
Anyway, I'm in the early phases of designing the form for Trips, which will almost entirely consist of subforms linking to junction tables. The problem that's given me the most difficulty so far is that of how to add a contact to a trip. I'm fairly new to access, and thus far I've been populating such tables using autofilling comboboxes, but the contacts table contains over 100,000 records, and as such some sort of search function would be prudent.
Here's what I have so far. This subform is based on the people_has_trips table, and currently is limited to showing existing records. I disabled all fields as not to allow the editing of People records, but I'm somewhat stumped as to how to handle adding more people. In my limited Access knowledge, the most logical solution to me seemed to be having a button to open a form that would allow the searching of People and perhaps the addition of new people.
Now, I have a fully realized form for entering new People (shown below), but it doesn't have any real search functionality besides Access's built-in filters. So my subform currently opens People and... does nothing else. Quite frankly, I have no idea where to go from here. Do I develop a second form for searching people, or do I build in search functionality to the primary People form, something I should probably do anyway? If so, How? And after doing either of those things, how do I then populate people_has_trips? The only answer I can think of involves the user clicking the button to open People, finding the person they want to add, and then manually entering the primary key into the subform, which surely isn't optimal.
The aforementioned People entry form
The solution, I would wager, is VBA commands. I've recently taken the time to learn some VBA, and I'm a bit more comfortable with it, but I just don't know where to begin with this problem. I'm confident that I can adapt and apply other people's VBA ideas and code, but I can't find a thread on this particular issue from which to do that! I'm guessing the reason I can't find any help for this issue is that it's so blatantly obvious that nobody has asked the question yet, or my Google skills are lacking. Either way, I'd be quite happy to facepalm in realization of the solution. Thanks any and all for their help!
You need to be focused on your core problem and as far as I understood, you want to search and add "users/contacts" to your "People on this trip" form.
Yes combo-boxes can eat up time loading 100k rows and it's not really search friendly.
In your "People in this trip" form you can:
have a text box => for search
have a combo-box => showing search result
[Search] [Add] [Clear] buttons
In theory,
search button performs a search on your TContacts table and assigns the results to the combobox. something like SELECT PersonId, FirstName, LastName From Prople WHERE firstName like #keyword OR lastNAme like #keyword ... other fields
User selects a specific result form the combo-box.
Add button then performs SQL operation adding selected user to your junction table and refresh your junction table.
something like: INSERT INTO people_has_trips (people_personId, trips_tripId) values (#selectedPersonId, #tripId); followed by requery
This is just a theory, you need to try out something and narrow it down to a specific problem. Otherwise your question might be marked as too broad.
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.
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.
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.
I have a MySQL table , each row representing a Person. For each person I would like to show a list of related links (when generating his page on my website), so I created a column called "RelatedLinks" which there I save raw HTML content such as:
Related Link 1 Related Link2
Then I just use PHP to echo $row["RelatedLinks"]; within the HTML itself.
The problem with this implementation is that I have little control over the links, for example in changing their order of appearance on the website, deleting/editing a specific link and so on.
The second idea I thought about was to create a column in the table for each related link, such as "RelatedLink1", "RelatedLink2" and then use PHP to echo $row["RelatedLink1"] . "<br />" . $row["RelatedLink2"].
Although I do have much more control with this implementation, I think I am creating a big overhead in the table.
What is an efficient way to achieve this functionality?
EDIT
Referring to Gabriel's answer, the question now is about complexity:
With the current implementation, once I select the person I have all the links in my hand - complexity of O(1). What will be the complexity of running a query to select all foreign keys of the current Person, as suggested by Gabriel (and Haim) below?
Thanks,
Joel
If you only want to store and display the links, and the edit actions are very few, the first option is the best one. In this case, you will have to save the new values on edit.
If you think you'll have more edit operations, you could try to create a second tabel, to contain id_pearson, link, text, order . And you can use this tabel to edit the links for a specific pearson.
Also, if you need the same link for two or more persons, it's preferable to use 3 tables.
persons table : id_person, name (and all other info)
links table : id_link, text, link
person_links : id_person, id_link, order
Using this setup, you can edit the links in one place, and all persons will have access to the same version.
LATER EDIT IN RESPONSE TO COMMENT
Okey, regarding complexity of operations, nothing could beat the first solution. But you must take in account several things regarding what you need:
how often do you expect to change the links ?
who is gone change the links (the admin of the site, or the end user) ?
how many cases of the same link to appear for different persons (using the first solution, you will have to edit all persons that contain that link )
To answer your question of complexity, the solutions proposed by me are O(n) if I'm not mistaking. Using foreign keys and proper indexing in MySql, you shouldn't have a problem with this.
Summary: if performance is very important to you and the links will be edited only by the admin, use the first solution. If not, I would use the third one.
Hope this helps,
Gabriel
You need a secondary table that contains a PersonID (foreign Key), RelatedLink(ID) and maybe an OrderID.
Something like
Table PersonRelatedLinks
PersonID
RelatedLink or RelatedLinkID
OrderID
SpecialFormat maybe