I'm posting this here in the hope that someone can give me some ballpark advice as I am a frontend and don't know PHP/MySQL well.
I've heard of triggers but I'm not sure if they are appropriate for my use case. This is more of a conceptual question, before I start the code. Please be kind, I'm a novice :)
I have built a table set up like so:
+-----------+-----------+-------+
| UNIQUE ID | Anchor | URL |
+-----------+-----------+-------+
| 1 | link name | [url] |
| 2 | link name | [url] |
| 3 | link name | [url] |
| 4 | link name | [url] |
+-----------+-----------+-------+
This is linked up to an HTML form where a user can set custom links to appear in a menu.
I would like it to be the case that the MySQL table can only ever have four rows and the unique IDs stay constant and are not overwritten. However the 'Anchor' and 'URL' rows can be overwritten.
This is so that I can have a permanent hook on the row (via a WHERE uniq_id=x SELECT rule) whilst allowing the user generated data to change.
I want it to be the case that the link output to the front end will always be the last one set by the user.
I have really searched but no one seems to've had a similar request which implies I may be going about this completely the wrong way. Grateful if someone could direct me to the right track. Thank you.
I've been tasked with creating a physical event logging system, where an employee will create an event based on a physical event that occurred purely for logging purposes. For example, say they answer the phone - they must then create a "Phone" event and fill in who called, why, and when.
Each event will have the same input fields accessible to enter, however some of them require additional input fields that are only accessible to specific event_types.
Here's a snippet of the schema:
table: event_types
| column | type |
|--------|---------|
| id | integer |
| name | varchar |
table: events
| column | type |
|---------------|----------|
| id | integer |
| report_id | integer |
| user_id | integer |
| event_type_id | integer |
| date | datetime |
| details | text |
| locations | json |
| people | json |
| data | json |
Basically, the event_type_id can be one of 50+ event types. Only 15 of them will require unique fields. These event types are static when the app is installed (they are seeded into the DB), and users won't be creating them in the app itself.
The locations, people and date field will be available inputs on every event. My initial thoughts was to have a data json field to store additional input field data.
However, I'm not sure if this is the best way to handle unique input fields depending on specific event_type_id's. I'm also not sure how I'll handle validating these unique fields based on the event_type_id.
Would it be best to hard-code event_type_id's and then assign validation rules depending on which event_type_id an event is created with? I'm also wondering how to handle this when rendering the form view to load in the additional input fields.
I've also thought about storing the validation rules and the view name inside the event_types table, but I thought doing so may be bad practice since I'd need to update the event_type record in the database anytime I want to add another field.
I'm really hoping for some advice from anyone who's had to implement handling unique fields within their database - I'm really not sure how to handle this properly... Thanks so much for your time!
EDIT: I've went with a hybrid - a very limited version of the Entity-Value-Model and json data fields. I'll be posting my complete implementation in the coming days for others in case it helps anyone.
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.
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 want my users to activate their accounts before they are able to login. They are sent an email after registration containing an activation link, something like this:
http://www.blabla.com/activate.php?email=blabla#blabla.com&token=Aisd23uNMAu53932asdDasd82AS
Of course, whenever someone logs in, I have to check wether or not that user has activated his/her account. I can think of 2 ways to solve this problem, either have an extra column in my 'users' table, which is set to empty whenever a user activates like so:
-----------------------------------------------
| id | username | password | activation_token |
-----------------------------------------------
| 1 | user1 | blabla | |
-----------------------------------------------
| 2 | user1 | blabla | asd232DA34qADJs2 |
-----------------------------------------------
Then I extract the activation_token along with the user-information whenever a users logs in. Or I could have a seperate table that contains activation tokens only, which is then joined on the 'users' table everytime a user logs in:
--------------------------------------
| id | account_id | activation_token |
--------------------------------------
| 1 | 37 | dsad2428491dka98 |
--------------------------------------
| 2 | 2 | asd232DA34qADJs2 |
--------------------------------------
So which one would be most efficient? Thanks for your time.
EDIT: Thanks for all the great responses
Personally, I'd do a combination of the two...
-------------------------------------
| id | username | password | status |
-------------------------------------
| 1 | user1 | blabla | 1 |
-------------------------------------
| 2 | user1 | blabla | 0 |
-------------------------------------
Where the status is a TINYINT(1) field which is 0 for deactivated users, and 1 for activated users. That way, you can tell really quickly the "status" of the user...
Then, store the token in another table (just like you already have)... That way, you don't need to join, or check a string column when not activating the account...
Use the first option - add an isactivated column to the USERS table.
There's no need for a separate table - this is a one-to-one relationship.
Storing the token in the Users table rather than a seperate table will mean that you don't have to join them during each query, which will be slightly quicker.
Also, you're not storing the userIds and creating a new Id for that tokens table, which will save on the data storage.
I would have an integer field, Activated, that is defaulted to 0. When someone attempts authentication, you would only look for Activated accounts. I store auth tokens in a separate table like you have described.
If the relationship is 1-1 (e.g. the activation table would have 1 row per account id), then doing a fully normalized 2-table approach is an overkill.
You would not have major problem with either approach but 1-table one is easier.
If you go with 2-table approach, you should store "activated" yes/no flag in the user table, so you don't need to join to a second table for user login purpose.
If the activation token is only ever used to validate the 'click here to activate your account' link and is never used again, then there's no point in wasting space in your user table storing the char(32) (or whatever it is) field for a one-time usage. Put the activation tokens in a seperate table that your account activation script can refer to when the user clicks through to activate. Once the activation's completed, you can delete the token's record from that seperate table.
Put an 'is_activated' boolean/bit field in the user table that your login script can check during the login process (and output a "hey, you haven't activated yet" error if the field's null/false).
Of course, disk space is cheap these days. Even a million users each with a 32char activation token will only 'waste' 32meg of space. With a terabyte drive going for less than $100, that's 0.00305% of the disk, and essentially $0.00 cost (0.305 cents).
I don't think there's a need to store the activation token in DB. Something like md5('users#email' . 'secret') will work just fine. As for user status, i agree with others, use a separate dedicate "status" column in the users table. An additional advantage is that this column can store others stati as well (e.g. "banned" ;)
In my opinion instead of activation code being stored in users table, keep a flag set it off by default. when a user clicks on any activation link, then update the table and set the flag on.
Before logging in check the flag is on or not.
If flag is off then the user has not clicked on the activation link. then you can give a error message to the user.
If flag is on then the user can log in successfully.