Calendar Event Tags

Alright /prog/ - Working on a site for a client. Currently we have an event system up so that the owner (and eventually customers) can easily add events to the calendar for customers to see online. It is set up pretty simply with each event being an entry in a MySQL table currently set up like this:

id
filename (for images)
date
time
timeEnd
eventName
description
host
hostID
ip


--
That said, I was talking to the owner last night and she would like it so she could add tags to the events so that when people look at the calendar, they can filter it to see only relevant content.

Honestly, I don't see the reason for it as I doubt there are ever going to be that many simultaneous events. That said, I don't think I'm going to be able to convince her otherwise.

Right now I'm considering using a second table for each tag and linking it to the event ID. Then simply grab all the event ID's with a given tag when rendering the calendar. Any other thoughts on how I should implement this best? (I've never worked with creating a tagging system before)

I'm sure that you'll have to use joins, but I've no idea how to use them.

>>2
Prelude> :t Control.Monad.join
Control.Monad.join :: (Monad m) => m (m a) -> m a

Tagging is an archetypical many-to-many relationship (there are subtleties if you care about performance, but you don't.) Representing this in a relational database is a well-understood problem.
Why do people try to design databases without any sort of formal training whatsoever, as if it was some sort of menial work? Is reading an introductory book too hard?

>>3
I tried writing a clever post where I defined both :: (a -> b) -> (a, a) -> (b, b) using join like I saw in a post on /prog/, but I failed.

>>4

OP here - I understand that - the main point of my original post was figuring out the best (or at least a good, normalized database) way to implement this system.

As of right now, I'm considering:

+------------+--------+----------+--------+
| Events     | Tags   | EventTag | Groups |
+------------+--------+----------+--------+
|id          |id      |tagID     | id     |
|filename    |groupID |eventID   | name   |
|date        |name    +----------+--------+
|time        +--------+
|timeEnd     |
|eventName   |
|description |
|host        |
|hostID      |
|ip          |
+------------+

Where Tags.group will allow them to create categories/groups of tags if they needed to. Am I over-simplifying? Am I making it too complicated?

>>6
That is indeed The Way To Do It with tables in a standard SQL database. (Someone will likely offer you some bullshit about using natural keys, but meh.)
As long as it is expressive enough for your use cases I don't see a problem with it.

>>7
(Someone will likely offer you some bullshit about using natural keys, but meh.)
There is no way to use natural keys when normalising an M-to-N relationship.
This thread is all kinds of sad. Even very bad colleges teach this sort of thing in their first semester.

``Database theory'' is rocket science created with the purpose of selling books.

OP here again.

>>8

Interesting - I'm a designer and a hobby programmer. All my training is in the arts, not in database theory. It would be sad if I were in college for programming, but indeed I'm not. I think I'm actually not doing too bad for a designer.

>>7
Yeah, and well, basically the combination of tagID and eventID make a psudo-natural key (you're not going to see more than one of the same combination).

>>9
I'd believe it.

>>10
Buy any book on SQL or get it from the library and read it cover to cover. There is no easy way to good database design, and it will save you and your so-called ``clients'' a fuckton of trouble in the long run.

>>11

They originally hired me for design and nothing more, then wanted me to do the coding rather than hiring someone else. Just because programming isn't my specialty doesn't make them any less my clients. Man I swear /prog/ is full pretentious fucktards.

>>12
Just because programming isn't my specialty doesn't make them any less my clients. Man I swear /prog/ is full pretentious fucktards.
Your insecurities are causing you to read more into >>11 than was there. I suppose that's good; too many people are cheerfully unashamed of their lack of ability.

>>12
Hey look, my father is doctor, do you mind if I diagnose your next illness instead? After all, why bother going to a real doctor if I can do just as well?

This thread is seriously dangerous to my mental health.

>>13
Indeed, I probably was reading into it a bit much.

>>14
If I paid you money for it (that is, diagnosing my next illness), you'd gladly take it. Likewise, I'm getting paid for this, even though I'm not a programmer, and my client knows it. Ya know what I mean?

>>15
If I paid you money for it (that is, diagnosing my next illness), you'd gladly take it.
Are you assuming everyone is as unethical as you are?

>>16

Ethics? She's paying me a hobby programmer's paycheck for a hobby programmer's job. She knows my abilities, and they are more than qualified for this job.

>>17
and they are more than qualified for this job.
Your opinion of your own worth is biased. It is plain from reading this thread that you aren't qualified to write this websight, post on this board, or even to program Hello World in Common Lisp(tm). For the good of your employer, you should step back now and let a real man do the job.

>>17
I knew it was your mother! Don't worry, mine asked me to do something similar too. I quickly scrapped SQL and changed to a filesystem database.

>>12
Your first post was not clear -- is the event system already in place, and you are adding tag support to it? Or you are creating this whole thing in >>6 from scratch? Are you attempting to write a CMS to manage these events, or just providing the database and some code to query it?

Lol women

24 Name: Anonymous 2011-02-04 14:02

Don't change these.

Name:		Email:
Entire Thread Thread List

All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -