chx:<br><br>Was your basic idea to isolate the more static parts of the database from the more active parts? It strikes me that could be done without SQLite.<br><br><div class="gmail_quote">On Tue, Feb 3, 2009 at 4:32 PM, Sam Tresler <span dir="ltr"><<a href="mailto:sam@treslerdesigns.com">sam@treslerdesigns.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<br>
On Mon, 2009-02-02 at 20:14 -0800, Karoly Negyesi wrote:<br>
> We could say that for<br>
> high performance sites you only change system or the registry when you<br>
> deploy and thus the SQLite file is just one more to be deployed.<br>
<br>
</div>This is not a viable solution for content heavy sites such as newpapers<br>
and radio stations. If I understand it correctly it would involve<br>
pausing the entire content creation staff while development pushed the<br>
new db file live.<br>
<br>
It would also entail having site admins, that might not be<br>
administrators required to either know what was a safe change in a<br>
clustered environment and what wasn't, or attempting to restrict the<br>
access of site-admins in complex ways.<br>
<br>
I'm not shut off to the idea, but I don't see it working well in a<br>
clustered environment.<br>
<font color="#888888"><br>
-Sam Tresler<br>
<br>
<br>
</font></blockquote></div><br>