The point of the SUV analogy was that many purchases such as Oracle and other software and hardware are made according to the "Law of the Sheep": everyone else is doing it so it must be the right way to go.
Regarding security, which is the antithesis of shared data, one should not be surprised to find complications expanding. Just as "combination locks" are put on doors and passwords and security levels are put on data the overhead increases. Patrick "Will" Williams, President American Computer Technics, Inc. 919-567-0042 Raleigh, NC ----- Original Message ----- From: Jeff Flynt To: [EMAIL PROTECTED] Sent: Monday, May 17, 2004 11:23 PM Subject: RE: [U2] Cost of Oracle vs PICK Please forgive me for playing the devil's advocate here, but if you want to use vehicle analogies you might as well be comparing a VW Beetle to a 747 jet. One may get better gas mileage, cost more, go higher,... So what? Don't get me wrong. I love our Pick database model, but in the modern usage of the word "database" our database model is at best very "light." I would hazard to say it is really a file base or a record base. For as flexible as it is, it still lacks in many ways that can be taken for granted in other database models. As for companies going "belly up" when converting, well, to me that is a reflection of the design of the original database, not how the data is stored. A complex, convoluted multivalue style database may be a tough nut to crack. Multivalued data can be corrupt. It can be dirty. It may have "evolved" in some as hoc manner that defies common sense. Or the underlying structure of the data may not directly correspond to some new relational based application's perspective of data. These problems would affect any conversion from any database to any other. I would think it is a lot easier to go from a relational perspective to a multivalued one simply because relational data is simpler. But it isn't as elegant. Any stories of the converse of this topic? If the Pick model provided the same "uniform" level of security that standard relational databases do then the rest of the world might look at it differently. Truth be told, I want a black box database. I do not care how the grand designers implemented the internal structures, i.e., records composed of delimited strings, hashed files... If I have to know that then I have to know to much. Knowing it may have its advantages. Hacking the data being one of them, i.e., with the editor. Every single Pick style app I have used requires application level security. So if the app has no bugs, and you can never leave the app, you're good to go. Personally, I have never seen either of these cases with a Pick app. In this modern day who really cares how many bits a piece of data requires? Bits are cheap! Have two! Is the relational database slower? You can bet on that! But it is also doing a lot more. More work requires more time! Even if the internal structures are very inefficient the hardware today can help compensate. But I somehow don't think the Oracles, IBMs and Microsofts are building them that way. The slowness comes from the overhead of being a proper database or from poorly planned databases and queries. If the multivalued model had the same (security, integrity, etc.) overhead it would be slower as well. If the multivalued database is poorly planned it also would be slower than a well planned version. Universe's and Unidata's native languages are woefully out of date. If someone came up with an object oriented version of the languages then app level security could be a lot tighter at least. Recent apps I have worked with have records of people who are alive and hundreds of years old! They are fraught with dangling references to non existent records. Sure, it's a data entry error or an app error, and it could happen on other databases/app. But other databases can constrain that data so it never happens either. That is why they are slower. They maintain the integrity - not the application. Multivalued style databases do not require integrity and do not provide for it. That is a function of the application. That is a serious weakness, and all the multivalued applications I have dealt with but the very simplest do it poorly. Also, the app level security is worthless for third party solutions that have no awareness of the app's security model. If the multivalued platforms incorporated modern security, a better native language(s), built in integrity, constraints, and other features that can be taken for granted in other world class databases then the throngs (probably) would not be abandoning ship. Unidata (or Universe, maybe every Pick type) can not pass a rigorous security audit. If you work with privileged information you need a better platform. One VAR is moving this direction. It's future releases are flattening out all the files (i.e., sql'izing them) and moving toward database independence. When your VAR is leaving the technology what do you do? You have two ways to ride the wave. Migrate to something more modern or salvage multivalue by updating the features mentioned above. Ellhay, while we're at it let's put a mathematical foundation on it. I am certain it could be done. But when you have statements like the one below from a Gartner Group review how will you "ride the wave?" I personally would love to salvage multivalue... ------------------------------------ This is off the Gartner Group's web site: http://www.gartner.com/ (search for Datatel and include archives) Datatel in Higher Education 2002 2 April 2002 Pages: 5 Vendors Although Datatel's full-function product suite and a seasoned management team have attracted loyal customers among small and midsize institutions, it must replace outdated technologies and provide a SQL Server offering. ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users
