Database Enquiry

[gothwalk]

A question for the more technically minded among ye. I'm going to be doing some work on a database of local information for inranelagh.com, and I'm think about how to structure it. At present, I'll want to flag entries in the database with various notes, and also attach tags to them, in the short-established Web2.0 style. Since there'll be an arbitrary number of possible tags for a given entry, and an occasionally changing number of flags, what's the best way to manage this?

Possibilities in my mind is to have one field, "flags", containing a comma separated list of words, and the same for tags. Another possibility is to have a field per flag, and let them be 1 or 0 - although I can't see that working for the tags. And finally, there's the possibility of a table co-relating flags/tags and entries separately.

I might just use tags overall, but I'd like to distinguish between the ones I set (flags) and the ones anyone else sets.

And a separate question - does anyone know how easy it is to get at phpBB's user storage, and if that login could be used elsewhere on the site, for comments, feedback, submissions, and the like?

I'm in an odd place on this; I know the stuff that can be done, I work with it every day, but in many ways, I haven't the slightest idea how to go about it anymore without developer support.

Comments

[sharikkamur.livejournal.com]

No no no no no! :)

Sorry - one field with a comma seperated list or a fixed number of fields for individual flags are really bad ideas. The recommended way of doing this is to have a new table which contains two fields - the primary key for the entry, and the tag. If an entry has four tags it has four records in the new table. If it has forty flags it has forty records in the new table.

Normalisation, that's what it is. :)

[theferrett.livejournal.com]

Heavily seconded.

Also, PhpBB's login functions are pretty easy to access, but PhpBB is fairly insecure. I wouldn't trust it for anything of significance. Then again, I have a hand-rolled login system I use that works fairly well, so it depends on your time.

[mollydot.livejournal.com]

Thirded.

[smarriveurr.livejournal.com]

Er... Fourthed. My DBMS prof would've tanned my hide for it. Relation table good, expandable, easily maintained and understood. CSV field messy messy messy dirty unclean inefficient bad touch. Integer with essentially bit-wise flags is expandable up to a point (ie log2(MaxInt)), but requires more work in the long run to keep clean, and locks you down once you start choosing values, whereas the table can just be cleaned out of whatever's obsolete.

So, yeah, just create new tables for such things. You'll thank yourself later.