For now, the system should have 6 different user levels.
Each level will be gained upon user activity, for example:
Level 1 - When user register
Level 2 - When user completes a mission
Level 3 - When user completes more than one mission
Level 4 - When user donate > $X amount of money
Level 5 - When user write more than 50 comments in blog
Level 6 - When user complete quiz
And now... I'm wondering, what's the best database schema to achieve this? I should keep track of all actions related to user's activities, that's why I though about xp_events table... Something like this:
id # primary key
event # type of event, e.g. 'register', 'complete_quiz', etc.
user_id # id of user
delta # number of "exp" which will be gained after specific action
And... in users table I will keep record of current level and "exp" which each user has earned until now.
When user makes any activity, I will call a trigger which will check if user have new level unlocked.
But... I'm aware that in long term (e.g. if more levels are added), this isn't optimal solution.
Looking forward for any suggestions.
I see two obvious possibilities here.
One is to have an event table like you say, with a user ID, event ID, dollar amount (for donations), probably a date/time, maybe other data. If the only reason why you are keeping any of this data is to determine each user's level, this is simple and effective.
If you're keeping track of this data for other purposes also, you probably want to separate it into multiple tables. In such a case you would likely have other data you need to keep for each event. Like for a donation you would need dollar amounts, which I assume don't apply to comments and missions. For comments you likely need the text of the comment and some indication of the thread this comment is on or what it's subject is. For a mission -- I don't know what a "mission" is in this context, but you likely want some information about the type of mission and where it was or who they were supposed to kill or whatever. Most of this data would not be applicable to events of different types. A comment probably doesn't have a dollar amount, a mission doesn't have a thread, etc. So you'd end up with a lot of irrelevant data and bunches of null fields.
Related
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
I've got a PHP/HTML/Javascript driven front-end for a MySQL database which archives different files/papers for our office (kind of an electronic index for physical paperwork).
The users want to be able to have permissions on each of these entries; for instance HR complaints need to be indexed, but should not be viewable by all users of the database.
The user heirarchy is two-tier. Each user is a member of one OR MORE distribution lists (similar to an Email list). When a file is indexed, the user choses the permissions for others: for instance he/she can select the following for a sample HR complaint:
List | Permission
`````````````````````````````````
HR Dept | Read/Write
Board Members | Read
John Smith | Read/Write
Mary Smith | Read
and should be invisible to anybody else. Now I've tried several things to implement this, the most recent being a relations table which relates the following:
User 1->Many DistributionList // Assoc the user to some lists
Permission 1->Many DistributionList //Indicates level of permission that the list has
Permission 1->Many User //Indicates level of permission for each user
However the permission table contains a row for each file for each permission, which, given a few thousand files and ~50-60 lists/users, means a few hundred thousand entries. Since this index will not be flushed often (maybe flush files older than 50 years) that number could skyrocket. Not to mention that the queries are somewhat complicated, and take a decent amount of time (~1 second for the SQL request) for only a couple hundred files.
Is there a more efficient way to create this sort of User based stuff? Is it possible instead to make users in SQL itself with these permissions and let the connection handle these things?
tl;dr: What is the best way to put read/write/invisible permissions on entries in MySQL using PHP, Javascript, HTML and PHPMyAdmin?
If there are not many groups (64 max) you could use a SET of permissions for each file (1 extra column).
http://dev.mysql.com/doc/refman/5.0/en/set.html
So each file could have one column denoting which groups it belongs to, which can be expanded as the systems grows.
You could also add a second column if you want to go beyond 64, but that would require more complex queries (keeping departments separate would help here, HRgroups, Boardgroups etc..)
You could also add exceptions to specific users or create another group. But as you say one associating entry per file/user is the best your going to get.
I am developing a php text based game.
I am organizing tasks in games. Basically tasks increase the understanding of the game.
A task is a group of small actions in the game.
For example:
TASK Description: You are required to steal a bike, repair it and ship to another city.
It includes 3 actions.
Steal a bike
Repair the bike
Ship it to another city (let say London)
These 3 actions are possible at single of different pages.
I created a table for TASK(task_id, title, description (TASK Description Above),STATUS), but I'm not sure how to store and execute actions of task.
I have one idea, to use a related table TASK_ACTIONS (task_id, action_id,action(?),done)
But I'm not sure in which form to store actions action(?):
An sql statement to check for actions Like following three points.
Bike has been stolen or not. If yes, Mark action to DONE
Bike has been repaired or still damaged. If repaired, Mark Action DONE
Bike has been shipped to London or not. If shipped, Mark Action DONE
If all above marked DONE then mark TASK STATUS as COMPLETED, show next task.
A cheap way to do this would look like this:
tasks
{
user_id
has_theft_bike
has_repaired_bike
...
}
However, this is not easy to expand. A more correct way would be to define all actions in an actions table
actions // defines all possible actions (also actions not part of a task)
{
action_id
description
}
user_actions // has one record for every action a user commits
{
user_id
action_id
date // possible extra
}
tasks // all possible tasks
{
task_id
name
}
task_actions // all actions linked to a task
{
task_id
action_id
}
This way you log every action a user does. You could make a steal bike action and a repair bike action.
Now you can for instance retrieve all actions you need to complete task 5 (steal a bike and repair it). Then if all those action id's are in the user_actions table for your current user. it means the user has completed the task.
Just not that your user_actions table will grow really really really fast if you have a couple of users.
I am building a database in MySQL that will be accessed by PHP scripts. I have a table that is the activity stream. This includes everything that goes on on the website (following of many different things, liking, upvoting etc.). From this activity stream I am going to run an algorithm for each user depending on their activity and display relevant activity. Should I create another table that stores the activity for each user once the algorithm has been run on the activity or should I run the algorithm on the activity table every time the user accesses the site?
UPDATE:(this is what is above except rephrased hopefully in an easier to understand way)
I have a database table called activity. This table creates a new row every time an action is performed by a user on the website.
Every time a user logs in I am going to run an algorithm on the new rows (since the users last login) in the table (activity) that apply to them. For example if the user is following a user who upvoted a post in the activity stream that post will be displayed when the user logs in. I want the ability for the user to be able to access previous content applying to them. Would it be easiest to create another table that saved the rows that have already been run over with the algorithm except attached to individual users names? (a row can apply to multiple different users)
I would start with a single table and appropriate indexes. Using a union statement, you can perform several queries (using different indexes) and then mash all the results together.
As an example, lets assume that you are friends with user 37, 42, and 56, and you are interested in basketball and knitting. And, lets assume you have an index on user_id and an index on subject. This query should be quite performant.
SELECT * FROM activity WHERE user_id IN (37, 42, 56)
UNION DISTINCT
SELECT * FROM activity WHERE subject IN ("basketball", "knitting")
ORDER BY created
LIMIT 50
I would recommend tracking your user specific activities in a separate table and then upon login you could show all user activities that relate to them more easily. ie. So if a user is say big into baseball and hockey you could retrieve that from their recent activity, then got to your everything activities table and grab relevant items from it.
i m creating a project with php and html use.i would like to create a ticket reservation system for my university.Firstly,the user will choose a date and the number of persons that he wants to reserve tickets.Then,by pressing the next button,he could see the list of the events that are available in the date he checked in the previous step.this list will be static,so i think that i have to create a data base which will have this data and if the users selects ex monday,he could see the data events for monday.Could you please help me do this because i have no big experience with php?i have created the two screens with html and css but now i would like 1st to let me know how to create a data base with my data and secondly how to connect them with my day oprtions!
Thanks a lot!
Take a look at:
PHP 101: A Simple Seat Reservation System
It is not a simple task as you seem to think and explaining it is almost writing the software but I'll try :
Create database tables in the database engine of your choice
required tables
table [events] : colums{id Integer,event_date Date,title Varchar,tickets Integer, description Varchar}
/*
How many tickets are availble for that event, depending on the reservations Count you will show less and less available tickets and eventually you will stop the reservation
*/
table [users] : columns(id Integer,name Varchar,username Varchar,password Varchar)
table [reservations] :
columns(id Integer,
user_id Integer [foreign key to users],
event_id Integer [foreign key to events],
reserved_tickets Integer,
reserved_at Datetime}
/*
reserved tickets are used if you want a user to be able to reserve more than one ticket per person, for safety reasons you can limit that either by adding a new field in the event table where the event creator can choose how many tickets one person can have or either hardcode it in the code, but this is not so "fancy")
*/
Now you will need a lot of views interfaces:
User management interfaces :
1 List + 1 Add/Edit(administrator) +1 register (user can register them selves, this is optional) = 2 (3)
Event management interfaces:
1 List(administration) + 1 Add/Edit + 1 Event listing (in a calendar or something for reservations) = 3
Reservation management interfaces:
1 List(administration) + 1 Manage (Cancel/confirm the reservation of a user etc) = 2
You will need a login page, maybe a recover password/username, a screen where a user can see his reservation and cancel/confirm whatever.
These should be all html/flash etc eventually mixed or comunicating with code (PHP,JSP,ASP whatever)
Every html should have a control script "behind" it, meaning the actuall code that gets/sets info into/from the database, this is recommended to be in a separate file then the view (at least) and should be contained in a function or class methods and here are a lot of details to be said, to many.
I recommend that you try and understand CakePHP, it should fit you at this level and anyway to me it seems the simplest framework that one could use and understand empirically.
It's not an easy job as I said, this should take about 12-16 hours to be written from scratch to a professional programmer, and I think it will take you 5 times more even if you use CakePhp. (of course considering a modern interface,approach and functionality otherwise it would take a pro 6 hours at most)