Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] PIW Relationships Modelling

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: "John Schinnerer" <john@eco-living.net>
  • To: "pcplantdb" <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] PIW Relationships Modelling
  • Date: Fri, 22 Jul 2005 05:44:18 -1000 (HST)

Moi,

> I love the idea from an ease of implementation standpoint, but I'm not
> sold on the extra select to reassemble the plant row and lack of
> contraints (anything could be NULL). OTOH, this is really close to
> the loose tagging way of data organization I'm currently in love
> with.

Haven't read the rest of this thread but if there are concerns in terms of
search overhead and how long it will take in real time to return search
results, I have no concerns over 'inefficient' but otherwise attractive
implementations/algorithms at this point or for the considerable future.

We should consider scalability of implementation/algorithms in terms of
data growth (both amount and type or nature of data) for sure.

Our level of traffic\use is not IMO going make slightly or even
significantly 'inefficient' searching an issue, even in several years or
maybe even a decade from now (hardware gets faster too... ;-).

A few seconds' difference in real time is not significant. Fifteen or
thirty seconds is, from an end-user usability standpoint.

Does anyone really think we will be dealing with more than a few
*fractions* of a second at the server-engine itself, based on these
different implementation options?

Seems unlikely to me.
If you want to convince me otherwise, some structured testing will have to
be done to measure actual search-transaction times and show orders of
magnitude of difference early on.

cheers,
John S.



John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net






Archive powered by MHonArc 2.6.24.

Top of Page