In my database, I have two tables that are dedicated to handling recurring events.
An 'Events' table currently store names, descriptions, locations, start time and end time of events.
Another table, 'Episodes', takes the parent Event id as foreign key and stores event dates which are generated based on recurrency rules set with the PHP recursion library When. Recurrency logic and creation of all events-related database items is intended to happen in an Add/Edit/Delete-type interface.
This database structure follows what I consider a good suggestion from a forum thread on Devshed (the 6th post). My problem is that while this as far as I can understand allow the changing of date in single Episodes easily, the same is not the case if the user wants to change start and end times to a single Episode.
I want users to be able to easily modify the start and end time of all Episodes of an Event through a button in the UI, but at the same time be able to edit the start time and end time of single Episodes of an Event by clicking the event in a calendar, while also avoiding redundant start_time and end_time fields in the database. As I am relatively inexperienced with such issues in MySQL, some suggestions would be most welcome.
Related
I'm coding a website where users can add concerts/events and other users can modify the informations provided for every concert/event added on the website.
I want to save every modification that has been made and the user that made the modification. For instance there is this functionnality on Wikipedia where every article has saves of every modification made and the user who made it.
For now, I just save the name of the user who made the last modification(s), and the modifications aren't saved: when a modification is made it will just overwrite the previous value of the corresponding column.
You can see under the current state of the tables I'm talking about. One for concerts with different informations: artist, date of the event, hour, links related to the event etc...
and another one for users.
Current sql tables
I think a first step would to create separate tables for every element of a concert that can be modified, with 2 foreign keys (one linked to user, one linked to concert) plus the value of the element. But still, if a modification is made I still don't know how to save the previous value and previous user.
I've thought of puting values inside an array but I don't know if this is possible in SQL and if this is the best solution.
Thanks for reading/helping
You should add a column that mark the create/update time to the concert table.
Then create a new history table (same schema of concert) for storing concert changes.
When a user edit a concert:
Save the current state of concert content to the history table.
Update the new change to the concert table with the user_id of the user who perform this action
That's it! When you want to list the changes history, just query the history table!
If you want to log the delete operations as well, add another column and mark the end period of each version (a little bit more complex)
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.
Using PHP & Mysql-
I have a list of 120,000 employees. Each has a supervisor field with the supervisor employee number.
I am looking to build something that shows the employees in a tree like format. Given that if you click on anyone that you have an option to download all of the employees (with their info) that are under them.
So two questions - should I write my script to handle the query (which I have but is SLOW) or should create some sort of helper table/view? I am looking for best practice behind this.
Also I am sure this has been done a million times. Is there a good class that handles organization hierarchy?
The standard way of doing this is to use one table to store all of the employees, with a primary key field for the employee_id, and a field for supervisor_id which is a 'self join' - meaning that the value in this field points back to the employee id of this employee's supervisor. As far as displaying the employee tree - for relatively small trees, the entire tree structure can be sent to the client's browser when the page is created, and tree nodes can be displayed as the nodes are clicked from the stored data. But, for larger trees, it is better to fetch the data as needed, i.e. when the nodes are clicked. If you have 120,000 employees, then you might want to use the later approach.
I am rebuilding the background system of a site with a lot of traffic.
This is the core of the application and the way I build this part of the database is critical for a big chunk of code and upcoming work. The system described below will have to run millions of times each day. I would appreciate any input on the issue.
The background is that a user can add what he or she has been eating during the day.
Simplified, the process is more or less this:
The user arrives to the site and the site lists his/her choices for the day (if entered before as the steps below describes).
The user can add a meal (consisting of 1 to unlimited different items of food and their quantity). The meal is added through a search field and is organized in different types (like 'Breakfast', 'Lunch').
During the meal building process a list of the most commonly used food items (primarily by this user, but secondly also by all users) will be shown for quick selection.
The meals will be stored in a FoodLog table that consists of something like this: id, user_id, date, type, food_data.
What I currently have is a huge database with food items from which the search will be performed. The food items are stored with information on both the common name (like "pork cutlets") and on producer (like "coca cola"), along with other detailed information needed.
Question summary:
My problem is that I do not know the best way to store the data for it to be easily accessible in the way I need it and without the database going out of hand.
Consider 1 million users adding 1 to 7 meals each day. To store each food item for each meal, each day and each user would potentially create (1*avg_num_meals*avg_num_food_items) million rows each day.
Storing the data in some compressed way (like the food_data is an json_encoded string), would lessen the amount of rows significally, but at the same time making it hard to create the 'most used food items'-list and other statistics on the fly.
Should the table be split into several tables? If this is the case, how would they interact?
The site is currently hosted on a mid-range CDN and is using a LAMP (Linux, Apache, MySQL, PHP) backbone.
Roughly, you want a fully normalized data structure for this. You want to have one table for Users, one table for Meals (one entry per meal, with a reference to User; you probably also want to have a time / date of the meal in this table), and a table for MealItems, which is simply an association table between Meal and the Food Items table.
So when a User comes in and creates an account, you make an entry in the Users table. When a user reports a Meal they've eaten, you create a record in the Meals table, and a record in the MealItems table for every item they reported.
This structure makes it straightforward to have a variable number of items with every meal, without wasting a lot of space. You can determine the representation of items in meals with a relatively simple query, as well as determining just what the total set of items any one user has consumed in any given timespan.
This normalized table structure will support a VERY large number of records and support a large number of queries against the database.
First,
Storing the data in some compressed way (like the food_data is an
json_encoded string)
is not a recommended idea. This will cause you countless headaches in the future as new requirements are added.
You should definitely have a few tables here.
Users
id, etc
Food Items
id, name, description, etc
Meals
id, user_id, category, etc
Meal Items
id, food_item_id, meal_id
The Meal Items would tie the Meals to the Food Items using ids. The Meals would be tied to Users using ids. This makes it simple to use joins in order to get detailed lists of data- totals, averages, etc. If the fields are properly indexed, this should be a great model to support a large number of records.
In addition to what's been said:
be judicious in your use of indexes. Properly applying these to your database could significantly speed up read access to your tables.
Consider using language-specific features to minimize space. You mention that you're using mysql; consider using ENUM when appropriate (food types, meal types) to minimize database size and to simplify management.
I would split up your meal table into two tables, one table stores a single row for each meal, the second table stores one row for each food item used in a meal, with a foreign key reference to the meal it was used in.
After that, just make sure you have indices on any table columns used in joins or WHERE clauses.
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)