I do agree that it can help with benchmarks to lock into some "givens"
and go from there, but even choosing something as common as SOAP gets
you into the SOAP vs REST discussion (e.g.
http://www.oreillynet.com/pub/wlg/3005).  I can imagine doing
benchmarks where you say "given these technologies, what else works
well with them" but would prefer to also have benchmarks that leave
more open.

Starting with user requirements and measuring a full range of quality
requirements, including various performance and scalability measures
would keep those technology wars out of the testing.  It is the fact
that SQL, an industry standard, is tightly coupled to industry
benchmarks that we are even having this discussion.  How can you get
to something better if you lock into a specific technology or approach
when doing benchmarks?

That said, at this point in time we could at least do tests with
TCP/IP as a given, I suspect, then tests with http, and then with SOAP
and REST and all such information would be helpful.

The other thing I found was that most of the really good benchmark
testing is done by large companies in their R&D areas.  I would guess
that companies like IBM really do know the various performance and
scalability comparisons among their own products and likely those of
competitors too. If they do not, then large database users have done
such testing. That information doesn't leak out so easily, however.
--dawn


On 7/17/07, Nick Cipollina <[EMAIL PROTECTED]> wrote:
On one hand, if the purpose of exposing this data is for internal
consumption only, then some sort of proprietary format would be
perfectly acceptable.  In fact, we are using a sort of proprietary
format for communication.  The problem with this approach is that when
you begin dealing with outside organizations, your proprietary way of
communicating is no longer that clever.  This is when using a standard
protocol, such as SOAP, really has value.

To me, this is part of the problem that we have in the MV world.  We
look at how things are being done elsewhere and say, "Pick does it
better, we aren't going to do that."  The problem with this approach is
that everyone else is adopting these standards and using them.  We are
going to be left further behind if we don't start using some of the
technologies available to us.

On an unrelated note, we interviewed a .Net developer that worked for a
company that also had a UniData shop in house.  He was telling us about
this custom interface they used in communcations.  He didn't know
anything about it's origins, except that you had variable length records
delimited by "funny" looking characters.  I asked him if the characters
were ASCII 253, 254 and 255 characters, and he said in fact that he
thought they were.  The moral of the story, not really sure, I just
thought it was kind of funny.

Thanks,

Nick Cipollina
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dawn Wolthuis
Sent: Monday, July 16, 2007 11:22 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData 7.1 vs. MS SQL 2005 performance

I do understand the advantages to that approach, Nick. But that was
also the thinking of those who prepared the current industry
benchmarks by locking in on SQL.  My concern was that if you specify
technologies, you can make it difficult for solutions that are outside
the box.  --dawn

On 7/16/07, Nick Cipollina <[EMAIL PROTECTED]> wrote:
> If the consumer of this data is going to be external, then I would
> definitely use web services.  Using a standard format (SOAP) will make
> it possible for anyone to consume the data.
>
> Thanks,
>
> Nick Cipollina
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dawn Wolthuis
> Sent: Monday, July 16, 2007 4:58 PM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] UniData 7.1 vs. MS SQL 2005 performance
>
> Yes, agreed. I think if you start with user requirements for services,
> then have folks design for those requirements according to each
> environment, that would be a good start.  I hesitate to say that it
> must be "web services" only because that might imply use of SOAP or an
> XML exchange that could prejudice the implementation, but otherwise
> defining the requirements as services makes a lot of sense. Each
> service implementation in different environments can then be judged
> and compared by a variety of measures.
<snip>
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure, or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to