Question

i would like to learn from you on designing the database schema:

ie. my problem is 1 activity has 1..* date_held

eg. activity name is

"see movie" has date_held on 1 Sep

"shopping" has date_held on 2 Sep , 5 Sep, 6 Sep

Method1

so my current database design is

---------------------------
Activity Table
---------------------------
id|name|date_held

1|see moive|20120901

2|shopping|20120902

3|shopping|20120905

4|shopping|20120906

You can see that shopping record is duplicated 3 time. I think it seem not good.

Method2

So I divide into 3 table

---------------------------
Activity Table
---------------------------



id|name

1|see moive

2|shopping


---------------------------
Date Table
---------------------------
id|date

1|Sep 1

2|Sep 2

3|Sep 5

4|Sep 6



---------------------------
Activity_Date Table
---------------------------
activity_id|date_id

1|1

2|2

2|3

2|4

But I think method 2 is very confused. Any one can give me a suggestion how to do table design on 1 activity match 1..* date_held?

Thanks!!

Hi Branko Dimitrijevic

after I think a few hour , i discover another method, i.e. use redis json format

{

"name":"shopping",

"date":[

"Sep1"

]

},

{

"name": "see movie",

"date":[

"Sep2","Sep5","Sep6"

]

}

It seem very easier~ 😀

But let me think your suggestion..

Answer 1

You can see that shopping record is duplicated 3 time.

The value of the name field, taken alone, does repeat in different rows. The whole records (i.e. rows) are not repeated.

Logically, if the same activity is repeated on multiple dates, the same piece of data identifying that activity¹ must be repeated for each of these dates. There is no magic and all the relevant combinations must be listed in the database. Fortunately, databases are good at handling huge amounts of data.

I think there are two issues here:

1. Do you need a surrogate key id? If there can never be the same activity on the same date, then the {name, date_held} is a “natural” key, no matter whether you’ll add another “surrogate” key such as id. So unless you actually need the the surrogate PK, you can just leave the natural key as primary. If there can be multiple activities per day, consider replacing date_held with datetime_held.

2. Do you need a third table? If you want to associate more information than just name with each activity, or you want an activity to be able to exist even without ever being held, then you need it at the logical level anyway. But even if you don’t, at the purely physical level, using a surrogate PK in a third table would save you from repeating a string, and instead allow you to repeat the (slimmer) integer. You could potentially save space (and cache performance) with that, but could also require more JOINing. As you see, it’s a matter of balance and measurements can be an invaluable tool for picking the right one.

---

¹ Be it activity name or ID.