I am trying to design a database for the known 6/49 lottery game. But I am confused about designing. First thing came up my mind is something like that:
Table Users:
ID | Name | Age | mail | username | password | balance | etc. |
Table Coupons :
ID | Date | Draw Date | Chose 1..6 | isWinner | owner username | earning | Cost |
Is that enough? Or I really want to hear new ideas. For example, after a drawing, I am going to enter results to the system. Then system has to check all the coupons which belong to relevant draw date.
However, wouldn't it be too much load if there are hundreds of thousands coupons of this particular draw date? What is the best desing for this system? Or wouldn't it be to much load when a user tries to list the coupons that s/he has played in his/her account page?
And I have to say that, I am very junior about database designing.
Related
I am looking for some general information in regards to User Table Design.
I have an old table design for 'users', which I need to update but not breaking the entire site's structure.
Current Table Design
UserID | Email | FirstName | Last Name | ...
1 | a#a.com | John | Doe | ...
2 | b#b.com | Jane | Doe | ...
I need to be able to create "Primary" users, as well as "Assitant" users.
Now I believe I should have a few tables designed:
Users
Accounts
Users > Accounts - (Relationships & Permissions)
IE: of users > accounts
TableID | UserID | AccountID | PERM
1 | 1 | 1 | 001
So I guess my question is. Is there a better way to do this? Specifically if there is a current design being used?
Hope this makes sense. Any direction in this would be greatly appreciated.
Here's an example where you'd have a table for each group, plus a users table. You can filter the users by group using a JOIN. Personally I don't love this. If anyone else has a better suggestion, I'd like to hear it.
http://sqlfiddle.com/#!9/993dd/1
I'm currently building a service in which students can log in and read messages written by teachers/admins, download files and check their grades.
Problem: I have no idea how to input their grades and how to display them.
I'll try my best to describe what I want to do.
Teacher (Inputs Grades)
Student (Display Grades)
I already have these tables on my MySQL databse and i'm using PHP + Boostrap.
+-------------------------+
| Tables_in_portal |
+-------------------------+
| Messages |
| Students |
| Admins |
| Subject |
| Teachers |
| Classes |
+-------------------------+
You can build a teacher panel page, give teachers' their username and password and let the teachers enter grades for each student and then upload using a form. This will automatically add grades in each students' column in the grades table in MySQl which can be seen by students when they login from their portal.
And don't expect anyone to write the whole code for you here.
How would things like customer reviews be stored in a database? I cant imagine there would be rows for each item and columns for each review as one product may have 2 reviews and another may have 100+ - id presume they were stored in a separate file for reviews but then surely not one file per item! I dont know enough about storing data to be able to figure this one out by myself!
A similar situation is something like an online calendar - there is all the information about each appointment (time, duration, location, etc) and there can be many of these on each day, every day, for all users! A logical way would be to have a table for each user with all their appointments in, but at the same time that seems illogical because if you have 1000+ users, thats alot of tables!
Basically Id like to know what the common/best practice way is of storing this 'big dynamic data'.
Customer reviews can easily be stored by using two tables in one-to-many relationship.
Suppose you have a table containing products/articles/whatever worth reviewing. Each of them has an unique ID and other attributes.
Table "products"
+-------------------------------------+
| id | name | attribute1 | attribute2 |
+-------------------------------------+
Then you make another table, with its name indicating what it's about. It should contain at least an unique ID and a column for the IDs from the other table. Let's say it will also have an email of the user who submitted the review and (obviously) the review text itself:
Table "products_reviews"
+--------------------------------------------+
| id | product_id | user_email | review_text |
+--------------------------------------------+
So far, so good. Let's assume you're selling apples.
Table "products"
+-------------------------------+
| 1 | 'Apple' | 'green' | '30$' |
+-------------------------------+
Then, two customers come, each one buys one apple worth 30$ and likes it, so they both leave a review.
Table "products_reviews"
+-------------------------------------------------------------------------------+
| 1 | 2 | alice#mail.com | 'I really like these green apples, they are awesome' |
| 2 | 2 | bob#mail.com | 'These apples rock!' |
+-------------------------------------------------------------------------------+
So now all you have to do is to fetch all the reviews for your apples and be happy about how much your customers like them:
SELECT *
FROM products_reviews
INNER JOIN products ON products_reviews.product_id = products.id
WHERE products.name = 'Apple';
You can now display them under the shopping page for apples (just don't mention they cost 30$).
The same principle applies for things like an online calendar. You have one table with users, and many tables with other stuff - appointments, meetings, etc. which relate to that user.
Keep in mind, however, that things like meetings are better displayed in a many-to-many table, since they are shared by many people (usually). Here's a link that visualizes it very good, and here's a question here on SO with sample code for PHP. Go ahead and test it for yourself.
Cheers :)
I am developing a website which will collect and store information for users.
I need to create a table specific to each individual user on registration to store the information they are searching for using the website. The table created will be named after the newly registered user's username.
Then when the user is logged in and runs the search, the data collected will be stored in a database using a MySQL insert query where the table name is a variable containing the logged-in user's username which will also be the table name.
I am an amateur developer and have searched everywhere to try and find a solution but I cannot seem to find anything evenly remotely similar to my problem.
Thank you in advance for any help!
Creating tables on the fly is more trouble than it's worth and very much swimming against the tide with any SQL database.
The reason you haven't found any docs about the approach you mention is because this problem is generally (almost without exception) solved best by having all the data in one or more tables, and including a column to specify which entity (user) the row is associated with. In your case, this might be an email address, or a username, or just a sequential number.
E.g.
| user_id | email | first_name | last_name | fave_color |
- - - - - -
| 1 | "a#b.c" | "anton" | "aardvark" | "red" |
| 2 | "b#c.d" | "miles" | "o'brien" | "infrared" |
| ... | | | | |
First take name from user like:
$fullname="$fname"."_"."$lname";
Then, write a query like this to create a table of that name
$sql="CREATE TABLE $fullname(ALL THE COLLUMNS YOU WANT TO CREATE)";
$result1=mysql_query($sql, $db_link);
this query is from my project. Works fine in wampserver.
I have a website that allows users with accounts. Account profiles are displayed on the front end of a website. Users can login and update their data, but it all must be approved by an admin (on a form) before the front end content reflects their update. The "live" data is stored across multiple tables in a Postgresql DB.
I'm looking for ideas for the (best / easiest) way to handle storing (db schema) this updated data that will allow an admin user to
approve/deny updates independently for a user (approve update A, deny update B, and ignore update C)
Be easy to maintain
Be easy for me to pull the updates to show admin and then process each individual field request.
Admin will need to be able to see a list of all users that have pending updates and then be able to see which fields for a specific user was updated so they can approve/deny the request.
Users can freely update a field as many times as they want, but admin will always see the current field content and the last update the user made.
I don't need to be able to see exact differences (although brownie points if you know how). They really just need to be able to see the two fields
ie:
Current Update
+--------------+-------------+-------------+
| | | (o) Approve |
| description | Description | |
| | | (o) Deny |
+--------------+-------------+-------------+
| | | (o) Approve |
| title | Title | |
| | | (o) Deny |
+--------------+-------------+-------------+
| [Submit] |
+------------------------------------------+
I'm open to any and all ideas, DB techniques, programming, or something else I haven't thought of.
Thanks in advance!
It's just a status of a record, an extra column in your tables holding the current status will be enough.