Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

Johan Andersson wrote:
>
> no_sp.am_at_agd.nsw.gov.au says...
>
> > Do you have any examples?
> >
> No. My point was that specific databases was not the issue.

	I thought that this is what I've been trying to say,
	irrespective of what others have been claiming?



> >        And increasing concurrency gives you ... ?

        And not increased contention for resources as well?  

> >> The only thing the TPC-C proves is that there exists at least one
> >> application for which RLL / PLL is not an issue. I can see no proof
 whatsoever
> >> for this being true for all 'finely tuned' applications.
> >
> > Do you have any examples where its not the case for a
> > 'finely tuned' application?
> >
> No. My point was that Pablo has no proof of his statement. I have not tried to
> prove my assumptions. Neither have I tried to define or examplify a 'finely
> tuned' application. My point again is that neither has Pablo. He waved the
> TPC-C test as proof, IMHO this is not so, for the above reason.

	You seem to be contradicting yourself here. Above you stated
	that "The only thing the TPC-C proves ..." and immediately above
	you now state "IMHO this is not so". Can you clarify your
	stance? I'm under the impression that only one proof or
	disproof is required.



> >> [.. my description of TPC-C ...]

> >

> >        TPC-C mimics OLTP applications (which is what you've described).

        True. but I don't think its possible for it to mimic all.

> > I don't know of any OLTP applications that are batch jobs. Do you?
> >
> The combination of batch an OLTP is not unexistant, why?

	The implication of batch is that it does not require interaction
	where as OLTP would. A true batch process could not do this
	(realistically), whereas an OLTP process might try and combine
	elements of a batch process with OLTP processing. But then
	would it be batch or OLTP? I don't think it can be called
	batch since it requires interaction. Would it then be just
	OLTP. I'd imagine that it would be designed in such a way
	as to not leave a person interacting with it idle for
	lengthy periods. The only other possiblity I can see is
	having the interaction purely at the start of the process
	(setting up options etc.) and then leaving the process to
	run in a batch-like state. Would this sort of hybrid have
	a different descriptive label?
 


> >> It would be very interesting seeing a test that measured how an RDBMS


> >> performed under the load of transactions of ever increasing complexity.

> >

> >        Do you know of any applications that run with ever increasing

> >        complexity? An OLTP application does essentially the same thing

> >        over and over. Only its data changes.

        OK, I see your point.

> Where
> is your proof that _all_ OLTP applications 'does the same thing over and
> over'?

	I didn't say "all", I said "an". An OLTP application is designed
	to do its task and its task only. True, it may well be more than
	one single specific task. These tasks would be of differing complexity,
	as you note. However, within a single task, I can't see how
	it would ever change the nature of its complexity. That is,
	the task follows the program specification. This may change
	dependant on the conditions (i.e. different conditional tests
	cause different code to be executed), but the overall complexity
	itself can never go beyond the bounds imposed by the code. This
	matches your point about the complexity being user driven. As
	this was your real point, then yes, the complexity can vary
	based on the dataset. In this case, varying the dataset would
	test an RDBS differently, as was your original comment.

> >> We have seen a number of examples in this thread of applications that would
> >> benefit from RLL. My point is that the TPC-C alone is not enough to state
 that
> >> these examples are irrelevant.
> >
> > Which examples whould they be? I haven't seen one concrete example
> > yet that absolutely mandates RLL.
> >
> There have been examples. Whether they 'absolutely mandate RLL' is under
> debate. I have no proof either way. My point is that the TPC-C test alone is
> no proof these examples are false which means I have seen no proof that they
> 'do not mandate RLL' either.

	OK, and my point has been that any application that mandates RLL
	can be modified so as not to require it. I didn't find any of the
	cited examples adequate. I believe I suggested alternatives for
	at least two of them.

-am Received on Fri Dec 05 1997 - 00:00:00 CET