In teaching myself php and mySQL a year or two ago, I created a movie database for the theater I work at, to help automate the more mundane web updates that need to be done weekly. So far this only pertains to film information (title, ratings, synopsis, start date) - but does not include showtimes, but lately I've thought it might be fun to see if it's possible to build on this aspect of the site.
My initial idea was to build a table that displayed showtimes via date groups (ie 5/15 - 5/20), but it was suggested that submitting times for individual days would probably be more useful from a user perspective (ie the showtimes for 5/15 are...), especially since there are occasionally changes and cancellations throughout the week due to special events.
Problem I'm having even starting this - is how to submit more than one date at once. Would it be possible, in the form, to have a 'start date' and 'end date' and have the single form submit all the times input on those two dates and all the dates inbetween?
From a back-end perspective submitting the same 4 or 5 showtimes every day, 7 days a week for 10 to 14 films a week is more work for US than just putting the times in manually in dreamweaver - so I'm just trying to figure out how to make the process easier for us behind the scenes. If we could batch insert a set of showtimes, then we could go back through and edit the individual days that have special/cancelled times (which would probably mean building in a 'draft, live, hidden' system - but I've got at least a basic knowledge of how to go about that.
I've got a very basic table set up for showtimes with (user end example of what I'm aiming for here):
MOVIE_ID (links with the movie info database to pull in film info - title, runtime, etc)
sched_date (uses datetime to set a specific showtime on a specific date)
I guess I might have to abandon using datetime if there's any way to do this?
Any help would be hot! Much thanks!
You can have 2 date fields with names from_date and end_date in your PHP form. In your PHP form submit code you then need to use the DateTime class and start from from_date and use the DateTime::add method to loop till end_date is reached. Please note you need to first convert the 2 dates i.e. from_date and end_date to datetime using either new DateTime('YYYY-MM-DD') or using DateTime::createFromFormat.
In the loop simply send insert commands to MySQL to insert the rows to your DB.
Related
I'm working on a calendar application where you can set events which can last multiple days. On a given date there can be multiple events, already started or starting that day. The user will view everything as a calendar.
Now, my question is: which of the following is the right approach? Is there an even better approach?
1) use 2 tables, events and events_days and store the days of every event in the event_days table
2) use just one table with the events stored with a date_from field and a date_to field and generate every time with mysql and php a list of days for the desired range with the events
Obviously the first option will require much more db storage, while the second one will require a bigger work from the server to generate the list (every single time the user asks for it).
The db storage shouldn't be a problem for now, but i don't know if will be the same in the future. And i fear the second option will need too many resources.
I have used both approaches. Here is a list of pros and cons that I have noticed:
Two tables: events(id) and events_dates(eventid, date)
Pros:
Query to check if there are events on a given date or between given dates is trivial:
SELECT eventid FROM events_dates WHERE date BETWEEN '2015-01-01' AND '2015-01-10'
Query to select the list of dates for an event is trivial
SELECT date FROM events_dates WHERE eventid = 1
Cons:
While selecting the list of dates is trivial, inserting the list of dates for an event requires scripting (or a table-of-dates)
Additional measures required to make sure data remains consistent, for example, when inserting an event spanning three days you need four insert queries
This structure not suitable in situations where time is involved, for example, meetings schedule
One table: events(id, start, end)
Cons:
Query to check if there is are events on a given date or between given dates is tricky.
Query to select the list of dates for an event is tricky.
Pros:
Inserting an event is trivial
This structure suitable in situations where time is involved
In my application I'm developing a functionality for creating "reminders".
A reminder has a date and a time. In my application, I have a form to create / edit reminders - this has two separate fields to input this information:
<input type="text" name="date"></input> <!-- datepicker plugin -->
<input type="text" name="time"></input> <!-- timepicker plugin -->
Now as a rule I have always used a DATETIME column whenever I have needed to store date/time, however this is the first time I'm having to store a user inputted date/time.
I figured it would be best to have seperate DATE and TIME columns, because it would be easier to insert / retrieve the data to / from my application. For example I won't have to combine the values from the two input fields to create a single value to insert in to the database. And likewise I won't have to split a single value in to two values to populate the form fields in edit mode.
But on the other hand won't it be easier to query the table if I used one column? What do you think?
You should build bottom-up (database at the bottom). Don't think about the application, just the database. Now, what makes sense at the database level. DateTime.
So you need to write extra code at the application level.
Please see it
Adding a Timepicker to jQuery UI Datepicker
http://trentrichardson.com/examples/timepicker/
convert your date time according to your mysql format and store it
$mydate = strtotime($_POST['date']);
$myfinaldate = date("d-m-y", $mydate);
$mytime = strtotime($_POST['time']);
$myfinaltime = date("H:i:s", $mytime);
Seperating columns is unlogical. You can use timestamp as datatype and you can use mktime function to parse date and time easily.
Doesn't it depends on the system you're creating.
If you want to store dates beyond 2038 I would store the datetime and time separate.
what if you are developing a reservation application and at one end you need to know on what date and at what time to schedule an appointment for a user, and at the other end, you need to match the user to a doctors schedule. You save the doctors schedule in a database and you need to know (amoung other things) when the doctor is available (on what days), and at what times. Let us forget about the on what days for a moment, and focus on the time shedule first...
You need to develop a programmable schedule so that if you know that the doctor works 6 months in a particular calendar year. (Jan - Jun), He or she may work (9-5 M,W,Fr), and (10-3 T,Th). Sat and Sunday the doctor is off. So you develop a table to hold the Daily time schedule with 2 columns to hold the daily starttime and daily end time for each day of the week. 14 columns in total and a primary and possibly secondary key. So now its time for some date arithmetic (This is where it gets hairy:-|...
You can say i your query: (mySQL)
Select such and such...
where form.theapptdatetime between doctorschedule_startime_tuesday and doctorschedule_endime_tuesday
and this will do a match to see if your datetime is within the date range of your doctorschedulestartime and endtime... but what if all you need is the time??
will the date arithmetic still work if the time value is stored as a datetime???
In other words if I have 01:00:00 as my doctorschedule_startime, is this a legitimate date value for my arithmetic to work, or will a date portion be forced upon me.
Perhaps I should store the time as a varchar, and convert it to a suitable datetime value and perform the arithmetic in the code instead of the query????
An example comes to my mind as to when have date and time split:
You could want to have DATE a part of the unique index, so that a user is only allowed to add 1 record to some table per date, but still you want to know the TIME he added it, so you keep DATE and TIME separate.
I'm building a home rental system. The system stores profiles of homes and users can book homes for rent for periods as between one day to a year. I've got the booking part all set up except I am faced with a requirement from teh client to be able to set certain dates and date ranges as un bookable for homes.
A home can be available for a whole year for rent, or can be available for 6 months, or be unavailable on discreet days eg: Holidays and weekends for summer homes etc.
I'm perplexed as how would I be able to set up a database table to store this information considering that the information must be retrievable by a sql query. I mean consider the following situation, a home can be rented through out the year except on wednesdays, the 4th of July, 10 November to 25th December and 31st December.
How do I store this in a database and be able to run a query to check for a homes availability between set dates. I'm wokring in php MySql
There are two different concepts that you're describing: the "on Wednesdays" is not as much of a date range as it is a recurrence pattern. The same goes for "weekends".
You're probably looking at two different tables in addition to your property table that define these unavailable dates: one that represents specific date ranges and one that represents recurrence patterns.
Property
|
-------------- ---------------
| |
PropertyUnavailableRecurrence PropertyUnavailableRange
(Bear in mind that you might want to figure out shorter names)
PropertyUnavailableRecurrence would need to store the information necessary for turning "Wednesdays" and "weekends" into viable decision logic. I can't model this for you, since all of you've presented in this pattern are specific days of the week, but I'd imagine that you'd need to be able to account for "First of the month" or "Second Wednesday of the month", but I don't know. In any case, this is where you'd need to store that information.
PropertyUnavailableRange would just contain simple From and To dates that define the range. This part is pretty simple.
Of course, an alternative would be to take the recurrence patterns specified in the application and turn them into discreet PropertyUnavailableRange records, but you'd still need to set up a table to store these recurrences and associate the discreet records with a recurrence so that you could manage them.
One approach is to have a table, PropertyUnavailable, with the following structure:
create table PropertyUnavailable
(
property_id number not null,
when date not null
);
This table would have a row for each day that the property is not available because of a black out period (e.g., every Wednesday, Holiday, etc). I am ignoring how you will store the meta information of the pattern -- all this table wants are rows for each day where the property is not available because of a blackout period.
I assume you will also have a table for reservation days, PropertyReserved, with the same structure as above plus a foreign key to reservation_id (or something similar).
Now to see what day's are unavailable/reserved for a given date range, the sql would be something like this:
SELECT a.when, 'blackout'
FROM PropertyUnavailable a
WHERE a.when between <from_date> to <to_date>
UNION ALL (
SELECT b.when, 'reserved'
FROM PropertyReserved b
WHERE b.when between <from_date> to <to_date>
);
If nothing is returned with the query, then the property is available between the date range specified (from_date, to_date).
Did you consider simply booking those "unbookable" dates in the name of the system?
It appears that you are not clear about what is required to be stored in teh database; and what is required in code segments. Set the "unbookable" dates aside for a moment, assume you only have actual booked dates. Catcall has a point. What does your current code look like, when you search for available dates ?
SQL is quite capable of handling dates and performing date arithmetic. My NonSQL is not, you will have to store more in the databse than in real SQL. But you do not need to store rows per date. The Reservation table needs FromDate and ToDate only.
I am developing a website which will have 200.000 pages. There is also a browse section, which shows most popular, highest rated etc. documents. However this section will become almost static couple of weeks later, after launch. So I also would like to implement a filtering system which will show today's, this week's, this month's most popular items, just like youtube.
Just like this:
http://www.youtube.com/videos?c=2
How should I implement this function? Do I need another table, which will have a new entry for every document each day?
docid, date, view_count, rating
So I will get today's row for filtering by using a day, or calculate a week (7 rows) for filtering by using week? It seems not efficient. Do you have any suggestions?
I am using LAMP stack by the way.
Thanks,
Assuming you timestamp the records in your table, you should be able to put a where clause that limits the timestamp to whatever timeframe you want.
You can cache the result, especially the longer ones, for long enough to make the request inconsequential.
EDIT
But perhaps you mean most popular today, not most popular that was added today?
In which case, I don't have an answer.
The most direct approach is to save the timestamp and the resource id each time the resource is shown in recent_views(what, when). Daily/weekly/monthly charts can be created with appropriate WHERE clauses like WHERE when > $beginOfPeriod AND when < $endOfPeriod.
For performance reasons you can aggregate the values each night, save the sums in separate tables like daily_views(what, sum) and truncate the source table.
I guess I would calculate the date's in code and then pass them as arguments, to the SQL you are using.
I would do it using a compiler. Youtube probably does that too, considering the amount of traffic and the response times.
The principle is easy to understand. You log every every view or rating in a page_view table. You define periods at which the compilation occurs (hourly, daily, weekly, monthly). Every time you hit the good time (e.g.: end of the day), you execute the compiler, which essentially execute a query à-la...
SELECT * FROM page_view WHERE date > $from_date AND date < $to_date
... and store the result. This probably works better in a cron job.
The next time you need to display the information, you can just fetch the stored result and display it without re-computation. There are a variety of storage methods you can use: a MySQL table (e.g.: page_view_compiled), memcached, etc.
I'm building a simple calendar for holiday cottages to show when they are booked or available.
What would be the fastest mysql table design for this, bearing in mind when users mark dates as available/booked they will do so via a start date and an end date.
i can see 2 obvious options
Store 'booked' data for every day [more rows]
or, store 'booked' data with 2 columns a start_date and end_date [more processing?]
Which is best or is there another method i'm missing?
The data is to show a visual calendar on each property's page
Definitely option 2. Index both start_date and end_date columns and you'll be fine.
Your code will need to ensure there are no overlaps for a given cottage.
Well, exactly how to approach this depends a bit on the entirety of your model, but my first thought would be to model this in terms of bookings. That is, I would have an entry for each booking, and store the start and end dates. I wouldn't worry too much about efficiency here. With the amount of data it sounds like you're talking about it should be plenty efficient as long as you don't do anything unreasonable.