Very true and I agree that the DB Server (SQL, et al) and the DB client engine (UV) models each have pros and cons.
UV is a lightweight DB and application engine with some very good capabilities in the DB and application area. Plus of course some truly powerful features too! It is not the best or worse in any of these fields. It fills its own little niche very nicely. UV has had some truly good native SQL engine abilities (schemas, tables, triggers, integrity constraints, stored procedures, dynamic normalisation of multi-valued fields, etc) for a long time. Not tacked on like the UD counterparts. But next to no one uses them. As they would break your legacy application. Plus if you created a new application/DB using it - you may as well use a read SQL database server! Some of the nifty features of true SQL DB servers are really to "work around" the "limitations" of the relational model and how you store your data (requiring complex joins, queries, etc). Which tends to make those nifty features essential. Whereas SQL DB servers are progress in leaps and bounds in many different and diverse ways and this is where they truly diverge - be it to cater for massive databases or distributed or failover-active/active database clusters, etc., of any data type or structure you could imagine. Whereas the U2 database engine has not really progressed or evolved much at all in reality - that is not a bad thing. Adding various extensions to the traditional PICK/U2 application interfaces is a very good thing. It does add lots of functions that are truly useful - requiring minimal effort and zero install or cost (a key requirement for lots of sites). If you need something better AND you have local talent to build/maintain it (or consultancy budget) - then go again and do it. :) There are many examples of organisations using their own interfaces/extensions - because they can afford something better that works for them. Your mileage and budgetary will vary! Hence, as you imply - use each database - exploiting their inherent strengths. Use the right tool for the right job. Every tool has its sweet spot! ;) I won't mention the number of MS Access "databases" out there doing "real work"...groan! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Symeon Breen Sent: Thursday, 4 October 2012 5:56 PM To: 'U2 Users List' Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... "The Word"... the word is... "MiddleWare". As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 <> .NET client <web service> Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources available for getting help and solving problems. So these days I get MV to push a query or data payload out to a middle-tier that uses the latest communications methods available. The request goes out, the response comes back, it all just works - that That should be our bottom line here. HTH T > From: Ben Souther > We use a middle layer written in Java. > Jeff Schasny wrote: > > I know we have both the SOAP and RESTful web services development for > > publishing web services from Universe but how are folks consuming > > other peoples web services into the database? Are there tools for this > > or am I going to just open a socket, read, and parse 'till I'm blue in the face? _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
