🚀 go-pugleaf

In article <4995@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:
|(Hi Alan!)
|
|I'm not at all familiar with the DB architecture of Lotus Notes... however,
|a comment you made in your (very helpful) description of that system begs
|for elabration:
|
|In article <WEX.90Mar19131959@sitting.pws.bull.com> wex@sitting.pws.bull.com (Buckaroo Banzai) writes:
|> - Notes uses a custom, highly-optimized, fully-replicated database to store
|>documents.  Documents are seen through hierarchical views.  Views are
|>predefined for each DB, though users can define "custom views."  {this is
|>their biggest luze, imho.  A replicated DB is a disaster waiting to happen.
|
|Why is a replicated DB a "luze" for such groupware applications? How would
|*you* build a DB to share such information? Would your dream system do
|queries on a remote databases, and have that information come back in
|"realtime"?? What object granularity would you be able to support?

	I think the implication is that concurrent
	reliability and consistency is impossible
	to achieve in replicated DB's. The overhead
	to guarantee update consistency across all
	replications can often equal the overhead of
	direct query. Granted that some compromises
	of "guarantee" can be made to improve performance
	(if everyone understands and agrees to the "gotchas"),
	but this requires careful design, and usually
	later redesign if the interconnections change
	substantially. The bottom line is that if you
	try to imagine patching up a broken DB on one
	machine (always a painful process), you need
	to imagine the much worse problem of reconciling
	inconsistent views on a large distributed
	replicated DB - it ought to give one pause...

|What about situations where notes sites are not connected by fast networks??

	It's true that remote queries can impact
	remote connections severely in some cases -
	the usual solutions are some forms of local
	caching to increase performance, which ends
	up being a special case of replication (sigh),
	with many of the attendant problems...

|Isn't USENET news a slimy form of replicated DB? It seems to work ok...
|though it doesn't really offer very much functionality.

	I wouldn't call UseNet a reliable DB. If that
	level of unreliability (which can be pretty
	poor in terms of consistency and update time
	skew) is acceptable, then "go for it". I
	suspect however that groupware has much more
	stringent requirements in general...


-- 
  ,u,	 Bruce Becker	Toronto, Ontario
a /i/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `\o\-e	 UUCP: ...!uunet!mnetor!becker!bdb
 _< /_	 "Paranoia is its own reward" - W. Disney