Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] A VERY IMPORTANT MESSAGE

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Sean Maley <semaley@yahoo.com>
  • To: sgerson@stanfordalumni.org, pcplantdb@lists.ibiblio.org
  • Cc:
  • Subject: Re: [pcplantdb] A VERY IMPORTANT MESSAGE
  • Date: Mon, 14 Feb 2005 14:33:18 -0800 (PST)


Thank you Stephanie.

Is there anything specific you have found to be most
useful? It looks like there is some inertia being
experienced right now, which I hope I haven't caused
by introducing new ideas. Heide appears to be a
source of scope creep too. Going beyond plants
specifically. How can you have a system about guilds
with only plants?

Along these lines, user scenarios are very important.
The usage patterns will drive the interface design,
which in turn drives the design of the back end
package. That leads to why I am so interested in some
of the PIW listserv discussion. The problems will
come as the data set grows. Looking through the eden
package, I'm seeing lots of searching through strings,
known as in-string searches. Done against every table
in a default search, there will be enough trouble
distributing such a load. When you add concurrent
modification of this data, I'm not sure we have that
sort of hardware/software to handle it.

MySQL isn't known for it's transaction control. Where
I thought searches would be the extent of database
work and minimal modifications would ever be
performed, MySQL was the tool. However, this won't be
possible attempting to accommodate a general search
(OLAP) user base concurrently with a data entry (OLTP)
user base.

Perhaps a data entry delay would be considered in user
scenarios. This gives a chance to shovel the data
into the database without search engine disturbance.
There could also be a data model addition to index
words found in the database, as an alternative to
in-string searches (edible LIKE '%tasty%'). This
takes up lots of disk, but prevents us from going into
our main set of data via the in-string, thus
increasing concurrency and allowing transactional
control at the DB level. I believe google does
something like this.

MySQL also doesn't give much control over disk usage
either. Would it make sense to keep it in the back of
our minds that we have no set tool for storing the
data? At least not until we settle what the user
community looks like and run some numbers against our
hardware. How many searches are happening now? How
much disk/CPU/network does this generate? What can we
expect in terms of usage when we go live? Who else
operates on our host? Am I crazy to bother with
performance questions?


-Sean.

--- Stephanie Gerson <sgerson@stanfordalumni.org>
wrote:

> Thank you.
>
> To everyone contributing to this project, whether
> you're a newcomer or a
> veteran. I truly appreciate the recent discussions
> - all the time and
> thought that goes into your posts (can't help it
> folks, gotta single out
> Sean Maley here). It's a pleasure collaborating
> with you all, and I look
> forward to more.
>
> *sigh*
>
> This was my VERY IMPORTANT message.
>
> peace
> *Stephanie
>
>
>
> +++++++++++++++
> Stephanie Gerson
> sgerson@stanfordalumni.org
> (c) 415.871.5683
>
>
>
____________________________________________________________________
>
>
> _______________________________________________
> pcplantdb mailing list
> pcplantdb@lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/pcplantdb
>


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com




Archive powered by MHonArc 2.6.24.

Top of Page