Joachim Draeger wrote:
Hi Stefano,
Am Freitag, den 30.06.2006, 13:23 +0200 schrieb Stefano Bagnara:
1) flag: are flags dynamic? I understand from your document that we need
to store the flag types in a table so that their ID can be used. Is it
needed or the flag types are statically defined in the RFC?
I was reading RFC again carefully about this topic. Handling
many-to-many relationships might have some drawbacks. In fact the
predefined system flags like \Seen and \Answered can't be extended, so
we could store them either using a binary combination or one boolean
column per flag.
Well, I still don't like storing externally defined constants, like
OR-ing flags to an int value. But it might have the highest performance
and could be quite easy to handle. What do you think?
+1 for boolean flags. I expect more serious performance bottlenecks
elsewhere ;-)
in the RFC the flags are string constants and have no ID attached to
them. so the implementation can choose whether or not it assigns IDs to
them.
Allowing user defined flags, that are called keywords in the RFC, is an
additional feature. (Currently milestone 5 of the roadmap draft.) IMO
the best approach would be a one-to-many relationship here.
Table name: "keyword"
message_id integer the message this keyword is assigned to
name varchar name of the keyword
primary key (message_id,name)
Maybe it is not so good having a string in the primary key. In this case
we could add an auto-increment primary and a unique index for
(message_id,name).
as far as I can tell, having string-based PKs is ok.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
