RE: [U2] Why Buy (or develop in) UniVerse?
Relational theory requires you to abstract the database to fit a (badly flawed) prescriptive theory of what data *should* be like. MV simply models the database to look like the real world. Relational scatters the data about individual real-world items across multiple tables. MV (properly designed) puts it all in one place. That's why MV doesn't need optimisers etc - it doesn't need to guess what data is likely to be accessed as a blob - if data is tightly joined in the real world, it is likely to be tightly joined in an MV database (while it's guaranteed to be scattered everywhere in a relational database). Relational REQUIRES that data comes in two dimensions. MV reflects the real world in accepting data that comes in more than two dimensions. A generic data is n-dimensional theory will ALWAYS be preferable to a data is 2-dimensional theory. I liken that requirement of relational to Euclid's assertion in geometry that parallel lines never meet. Without realising it, he placed an artificial restraint on geometry and held it back centuries. CD have done the same for database theory. Would you use Newtonian mechanics to model events in the LHC? The physicists would laugh you out of Switzerland. As David said, Oracle market to CEOs - relational wins on marketing clout. Unfortunately, the mathematical foundation behind it is iredeemably flawed :-( It breaks the Einsteinian corollory to Occam - make it as simple as possible - but no simpler - relational theory has been simplified too far, with the result that it ends up far more complex than it need be. Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jordan Sent: 13 August 2008 01:18 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Why Buy (or develop in) UniVerse? Hi Louie Intersystems have done some benchmarks of multidimensional databases versus RDBMS and some of that logic follows through to UniVerse. It is difficult to compare UniVerse to RDBMS in benchmarks as they are designed for RDBMS strengths. If a benchmark was designed for UniVerse strengths instead, RDBMS would not look so rosy. RDBMS databases are designed to optimise cache and indexing because of the performance issues in the database. UniVerse does not inherit those performance issues, hence they do not need to optimise Cache and indexs to the same extent and the optimisations needs to be different. There are hosts of differences. RDBMS have fixed length and fixed structure records, where as UniVerse has variable length records and fields can be added at any time. More UniVerse records can fit on a disk sector than RDBMS rows increasing U2 performance. RDBMS don't efficiently lock rows, they do group locks. Universe can lock individual records without performance hits. RDBMS work with optimistic locking as pessimistic locking is a nightmare with group locking. UniVerse can handle both optimistic and pessimistic locking. RDBMS stores all tables within one file, UniVerse has a file for every table. Totally different approaches for BU, Restore and handling file corruptions. RDBMS have to join multiple tables which creates overhead and referential integrity issues. UniVerse stores all specific data in a multidimensional record. UniVerse is close to Zero-Administration, where RDBMS still require expensive Database administrators. RDBMS have large workloads in setting up security access to tables for different users. UniVerse can use table security or OS file security. RDBMS have limited functionality in business rules stored in the database. UniVerse can handle complex business rules with ease. In complex applications UniVerse is well ahead. However the argument should not be technical. The CEO and board does not make decisions on Cache and indexes, they make it on a business case. ROI, Cost of running, Staff numbers to administer and develop, competitive advantage. The old joke was what hardware does Oracle run best on, a projector. Oracle markets to CEOs and does little technology discussion, that is why they are successful. Its horses for courses, but if a project is going to be complex, the success rate of the project completing on time and on cost in UniVerse is near 100%, on an RDBMS the numbers are scary. Regards David Jordan Managing Consultant --- 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/
RE: [U2] Why Buy (or develop in) UniVerse?
David As always, that is a great post. Hit the nail on the head. I think part of the problem is we continue to call UniVerse a database. It isn't - it's an application platform that happens to have a complex storage model behind it. When you compare *application* performance against the three tier models required for effective RDBMS backed apps, the numbers will stack up very differently. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why Buy (or develop in) UniVerse?
To add to my post: If you want one single good reason, take a look at the Wrox Press Expert One to One series books by Roger Jennings on database programming. He's a SQL Server and .Net guru. Read his chapters on performance tuning and concurrency management and weep for those guys. And if that doesn't convince, I'd really recommend a good book on using the Oracle query optimiser to get performance out of that... Then you'll know why so few RDMBS projects deliver robusness on time and on budget. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Why Buy (or develop in) UniVerse?
These questions have come up so many times I'm almost sick of hearing it. I really wish that IBM would get off their duff and get some of these questions answered. I just wonder why they don't run the tests against the other databases. If their afraid to run them against DB2 for fear that their shinning star can be beat then don't do it against it, but at least they could run the tests against their competitors. And don't tell me that it's like testing apples and oranges because we all know that we can build either U2 product to act like an SQL database. If you do find that U2 is not up to other relational databases in their world then try using it natively. Jerry -- From: Louie Bergsagel [EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 6:08 PM To: u2-users@listserver.u2ug.org Subject: [U2] Why Buy (or develop in) UniVerse? Has anyone compiled any reasons for buying or developing in UniVerse vs. Oracle or some other relational database? I keep hearing things like: - UniVerse doesn't cache like a relational db - UniVerse doesn't use indexes properly - UniVerse selects aren't as fast as a relational db and I don't know what to reply. I've googled Multivalue vs. Oracle and found a bunch of complaints that UniVerse doesn't manage data or security like some people think it should. I have a friend who said that sometimes he just wished someone would tell him what to do. He would probably not like UniVerse. I found one white paper on IBM: ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/202452.pdf It would be nice to see hard data like: - Universe vs. Oracle speed benchmarks such as - time to select a 4 million record file. - time to update 4 million records. - time to LIST 4 million records. - UniVerse vs. Oracle tables per (Order Entry, for instance) app - number of UniVerse programmers to support a $100m sales company vs. Oracle - Cost of a UniVerse system vs. Oracle. Oracle here is generic for any relational data base management system, I suppose, including DB2. -- Louie in Seattle --- 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/
RE: [U2] Why Buy (or develop in) UniVerse?
David, Don't forget to invoice IBM when they use this! ;) Regards, Ray (presently in Japan,therefore missing U2 University) - Original Message - From: David Jordan [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Subject: RE: [U2] Why Buy (or develop in) UniVerse? Date: Wed, 13 Aug 2008 10:18:21 +1000 Hi Louie Intersystems have done some benchmarks of multidimensional databases versus RDBMS and some of that logic follows through to UniVerse. It is difficult to compare UniVerse to RDBMS in benchmarks as they are designed for RDBMS strengths. If a benchmark was designed for UniVerse strengths instead, RDBMS would not look so rosy. RDBMS databases are designed to optimise cache and indexing because of the performance issues in the database. UniVerse does not inherit those performance issues, hence they do not need to optimise Cache and indexs to the same extent and the optimisations needs to be different. There are hosts of differences. RDBMS have fixed length and fixed structure records, where as UniVerse has variable length records and fields can be added at any time. More UniVerse records can fit on a disk sector than RDBMS rows increasing U2 performance. RDBMS don't efficiently lock rows, they do group locks. Universe can lock individual records without performance hits. RDBMS work with optimistic locking as pessimistic locking is a nightmare with group locking. UniVerse can handle both optimistic and pessimistic locking. RDBMS stores all tables within one file, UniVerse has a file for every table. Totally different approaches for BU, Restore and handling file corruptions. RDBMS have to join multiple tables which creates overhead and referential integrity issues. UniVerse stores all specific data in a multidimensional record. UniVerse is close to Zero-Administration, where RDBMS still require expensive Database administrators. RDBMS have large workloads in setting up security access to tables for different users. UniVerse can use table security or OS file security. RDBMS have limited functionality in business rules stored in the database. UniVerse can handle complex business rules with ease. In complex applications UniVerse is well ahead. However the argument should not be technical. The CEO and board does not make decisions on Cache and indexes, they make it on a business case. ROI, Cost of running, Staff numbers to administer and develop, competitive advantage. The old joke was what hardware does Oracle run best on, a projector. Oracle markets to CEOs and does little technology discussion, that is why they are successful. Its horses for courses, but if a project is going to be complex, the success rate of the project completing on time and on cost in UniVerse is near 100%, on an RDBMS the numbers are scary. Regards David Jordan Managing Consultant --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
