* bbackde at googlemail.com <bbackde at googlemail.com> [2007-03-26 08:20:08]:
> On 3/25/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> > wrote: > >* bbackde at googlemail.com <bbackde at googlemail.com> [2007-03-25 > >22:22:45]: > > > >> On 3/25/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> > >> wrote: > >> >* bbackde at googlemail.com <bbackde at googlemail.com> [2007-03-25 > >> >21:01:06]: > >> > > > > >You can't have good performances with that because you are using > >VARCHARs... Btw, what's the point of having both isvalid and > >invalidreason ? can't you assume the boolean is false if the varchar is > >NULL ? msgdatetime ought to be stored on a shorter field, what's > >recipient ? can't "from" "signatures" and other fields like that be > >externalized ? btw, why do you keep the signature if you update the > >field signaturestatus ? > > > >Your database template seems messy to me. I think you should consider > >optimizing it before considering switching to an other provider. > > I don't think its messy. isvalid makes the design clear and is cheap > and works even if no invalidreason is set. I'm not convinced. > VARCHAR is needed to allow variable size subjects and owners. To me, you ought to have a special table for owners and store here their identifier. > msgdatetime is a BIGINT because this is a long! An int is not enough. I agree it's a long in java... but I don't think BIGINT is a long in most RDBMs and I know that they do have a special, optimized type for storing timestamps. > Recipient is the recipient identity of an encrypted message (one of yours). > from/signature is not externalized for performance reasons (I tested both > implementations). huh ? signature, why not, but I see no reason not to externalize from. > And the signature is kept in preparation of new functionality, like > sending others messages with their signature within an message. understood. > > But hey, this is not the problem :) I think an relational DB is > great, I have no performance problems and no DB design problems at > all! > My problem is that the McKoi DB seems to cause problems when the JVM > running Frost crashes. Some users report corrupted databases. Thats > why I look for alternatives! Are we aware that we are facing the same problem with BDB ? Users manage to corrupt their DB and aren't able to recover from it :S > >> >May I ask why do you need count queries for ? > >> > >> e.g. for the statistics dialog. But hsqldb was slow in different areas > >> too, currently I don't remember what areas...but all tests pointed to > >> McKoi. > > > >Hmm, how often is that thingy called ? can't you store/increase a > >counter each time you insert a new message in the DB insteed of > >recomputing every thing ? > > > >I hope this helps. have you seen that part ? NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070326/b20fa504/attachment.pgp>
