[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Houston, we have a problem...
- To: linuxkb-list@seul.org
- Subject: Re: Houston, we have a problem...
- From: Jason Pincin <chardros@linuxkb.org>
- Date: Mon, 3 Jan 2000 19:37:30 -0500
- Delivery-Date: Mon, 03 Jan 2000 19:44:55 -0500
- In-Reply-To: <Pine.LNX.4.10.9912302023190.9158-100000@vodka.linuxkb.org>; from Aaron Turner on Thu, Dec 30, 1999 at 08:50:32PM -0800
- References: <19991230183827.B26576@jupiter.ash.com> <Pine.LNX.4.10.9912302023190.9158-100000@vodka.linuxkb.org>
- Reply-To: linuxkb-list@seul.org
- Sender: owner-linuxkb-list@seul.org
> I know you've got big plans later on for the KB engine, but I think we
> need to worry about the KB first and bigger plans later. We need to worry
> about the needs of our environment right now and that of other uses later
> on (like after go live ;-)
I COMPLETELY understand what you're saying here, and I understand your concerns for me
thinking future as well as present when designing the KB frame work. It's a good way to
get ahead of myself and slow things down.
But you need'nt worry. I'm running out of time to get all this done... I'm under some
pressure from our sponsers as well, and am doing things by judging "time to
readiness"/"How I think it should be done"/"functionality" ratios. The way it is
implimented now servers many things very well, and I have sunk a great deal of time into
a multitude of functions and inter-operating pices that rely on the present structure.
To change it now would cost more valuble time in which we would simply be re-engineering
- not approaching our goal. The results of the re-engineering, to me, don't warrant the
lost time.
I suggest we roll with what we have, and let me propose a way to work around the
re-organization problem with our current solution rather than re-engineering the backend
to better suit re-orgaization.
> What does "assessig the impat on the DB" mean? What impact? The DB
> performance? Editing your PHP objects?
Well yeah... every change we make to the backend or php objects is going to produce
different loads on the DB. I understand we can always add more hardware, but if we can
keep the DB in line with some intelligent methods of accessing data, why not?
> Anyways, I don't wan't this issue to delay our go live in Jan, but I think
> we need to address this issue before we get too much content in the DB or
> we're going to end up making our lives harder later on.
Well, lemme know what you think of the above. I'll be on-line all day tomorrow.
--
Jason
http://vodka.linuxkb.org/~chardros