存储多个日期范围

Question

So I'm developing a carpooling system whereby users can submit what dates they can offer a lift for, or what time they are wanting to get lifts.

The form itself is going to be using a virtualised calendar where users can pick dates by clicking on them or select ranges of dates by shift-clicking for this. They will also be able to pick multiple types of selection, IE they can use a range of dates then include one or two more dates that don't obviously come in that range.

The format that will be produced for these dates will be as follows:

Standard one date: yyyy-mm-dd

Multiple dates:

yyyy-mm-dd, yyyy-mm-dd

One range of dates:

yyyy-mm-dd - yyyy-mm-dd

Multiple ranges of dates:

yyyy-mm-dd - yyyy-mm-dd, yyyy-mm-dd - yyyy-mm-dd

Mix:

yyyy-mm-dd - yyyy-mm-dd, yyyy-mm-dd

Now I'm curious about the best way of storing this into a database. Is it possible to store all of this information into one array of dates of some kind / another table. Or should it create multiple instances for each range?

Probably better if I show you what I had in mind for the tables:

If a user (id = 1) wants to offer lifts for 2014-04-01 - 2014-04-06 and also 2014-04-09 - 2014-04-11, the database at the moment will do the following:

  id  userid startDate  EndDate
 ---- ------ ---------- ----------
    1     1  2014-04-01 2014-04-06
    2     1  2014-04-09 2014-04-11

Or should it be something using multiple tables or as an array of many individual dates as opposed to a range?

The reason that it matters is because when someone is searching for someone who has offered lifts, they obviously want to see all of the available lifts from that person sometimes, therefore, should it be displayed as one record if the users submits it as one "offer".

Dates will be produced by json and inserted into database via php->pdo. Database is mysql.

Also note that the table for the request will hold more data than is displayed, but that's only what's necessary here. Main issue is I don't want repeated data everywhere for multiple ranges of dates.

I'm sorry if I haven't explained this well enough, it's quite complicated to get the idea across.

Thanks for your time. Andy.

Answer 1

I can't remember the reason now but when I worked on a trading system, we also had to put the trade positions over time in a similar date structure so that they could be queried easily for reporting purposes. We would have a structure like this:

  id  userid startDate  EndDate
 ---- ------ ---------- ----------
    1     1  2014-04-01 2014-04-06
    2     1  2014-04-06 2014-04-09
    3     1  2014-04-09 2014-04-11
    4     1  2014-04-11 null

I can't remember the exact reason why we did this now but it was something to do with getting all the positional data back quickly and easily.

Answer 2

I agree with IK

To address some of your additional questions:

Or should it be something using multiple tables or as an array of many individual dates as opposed to a range?

It would be a bad idea to store every date in that range. Not only will it fill up your database fast, it requires lots of operations to insert, and is more complex to amend (eg if the user wants to reduce the range).

Regarding 'single dates'. I would still store this as a range. You could null out the end date, as suggested by IK, but i'd rather just have a single day range, eg

id  userid startDate  EndDate
--- ------ ---------- --------
4   1      2014-04-11 2014-04-11

From a coding point of view it's more consistent, and means you don't have to deal with 'special cases' in your code when the end date is null. It also means the null value can be reserved for 'open ended' ranges, if needs be (which is, of course, a special case!).

I'm also assuming you're using a proper date type in the database, rather than storing as a string :)

Answer 3

I can't remember the exact reason why we did this now but it was something to do with getting all the positional data back quickly and easily.

Just to elaborate this a little bit further. You will gain some performance when you denormalize the table and use the "Date" as Datatype, because you avoided at least two joins. But it alway depend on the varoius ciriculumstances, for example if you prefer performance over deduplication and vice versa.