Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm new to programming, and hope this question isn't too basic. I've searched the questions here but can't find anything exactly like it.
I'm making a website in which people have to complete a sign-in form and then answer a survey. The survey answers will drive how the site performs for each user (there will be different monthly reminders in email personalized to the survey responses). I have two MySQL databases, one for the sign-in and one for the survey.
How do I get the member ID in the member database to be the same as the survey ID in the survey database? Or am I thinking about this all wrong, and there's another solution?
I'm most familiar with PHP and JavaScript, so I hope that there will be a way to do this in the coding if not in the database design. Again, sorry if this is too basic and many thanks in advance for your help.
This is a terribly generic question to answer, but I hope I can help you a little along:
Now, assuming that you have a good reason for separating the user registration and the surveys in two different databases (you did not give a reason for it being so), after a successful user registration you can assume that the user is 'logged in'. This should mean that the ID of the registered user is available to you in code.
You do not have to have identical survey IDs and user IDs, it usually makes more sense to have a separate table knitting users and surveys together (with a user_id field and a survey_id field).
After setting up or saving the survey, store a record in this table, connecting the user with the survey.
If you were hoping for a more specific answer, I suggest you delve into a little more detail in your question.
Good luck!
Just some hints, they won't rock the house but probably good for a start:
Put the two tables in the same database. This is less a technical requirement, but it's easier for you. The two tables belong together, keep them in the same database.
It's okay to have two tables.
The member ID and the survey ID do not need to be the same. Instead add a memberID column to the survey table and set it to the appropriate ID of the member table.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am aware that this question is asked before and common solution would be like in this link. Separate tables and use join to get information
How to store multiple emails work, personal etc for one contact in MySQL
I just want ask is there any drawback if i saved comma separated emails, numbers, fax or address . This will also eliminate Joins hence better performance. Thanks in advance
With any database-driven application, it's helpful to ask: "What questions does my application need the database to answer?" In other words, what are the main use cases for querying?
The link you provide is basically an example of normalized relational database architecture. Normal forms are meant to minimize duplicate data and ensure data integrity. Within those "quality-control constraints," query-writing is supposed to be fairly patterned and predictable.
Will you need to know if a contact has duplicate email or phone numbers? If multiple contacts share the same email or contact? If phone1 is missing but phone2 is not missing? If all the phone numbers have international prefixes? Those are all questions that can be answered with a database query. And those queries would be much easier and much more straightforward to write with a normalized database (like the one in the link). With data in a single field of comma-separated values, the queries would be hard, impractical, ugly, or virtually impossible to manage.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing a database that will match up care workers to clients. The carers visit the clients and assist them to get dressed etc. So the carer table holds there information such as what gender they are do they drive etc. If a client wants a female carer then I would check to see the gender of the relevant carer and all male carers would be excluded. I started down this route with my tables but soon discovered there was lots of combinations of questions and answers.
I don't know if this requires a many to many relationship but I'm a bit lossed off.
Any help would be gratefully received.
You should use a bridge entity to eliminate the many to many relationship between your Carer and Client tables. This Transaction table would also allow you to add additional transaction-based information to that entity such as Driver, etc... that wouldn't belong with either the Carer or Client.
Something like this:
Carer
Carer_ID PK
Name
Gender
Address
Vendor_ID FK -- Assuming your individual carers are part of a network
etc... Other Carer based details
Client
Client_ID PK
Name
Address
Gender
etc... other Client based details
Transaction
Transaction_ID PK
Client_ID FK
Carer_ID FK
DateTime
Location
Driver_ID FK -- Assuming you want to add a driver table
etc... Other transaction based details
As a follow-up... I personally disagree with those recommending the Entity-Attribute-Value design. EAV might be okay for basic look-up values in a front end application but basing your overall database design on it is a very bad idea (for integrity and maintenance reasons). It is much better to follow standard relational database normalization practices and create an entity table for each of your primary actors.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am fresher in database side. I am developing entertainment site. That site having user comment, reply comment for that user comment and rating for that user comment. For this, how I can design a database to store user comment, reply comment for that user comment and rating for that user comment.
User can post their comment only when login into the site. But this restriction is not apply for rating. User can give a rating without login into the site.
Any help will be helpful. Thanks.
2 tables; Comments & Replies
table comments:
#Comment_id(int)(pk)
*Users_id(int)(fk)
*Comment_content (varchar(500))
*Comment_rating(int)
*Comment_date(date)
table replies:
#Reply_id(int)(pk)
*Comment_id(int)(fk)
*Users_id(int)(fk)
*Reply_rating(int)
*Reply_content(varchar(500))
pk-> primary key
fk-> foreign key
#-> unique identifier
*->mandatory
The table "Users" is the table where your users are stored. Keep note this stores the content of a reply as flat text. I did not take into account the possibility of uploading images.
The rating fields are mandatory because the comments and replies have ratings. The fact that you need to be logged in to comment or reply is enforced because an user id is required. however to enable anonymous users to rate, that should not be done in the database at all. That should be done on the website itself. That would be a button that updates the field of the comment/reply with the corresponding ID.
note; this is not a perfect example. you should do research on database design and normalization. Nevertheless this will get you started.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am still fairly new to creating rails apps from scratch and would like to know the best way to set them up for efficient queries.
Consider this scenario. You are building a social site that shares books using mysql2 for a database. You start with two models; a user and an author. Both need name attributes; first_name, middle_name, last_name etc.
Would it be more efficient to create a name model where name would be it's own individual table?
Or add name attributes to the individual user and author where the attributes remain as columns?
First, you might consider implementing this using PostgreSQL - there are many, but performance is one of the reasons.
More, you have to think the system you build should be maintainable. Having a separate table for the name can be a very bad idea. Do you plan to add names for all the models you have in that one name table? Sounds weird. What problem do you think you could solve by doing that?
Instead, I think indexes can help you out (https://tomafro.net/2009/08/using-indexes-in-rails-index-your-associations) when it comes to retrieving associations.
And I cannot give you more advices on your data model. This depends on the requirements and future intentions. Are you going to query per model and then retrieve associations? Is there going to be sort of a tagging approach to handle synonyms?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a question about how big companies manage a database structure, let's say if i have an ecommerce app something like shopify which is the best approach you take:
a) When a new user creates an account a new database with his tables is created specifically for that user (i think if for some reason this database fail the other databases of other users remain working)?
b) When a new user creates an account Instead of create a new database, the app just create a new row in a table for his login and then all the products of all users are in the same table and only the user_id is the difference between one product of a store and another.
Thanks in advance.
Yeah, you should go for the second option (b), for alot of reasons:
1. Most of the data in your database shall be accessible for all users, so you don't want to have the same data stored in multiple places.
2. Sooner or later, you will come up with features where you want to share or link data between different users, etc.
3. Your first choice (a) would be extremely resource consuming compared to the second choice (b).
4. Well, the list can go on and on... :)
Obviously, the second choice - much more efficient and smarter.
Think about the number of the users, let's say 10k for example.
you realy don't want to handle this mass of tables!
I would go with Option B. This will reduce your work load and help in reporting needs down the road. Just make sure you use a robust database design to handle load when writing to database tables.