 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / April 2004Oracle and PICK
It's been claimed in this forum that there's no empirical data to compare TCO between Oracle and PICK. Oracle has a larger market share than PICK. That's empirical evidence. I would never claim that it's conclusive evidence. But it is evidence. And I can't believe it's unrelated to TCO. Depends on what the CLIENT thinks is TCO, Total Cost Of Ownership, right? Not the Database company....If as a Vendor I only need 10 developers to maintain and enhance an application that licenses for 250K while my Oracle competitor needs 100 to maintain enhance his/hers, and sells his/hers for 1 Mill, then TCO to the CLIENT is definitely lower with mine. That is the difference between Pick and Oracle, real world solutions to verticals are the ONLY real measurement Many, too many, years ago, I added a paragraph to my stand up sales routine just for the 'xpurt' IT weenies, "How can you describe a three dimensional 'any' thing in a two dimensional database?" Just a thought... Oracle, by the way, is great for your consulting bank account. If that's what turns you on. Most 'pickies' do not consider that, we only think of our verticals and the satisfaction we get from being the "best available application of computer technology to a problem". I do not put Oracle in IBM's class, so the fact that IBM has an outstanding RDBMS competitor to Oracle in DB2 and STILL went after the MV Market by purchasing the U2 companies just might indicate something to a client. Best, Nick and Dawn :-) > It's been claimed in this forum that there's no empirical data to compare > TCO between Oracle and PICK. [quoted text clipped - 3 lines] > I would never claim that it's conclusive evidence. But it is evidence. And > I can't believe it's unrelated to TCO. A sales routine. How come I didn't recognize it sooner! Yup 24 year old app sold 3 in 2002 for 1.7mil, guess what, still green screen telnet,,,and 7,650 fields (columns for you newbies) Please, answer the question, sir n. > A sales routine. How come I didn't recognize it sooner! > Many, too many, years ago, I added a paragraph to my stand up sales routine > just for the 'xpurt' IT weenies, > > "How can you describe a three dimensional 'any' thing in a two dimensional > database?" What, pray tell, is a "two dimensional database"? Look at this simple table definition: create table three_dimensional_point( x int, y int, z int ); How many dimensions does that table have? Schema for the table please? Thanks, Nick > > Many, too many, years ago, I added a paragraph to my stand up sales routine > > just for the 'xpurt' IT weenies, [quoted text clipped - 8 lines] > > How many dimensions does that table have? You really are a sales (or marketing) guy!!!! Wow. Tony gave you: create table three_dimensional_point( x int, y int, z int ); and then you ask for the schema. Nice. > Schema for the table please? > [quoted text clipped - 18 lines] > > > > How many dimensions does that table have? Who cares wether arguments come from a religious/dogmatic perspective, a marketing perspective or ignorance, as long as they are on-topic and put forward in a respectful way. Please don't top-post. http://www.xs4all.nl/~hanb/documents/quotingguide.html Centuries ago, Nostradamus foresaw when mAsterdam <mAsterdam@vrijdag.org> would write: > Who cares wether arguments come from a religious/dogmatic perspective, > a marketing perspective or ignorance, as long as they are on-topic and > put forward in a respectful way. Please don't top-post. > http://www.xs4all.nl/~hanb/documents/quotingguide.html Personally, I'm in the "against stupidity" camp. I think it's pretty stupid when one person presents a schema, such as create table 3d_foo (x integer, y integer, z integer); And then someone else asks "So, what's the schema?" The schema was, of course, create table 3d_foo (x integer, y integer, z integer); Someone that isn't sharp enough to notice that is more than likely not sharp enough that they should be visiting comp.databases.theory, and claiming much of anything about any would-be difference between Oracle and Pick. Like, "duh, the schema was create table 3d_foo (x integer, y integer, z integer);"  Signature(reverse (concatenate 'string "gro.gultn" "@" "enworbbc")) http://www.ntlug.org/~cbbrowne/x.html "... They are not ``end users'' until someone presupposes them as such, as witless cattle." -- <craig@onshore.com> Excuse please, was looking for the column elements of the three dimensional array with associated multiple instances of a column defined as in CREATE TABLE contract ( ContractNo VARCHAR(16) NULL, ContractYear VARCHAR(16) NULL, ContractVersion VARCHAR(3) NULL, Co VARCHAR(16) NULL, MasterKey VARCHAR(24) NULL, Brkr VARCHAR(16) NULL, BrkrDesc VARCHAR(120) NULL, Cedant VARCHAR(16) NULL, ) CREATE UNIQUE INDEX ContractId ON contract ( Co, ContractNo, ContractYear, ContractVersion ) > Centuries ago, Nostradamus foresaw when mAsterdam <mAsterdam@vrijdag.org> would write: > > Who cares wether arguments come from a religious/dogmatic perspective, [quoted text clipped - 19 lines] > Like, "duh, the schema was create table 3d_foo (x integer, y integer, > z integer);" > Excuse please, was looking for the column elements of the three dimensional > array with associated multiple instances of a column defined as in [quoted text clipped - 11 lines] > CREATE UNIQUE INDEX ContractId ON contract > ( Co, ContractNo, ContractYear, ContractVersion ) What is the difference, apart from the fact that my CREATE TABLE statement was on a single line and I omitted to define the obvious key? Does this make it better for you? :- CREATE TABLE three_dimensional_point ( x int, y int, z int, PRIMARY KEY (x, y, z) ); > Personally, I'm in the "against stupidity" camp. According to my Zen friend, without stupidity, intelligence would not exist. > Schema for the table please? Please explain what you mean - I already gave you a CREATE TABLE statement. What more do you need? Ok, Define an Order Header and the Order Items in that table, please. I.E. The deader has Number Customer Customer address Customer Phone Order date Total Order Cost The Items have Item number Product Number Product Price There may be more than one 'item' for any order... > > Schema for the table please? > > Please explain what you mean - I already gave you a CREATE TABLE > statement. What more do you need? > Ok, > > Define an Order Header and the Order Items in that table, please. You know that I know that you know that I would now provide you with 2 create table statements. And I know that you know that I know that you would then say that was a Bad Thing. Etc. etc. etc. All we need then is for Wol to come along and claim that now I have mysteriously "scattered" the 2 entities Order and Order Line across 2 separate tables, there is no way the DBMS can put them together again! Perhaps it's best that I just don't bother ;-) > > Ok, > > [quoted text clipped - 9 lines] > > Perhaps it's best that I just don't bother ;-) I believe that we're part of an involuntary beta-test of the next AI "Eliza"-style software, simulating discussion of database topics. Say, I wonder what they use as a data store on the back end? I'm guessing XML files, which accounts for the arbitrary nesting of concepts. - erk >> Ok, >> [quoted text clipped - 9 lines] > >Perhaps it's best that I just don't bother ;-) Actually, I wouldn't. I would just ask "how many items of information do you need to access data in the table? The answer is two - row-key and column-name - therefore the table is two-dimensional. Oh - and the question was "how do you describe a three-dimensional thing". So you chose to represent a point. I'm not sure how many dimensions that has but it ain't three! Nor is it two because that's a line. I suspect it's zero-dimensional. Hm! You need two dimensions to represent a zero-dimensional object! By my maths that makes you need infinity dimensions in order to represent three! :-) Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > >> Ok, > >> [quoted text clipped - 22 lines] > my maths that makes you need infinity dimensions in order to represent > three! :-) Cute, if perhaps getting a little tiresome ;-) > Schema for the table please? What do you mean with schema beside the table? What would be a relevant PICK 'schema'? Please don't top-post. http://www.xs4all.nl/~hanb/documents/quotingguide.html > Schema for the table please? > > Thanks, > > Nick Here you go: ******************************** *** BEGINNING OF SCHEMA ***** ******************************** HERE IT COMES... <SCHEMA> create table three_dimensional_point( x int, y int, z int ); </SCHEMA> ********************************** ******* END OF SCHEMA ********** ********************************** </end of posting> For completeness, you left something out, which was caught by my thumbing-nose parser <start of posting> > > Schema for the table please? > > [quoted text clipped - 19 lines] > > </end of posting> Not being from an SQL planet, to my (very) untrained eye I'd say that this was still a 2 dimensional table, with 1 row per record and 3 columns for integer data points, though I'm happy to concede that my English reading may be incorrect. The term I've normally seen attributed to "Pick" (or multi-valued) files/tables, is that they can implement a nested table, with repeated column values "nested" within the structure. A real world example would be an invoice, comprising a header (who we sold to, invoice # etc) and multiple lines (the actual products sold, values etc). Just like a "real" invoice form, the "Pick" model would allow you to create/model this structure in a single file, which in theory should result in better performance, as a single I/O operation would return both the header & line details (the lines may have further nested tables [values] to record details like actual serial or batch numbers sent, warehouse locations picked from etc, but I'll simplify it) My (limited) understanding of Oracle (excluding i series lines for the moment) is that there would be a requirement for a "header" table, and a "lines" table (with a foreign key to the header file) as a minimum. You COULD implement this same "flat/2 dimensional" structure with the Pick Data model if you wanted to, just as, say, Oracle 10i (I believe) allows you to create a nested table structure that more closely mimics the "Pick" multi-dimensional/nested table structure. (I don't want to get involved in a holy war as to which way is "right", as the answer will obviously vary with the platform, and also the problem at hand there is rarely a black & white answer to any non-trivial task) The main difference is that whilst this "nested table" approach is (relatively) new to the Oracle (SQL) fraternity, it has been one of the hallmarks of the multi-valued databases since inception (along with the fact that all fields can be arbitrarily "large" in a Pick structure a memo field if you will and also "small", which is reflected in the size of a record on disk, and also in RAM) As Dawn has mentioned, the propagation of "relatively" unstructured information in the form of XML sits "easily" within the Pick data model, and I would therefore assume that the "I" series logic will feature in Oracles native support of XML. (Note: that Raining Data, the successor to the original "Pick Systems" that commercialized the work of Dan Nielson & Dick Pick and brought the pick system to market, already have a native XML data store built on the Pick Data Model. The product is called "TigerLogic" see www.rainingdata.com for details) Anyway, I'm just trying to put oil on the water so that I can get a better/more accurate understanding of both sides of the argument (As a sideline, how many here are old enough to recall the problems that the "relational" database had in displacing rigid Cobol/CODASYL thinking in the 70's change is never easy) > > Many, too many, years ago, I added a paragraph to my stand up sales routine > > just for the 'xpurt' IT weenies, [quoted text clipped - 8 lines] > > How many dimensions does that table have? The point is, IMO, that you can project a three dimensional relation (or, maybe a third order relation) onto a two dimensional space (rows, columns) without loss. If it weren't for the capacity of two dimensional tables to capture and retrieve data that might be three dimensional or beyond, a star schema would be impossible. In other words, the table has only two dimensions, but the relation is of order 3, and therefore can list a (finite) set of points in a three dimensional space. Mathematical relations are not limited to finite cardinality, but I'm putting that limitation on the relations in the relational data model. Now that I think of it, is this a legitimate limitiation or not? Your thoughts. Clear as mud? > The point is, IMO, that you can project a three dimensional relation (or, > maybe a third order relation) onto a two dimensional space (rows, columns) > without loss. Obviously, and the pattern can be repeated for n-dimensions, allowing n-dimensional datasets to be represented using . The discussion then descends into the physical implementation, which in turn impacts performance in the real world, as you can also represent n-dimensions with flat files ! > If it weren't for the capacity of two dimensional tables to capture and > retrieve data that might be three dimensional or beyond, a star schema > would be impossible. Or is it that a star schema is NECESSARY in order to represent n-dimensions using just 2 dimensions ? > In other words, the table has only two dimensions, but the relation is of > order 3, and therefore can list a (finite) set of points in a three > dimensional space. > Mathematical relations are not limited to finite cardinality, but I'm > putting that limitation on the relations in the relational data model. Now > that I think of it, is this a legitimate limitiation or not? Your > thoughts. In real terms the set of points is obviously finite, simply because of physical storage & representation limits, but the set of points could obviously be "arbitrarily large" > Clear as mud? > Or is it that a star schema is NECESSARY in order to represent > n-dimensions using just 2 dimensions ? Good point! >The point is, IMO, that you can project a three dimensional relation (or, >maybe a third order relation) onto a two dimensional space (rows, columns) [quoted text clipped - 12 lines] >that I think of it, is this a legitimate limitiation or not? Your >thoughts. Rephrase that. "Is it a *necessary* limitation?". If you don't *need* to apply the restriction, then your solution space is a subset of the available solution space and must, by definition, be incomplete. You'll probably rephrase me again :-) but to rephrase myself in physics terms - "are you applying a cosmological constant?" - a cosmological constant being "some number we can't explain that just happens to be the fudge factor we need to make things add up". Think of the recent proof of Fermat's Last Theorem. The proof was all the more elegant because it didn't even prove Fermat directly - the guy just said "oh, if you pick this particular case, it just happens to be Fermat's Theorem". Actually, I'm not at all sure I've picked up your primary point - you were talking about "finite" cardinality and I've picked up on "two-dimensional projection". But my comments about "legitimate" and "necessary" still stand ... >Clear as mud? Probably :-) Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > Not being from an SQL planet, to my (very) untrained eye I'd say that > this was still a 2 dimensional table, with 1 row per record and 3 > columns for integer data points, though I'm happy to concede that my > English reading may be incorrect. You are confusing the table with the 2-dimensional printout of the table's contents. You may as well say that both SQL tables and Pick table/files are 1-dimensional, because physically the data is all strung out as a linear sequence of bits on the disk. > The term I've normally seen attributed to "Pick" (or multi-valued) > files/tables, is that they can implement a nested table, with repeated > column values "nested" within the structure. True. And many SQL databases (such as Oracle) now allow the same thing - unfortunately! In my experience, this new nested table capability is taken up enthusiastically by novices who (a) know no better, and (b) are positively encouraged to do so by books and training courses; people who really understand what they are doing (e.g. Oracle's guru Tom Kyte and, ahem, me ;-)) have nothing to do with them. This isn't Ludditism, it is wisdom. > A real world example would be an invoice, comprising a header (who we > sold to, invoice # etc) and multiple lines (the actual products sold, [quoted text clipped - 6 lines] > tables [values] to record details like actual serial or batch numbers > sent, warehouse locations picked from etc, but I'll simplify it) This is logical/physical confusion. The fact that invoice headers and lines logically reside in 2 separate tables does not mean that they may not physically reside together on disk for performance reasons. Oracle, for example, allows 2 or more tables to be physically "clustered" together by key values. > > Not being from an SQL planet, to my (very) untrained eye I'd say that > > this was still a 2 dimensional table, with 1 row per record and 3 [quoted text clipped - 5 lines] > table/files are 1-dimensional, because physically the data is all > strung out as a linear sequence of bits on the disk. I thought I was referring to how the DBMS treated the data - did this table simply have 3 columns proporting to represent a 3 dimension co-ordinate, or not ? Lacking a common technical background I was hoping to "grok" what you had proposed, which did NOT appear to correspond to a 3 dimensional data structure to me. Also, I'd suggest that in both cases the data is PHYSICALLY stored 3 dimensionally on the disk .... but please, let not go there :-) > > The term I've normally seen attributed to "Pick" (or multi-valued) > > files/tables, is that they can implement a nested table, with repeated [quoted text clipped - 7 lines] > (e.g. Oracle's guru Tom Kyte and, ahem, me ;-)) have nothing to do > with them. This isn't Ludditism, it is wisdom. Wisdom ? It is a wise man who knows he is wise ! I'm not aware of the rationale for the development of the "i" series, but I can only assume it is meant to bolster some deficiency, real or imagined, within the product itself. Could it be that the "people who really understand" are aware of problems in that product when it comes to the implementation ? or shotcomings in the tools & query capabilities ? Or is there a mathematical foundation to back up this belief ? The only serious work that I'm aware of that has been done on n-dimensional grammars was done by Ming Yue in the 1980's .. but it's a subject I haven't researched for some time, and no doubt there have been advances in this area. > > A real world example would be an invoice, comprising a header (who we > > sold to, invoice # etc) and multiple lines (the actual products sold, [quoted text clipped - 12 lines] > Oracle, for example, allows 2 or more tables to be physically > "clustered" together by key values. OK, given that this thread includes "Oracle" in the topic, it is reasonable to look at the physical implementation capabilities of that product just as I concluded that a single database I/O operation would be more efficient than multiple I/O's. (I'm assuming that with Oracle "clustering" the tables would still need to be "logically" joined to retrieve all of the Lines related to the header ?) In the context of the overall TCO question, it might be "enlightening" to see if we could actually do a real world benchmark of the speed/performance of "clustered" data sets in Oracle with a "multi-valued" data structure with Pick . Surely we have the technology available to look at real facts & figures ? Yes, let's go there. A set of flat surfaces is not a 3 dimensional space. Disk data is stored 2 dimensionally. When 3-d storage is built, it will be as different from disks as disks were from tape. However, I would like to know if the Oracle nested table I series, as does Pick, stores the data 'flat' as does tape, with hex characters determining the multiple value 'count' as in ORDER_SEQ <1,1> ORDER_SEQ <1,2> ORDER_SEQ <1,3> etc ORDER_PROD <1,1> ORDER_PROD <1,2> ORDER_PROD <1,3> etc This would lead to efficiency in reading an ORDER from disk but would impact on the SQL necessary to do anything with it. Oracle's SQL, as does all SQL, suffers from the inefficiency of parsing the SQL and creating the temporary files necessary when trying to do complex Updates/Queries. Roger Sippl ran into the same problems in 1984 when he developed the specifications for the INNER and OUTER JOINS during a project I was involved with as a VAR, I developed and installed the first 'application' done with his new INFORMIX PERFORM/ACEGO GL. I suggest that the learning necessary to actually 'use' the new nested relationships' SQL, which will be in all mainstream RDBMS products in order to define the multi dimensional world, will be extensive. PICK uses a 3GL programming language in order to overcome such a limitation on implementation. TCO would still apply ONLY to a Client's perception of the Annual Cost to license and maintain an application, IMHO Nick > Yes, let's go there. > [quoted text clipped - 4 lines] > When 3-d storage is built, it will be as different from disks as disks were > from tape. I'm wrong again. Just as a (finite) set of surfaces does not make a 3-d space, so likewise a (finite) set of tracks does not make a 2-d space. Disk data is really stored in 1 dimension, but the geometry is such that random access is acheived by jumping over data, rather than by winding by it. Man, You are now talking about a subject I've been musing over for nearly 30 years (hmm, too many fingers, maybe only 25 :-) Where would you like to take the thread ? My musings have mainly dealt with halographic/laser tecniques. Even using a fixed reference beam, the permutations of a moveable interference beam (even without the "enhancement" of multiple lasers [wavelengths - much like an RGB gun]) give an "interesting" result, though I also recognise that most of the recent work has been done along the lines of quantum state "memory" Nah, way to OT Do we really need to consider the physical representation of the abstract data model (am I saying this - must have been something I drunk) ? I believe that access speed (as we currently know/measure it) will become largely irrelevant - you can see this starting to happen with the price of solid state drives dropping, and the amount of RAM increasing at the current rate. Obviously (?) the "tape drive" (offline storage media) of the not too distant future (OK, NOW for a lot of people) is going to be the disk drive of today. That being the case, "speed differences" between various implementations will become less important, which in turn may alleviate some of the obstacles/objections people have had in implementing a "real", 100% compliant RDBMS (Star Schema & all, as the "cost" is then reduced) Anyway, I'm now sitting down for my "real job", so I have to kill (or at least retard) the musing algorithm! > Yes, let's go there. > [quoted text clipped - 4 lines] > When 3-d storage is built, it will be as different from disks as disks were > from tape. I'd like to see what you get from the world of biology. If a sunflower can have Fibonnacci numbers embedded in the spirals of the seeds, anything is possible. Does DNA store messages in a real 3-d encoding? Or is it just a long tape, coiled up? The human brain is more compact than it would be if the network were less rich. Maybe networking as the brain does can teach us something about making use of 3-d space for storage. > I'd like to see what you get from the world of biology. If a sunflower can > have Fibonnacci numbers embedded in the spirals of the seeds, anything is > possible. I remember when the first BIO-memory research was published ..... gave a whole new meaning to a "K" of memory (K=Kilogram for those not using metric [USA]) > Does DNA store messages in a real 3-d encoding? Or is it just a long tape, > coiled up? Tape > The human brain is more compact than it would be if the network were less > rich. Maybe networking as the brain does can teach us something about > making use of 3-d space for storage. Current thinking is that the brain doesn't work with "binary" style representation, but rather "shades of grey" > This is logical/physical confusion. The fact that invoice headers and > lines logically reside in 2 separate tables does not mean that they > may not physically reside together on disk for performance reasons. > Oracle, for example, allows 2 or more tables to be physically > "clustered" together by key values. I think you missed something here. Within Pick it is possible to have the all header and all detail lines reside in the same physical record on disk! Now I'm not saying that this is a smart idea all the time. But in many instances it can be a good idea. Then one single record is read from the database and containing most to all the information required. One situation, that comes to mind, may be an invoice structure. The invoice information, billing, ship-to, and all order lines containing, part numbers, quantity for each part, cost at invoice time, retail amount billed at invoice time etc. Read such a record and most of the required information is already read. There is no need to look up into a invoice-line number table to retrieve all the invoice line information. In Pick all that may be left to do is to look into the parts inventory table to retrieve a description. Heck, even the description at the time if invoicing may want to be saved just in case the powers that be insist on recreating the invoice exactly at some later date. Doing such thing in the proper way can may Pick extremely fast, and minimize that amount of disk space required to house all the data. Gee, when disk space was expensive, and a 100 megabyte hard drive was considered large, I converted a company from a relational (not Oracle) database accounting system to a Pick accounting system. The company could not hold a full month of data on the hard drive, but after conversion to the Pick accounting system I installed, the company had close to have the hard drive left for new data. In this company's case, the TCO for the relational accounting system would have required extra hardware to be added to the cost to compete with a Pick solution. Regards, Dale > > ross@stamina.com.au (Ross Ferris) wrote in message > news:<26f6cd63.0404170656.72605341@posting.google.com>... [quoted text clipped - 7 lines] > I think you missed something here. Within Pick it is possible to have the > all header and all detail lines reside in the same physical record on disk! Not at all. My point was that in Oracle (for example), you can have the header and all its detail lines reside in the same physical record on disk too! That is what clustering is for. > > > ross@stamina.com.au (Ross Ferris) wrote in message > > news:<26f6cd63.0404170656.72605341@posting.google.com>... [quoted text clipped - 11 lines] > the header and all its detail lines reside in the same physical record > on disk too! That is what clustering is for. Tony, I'm back for some education and I hope that you or others may help. I have searched on the web regarding Oracle's clustering as it pertains to data records, and only found a few things that confused me. (that aint too hard ;^) ) Does the clustering actual put header and detail information into the same physical record on disk, or does it offer a way of automatically linking the header and detail line items so that in when you ask for the header record the detail lines get read at the same time? Or is clustering have something to do with the indexing and arrangement of detail lines on the disk? I have worked with Pick for some 20 years and know the power of the way Pick handles multi-values. I have worked with dbase like databases in the past and found that the relational rules etc handy, but too many cross-reference tables were required, as compared to Pick, to allow a good size database to work. Best regards, Dale > I'm back for some education and I hope that you or others may help. > [quoted text clipped - 4 lines] > Does the clustering actual put header and detail information into the same > physical record on disk Yes. From Tom Kyte's _expert one-on-one Oracle_: "Clustered tables give you the ability to physically 'pre-join' data together. You use clusters to store related data from many tables on the same database block. Clusters can help read intensive operations that always join data together or access related sets of data." A database block is one or a few disk sectors (i.e. the unit of a physical disk read operation), whatever is most efficient for the hardware/OS combination. > > I'm back for some education and I hope that you or others may help. > > [quoted text clipped - 15 lines] > disk read operation), whatever is most efficient for the hardware/OS > combination. Thanks for the update :7) Having a better name for the technology helps in doing the research. I might get back to you with some more questions. Dale >The invoice information, billing, ship-to, and all order lines containing, >part numbers, quantity for each part, cost at invoice time, retail amount [quoted text clipped - 5 lines] >may want to be saved just in case the powers that be insist on recreating >the invoice exactly at some later date. Actually, the "description at the time" should be stored somehow (maybe make the lookup-table entries immutable) otherwise you can't recreate a copy of the invoice. Actually, that sort of mistake is something I would suspect was more typical of a novice relational analyst, not a Pick one. You're making me question that :-) Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > It's been claimed in this forum that there's no empirical data to compare > TCO between Oracle and PICK. Just comparing TCOs is only meaningful if the two would supply the same service. They don't. Otherwise we might just as well compare the TCO between Oracle and Access or Oracle and DBM files. -- Jan Hidders You are right. But the point was raised that there was no data tocompare with, and there is. Of course, there is a great deal more to market share than TCO. But it's relevant. I'll grant that number of copies of database software licensed per year is a measure of something. I doubt it is TCO, however. Given that PICK doesn't market directly, but to value added resellers does put it in a different category from a product perspective than Oracle. --dawn > You are right. > > But the point was raised that there was no data tocompare with, and there > is. Of course, there is a great deal more to market share than TCO. But > it's relevant. > I'll grant that number of copies of database software licensed per year is a > measure of something. I doubt it is TCO, however. Given that PICK doesn't > market directly, but to value added resellers does put it in a different > category from a product perspective than Oracle. --dawn TCO is only relevant as a comparison parameter if the different products serve a purpose in the same realm (niche?). What would be a typical PICK-based environment? You mentioned PICK-a-likes being embedded in products for vertical markets and the no-need for DBA specialists, but I wonder about things like # of users, developers, development method, modelcomplexity and data sharing between different applications. I know you responded to 'market share', but I would appreciate some remarks on these. Imagine for a moment that you head up an IT department of, say, 100 people, and the company is looking at 2 alternative solutions. The feature set of both products is similar, performance is similar, even pricing is comparable. As head of IT, your COO and CFO ask you for a technical appraisal of both solutions. You look under the hood and discover that Option 1 has the potential to reduce IT staff numbers to 10% of there current level ! That's right, your department will shrink from 100 to 10 over the next 18 months by all accounts, as there are similar sized comapnies using this application with much smaller IT staff numbers. Option 2 on the other hand will guarantee that the current staffing level of 100 will remain over the next 2 years, and indeed may need to be increased with a few additional DBA's. Now, YOU have to report back to the CFO & COO --> do YOU do the honourable thing & fall on your sword and have Option 1 installed, or do you look out for NUMBER 1, and install Option 2 ... and be honest to yourself here ..... Yes, TCO is relevant, but while ever there are empires at stake, people will man the battlements and strive to save the empire - and don't feel too bad, it's human nature ! -------------------------- If you look @ TCO for an installed solution, obviously there are certain TCO elements that would remain constant. If you have a site with, say, 500 PC workstations deployed across the country running Win2K & XP, then the infrastructure & support costs with ANY solution will be more or less constant (OK, so Nick would deploy "green screens" rather than PC's, so users will not stuff up windows, there will be less time lost with "futzing", and fewer moving parts so one would assume less failures --> but lets discount that Nick !) So, to simplify the calculation, lets assume we are dealing with a centralized server running some *nix variant (or Windows if you prefer!) The calculations should be fairly straight forward - we are dealing only with cost of acquisition of hardware & software [not applications - I've already pegged those as constant for this example, but if Nick is able to sell a solution at 1/4 the price of an Oracle based solution, that obviously WILL have an impact on acquisition costs !], ongoing maintenance (including care & feeding of the DB environment). For the sake of this exercise, maybe consider a "hypothetical" application of reasonable complexity that contains around 1,000 tables. Should we add in development costs for, say, making enhancements to the base system on an annual basis, as this is also an important aspect of TCO ? For the sake of my example, could we assume we are extending the base system "somehow" (each year) by adding, say, 24 additional tables (2 a month may be excessive) with 10-20 fields each, enhancing 50 existing screen based processes, creating a similar number of new screens, and likewise amending & creating 50 reports. Would anyone care to give REAL/INDICATIVE staffing for either side of the equation ? and hardware size & maintenance costs for database (once more, lets assume application maintenance is constant .... sorry Nick!) - assuming a user load of around, say, 200, to keep life simple Rather than emotive half truths, we should be able to get some form of quantification here ..... trim your hardware to the bone, be honest with yourself, and lets see some hard facts guys ! > You are right. > > But the point was raised that there was no data tocompare with, and there > is. Of course, there is a great deal more to market share than TCO. But > it's relevant. > Imagine for a moment that you head up an IT department of, say, 100 > people, and the company is looking at 2 alternative solutions. [quoted text clipped - 62 lines] > (once more, lets assume application maintenance is constant .... sorry > Nick!) - assuming a user load of around, say, 200, to keep life simple Hi Ross. You do make good points, but evolving business requirements and the adaptability/flexibility of the system seem to pose as great in not greater influences to TCO. A good example of why PICK might actually have orders of magnitude higher TCO in cases where applications share data or need to integrate can be found right in the comp.databases.pick newsgoup under the subject line, "Why meaningful Item ID's suck." Pick is so bound by its physical organization, that changes to logical identifiers across a set of conceptually related items leaves it open to no other choice but to entirely redesign an entire system. In the case of the thread mentioned, the work was estimated to take nearly two years. Note that Dawn, in her concern for TCO, recommends to the OP, "Best wishes and make 'em pay". I'd recommend reading the whole thread to anyone who is interested. This makes as good ancedoctal evidence anything else. I'm refraining from posting a URL to the referenced thread because it might be unacceptable to those netizen police out there that find excessively long URLs in newsgroups are impolite. Regards, Dan > Rather than emotive half truths, we should be able to get some form of > quantification here ..... trim your hardware to the bone, be honest [quoted text clipped - 5 lines] > > is. Of course, there is a great deal more to market share than TCO. But > > it's relevant. <snip> > Hi Ross. > [quoted text clipped - 12 lines] > make 'em pay". I'd recommend reading the whole thread to anyone who is > interested. That quote didn't sound like me, but I'll believe I wrote that ONLY because it sounded like a (poor) SOLUTION rather than the problem statement was given to the experts. It sounded to me and to others as if there were some very common "design patterns" that would typically be employed to handle the situation at hand and yet the customer picked something that really was not at all a good solution from the information we had. I likely suggested that the consultant on the case advise the customer of the relative costs of various possible solutions and if they still pick a non-sensical and expensive solution, well, then make 'em pay ('cause that was their choice). I sound wicked in your quote here, and I'm a fair bit gentler than that (except when, well, nevermind), so I had to chime in. Cheers! --dawn <snip> > <snip> > > Hi Ross. [quoted text clipped - 27 lines] > various possible solutions and if they still pick a non-sensical and > expensive solution, well, then make 'em pay ('cause that was their choice). Yes, and the same thing can happen with poor design methodology in any type of system, including relational. > I sound wicked in your quote here, and I'm a fair bit gentler than that > (except when, well, nevermind), so I had to chime in. Cheers! --dawn Dawn, The quote was out of context, but it highlighted a point I wanted to make. Since the system couldn't adapt to changes in terms of logical and physical independence, people began blaming the owners, requirements, and designers of the system. I wasn't trying to make you sound wicked, and out of context, that is probably how it comes off. That is why I recommend that the entire thread be reviewed, in context, in order to be fair to everyone. Warm regards, - Dan > <snip> Hi Dan ! I've read the thread, though my conclusions are somewhat different - I'd suggest the topic should perhaps be "Bad database design sucks - with ANY DBMS !" I also note that the application itself appears to be quite ancient, so the methodologies that were used at that time were probably sub-optimal by ANY standard :-) Actually, given the age of the application, this could be a classic TCO study, if we could find an "Oracle" (or other relational) solution somewhere from the same vintage to do a direct cost comparison. Do you want to pose the question to CDP Dan ? Are there enough "Oracle" people here to get a corresponding reference point, or would the request need to go directly to that group as well ? Given we are talking historical figures from 15-20 years ago, I would think that the client companies may not mind "anonamously" making real (or close approximation) figures available .... perfect opportunity to get some quantifiable facts & figures on where TCO figures do stand over the long term ! > Hi Ross. > [quoted text clipped - 22 lines] > > Dan > Hi Dan ! > > I've read the thread, though my conclusions are somewhat different - > I'd suggest the topic should perhaps be "Bad database design sucks - > with ANY DBMS !" I can see where these conclusions are born out of the discussion. But the thread started with a real-world problem driven by the fact that the company had merged with another company. It therefore had to incorporate and map a new set of logical identifiers, over history. The problem wasn't necessarily the mapping between logical identifiers themselves, but with the deletorious effects it would have on each and every application, report, etc. that relied on the original internal data model. An RDBMS solution was proposed (see first response to the poster) that, IMO, would have overcome this problem easily. > I also note that the application itself appears to be quite ancient, > so the methodologies that were used at that time were probably > sub-optimal by ANY standard :-) Granted, and perhaps that is a sufficient reason that would pose problems for a relational dbms as well. To me, the overriding problem in the conceptual problem space seemed to be a problem that is relatively common in the real world was posing great difficulties for PICK. But perhaps you are right and it has nothing to do with the fact that any data access path or index path is hard-coded into tightly bound applications. > Actually, given the age of the application, this could be a classic > TCO study, if we could find an "Oracle" (or other relational) solution > somewhere from the same vintage to do a direct cost comparison. I agree wholeheartedly. Dawn asked for recommendations in the past to determine a set of criteria for a head-to-head test. This particular type of scenario is exactly what I had in mind, if it is indeed possible to come up with an objective comparison. > Do you want to pose the question to CDP Dan ? Are there enough > "Oracle" people here to get a corresponding reference point, or would [quoted text clipped - 3 lines] > think that the client companies may not mind "anonamously" making real > (or close approximation) figures available .... I'm not so sure this would work. > get some quantifiable facts & figures on where TCO figures do stand > over the long term ! Yes. This seems like an excellent opportunity if someone was really willing to dedicate themselves to the research, or was going to be paid for it. However, it is a lot of work and I doubt if anyone really has the time and inclination to do this on a volunteer basis. It would also be interesting to find out how many companies, owners, or users felt that using either an MV system or a relational system contributed to a stifling of business innovation or process by virtue of the rigidity of their core information systems. We could call it the innovation/competitiveness impedence cost. It is a phenomena I've seen with local IMS systems here. > > Hi Ross. > > [quoted text clipped - 22 lines] > > > > Dan >> "Dan" <guntermannxxx@verizon.com> wrote in message >news:<2Zhgc.5856$Aq.1415@nwrddc03.gnilink.net>... [quoted text clipped - 15 lines] >proposed (see first response to the poster) that, IMO, would have overcome >this problem easily. Actually, iirc, it was NOT a specifically RDBMS solution. The same could/should have been done in Pick, with equal ease. I like relational theory :-) (strange as that may seem). It makes my use of Pick even MORE efficient :-) It's just that Pick doesn't constrain what I *can* do, but I *choose* to let relational constrain what I *should* do. The result is a well-designed and very efficient system. Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 Fascinating! The ironic thing is that the discussion of rewriting history by retroactively altering key values would play itself out the same way if the data were in an Oracle database, rather than a PICK file. If it's a wise thing to do, then it's a wise thing to do in both environments. If it's a foolish thing to do, then it's a foolish thing to do, then it's a foolish thing to do in both environments. Wise or foolish, Oracle makes it easy to do. I'm of the opinion that it's a foolish thing to do. And I have no doubt that, if the decision to do that comes back to bite them, the decision makers won't take the blame. They'll find a propellerhead to take the fall faster that Enron executives began blaming the accountants. Then they'll update their resumes so that can continue their careers over at the Ministry of Truth. Dan: >"Dan" <guntermannxxx@verizon.com> wrote in message [snipped] > You do make good points, but evolving business requirements and the > adaptability/flexibility of the system seem to pose as great in not greater [quoted text clipped - 10 lines] > make 'em pay". I'd recommend reading the whole thread to anyone who is > interested. The record key in a pick-like dbms is the primary key. Always. Sometimes meaningful data is stored there (such as a Vendor's invoice#) because it is unique. Sometimes a simple counter is used and all meaningful data is stored in the record. Your observation of the referenced c.d.p thread stumbled across an ongoing discussion in the pick-like community - documentation and structure. Unlike other RDBMS products, pick-like applications control the dbms, not the other way around. I always look at an RDBMS like the students in a religious school: uniforms, clean, sitting up straight, saying "yes sir/mam", doing the work quietly, etc. I see a pick-like dbms as a public high school, where everyone wears different clothes, draws grafitti on the lockers, smokes out back by the auto shop, talks in class, etc. In order to learn, the student _must_ provide the structure to succeed. The same is true in a pick-like environment; the application developer must provide the structure. All the same tools are there, as they are in an RDBMS, but they just aren't required by the database. Because of this, developers do stupid things, like those discussed in that c.d.p. thread. A pick-like development environment is much different in that the developer is assumed to know something (a lot actually) about the application being written, the toolsets being used, the network topography delivering stuff, and the users doing their jobs. One may like or dislike this. But it explains a lot. Bill > Dan: > [quoted text clipped - 38 lines] > true in a pick-like environment; the application developer must provide the > structure. I'll agree with you on everything you've said. You mentioned in another post that Pick-like application systems are a very good value for certain kinds of applications, sets of requirements, and environments, and I actually believe that -- especially those that last 15 to 20 years with little major upheaval. But those very same strengths could work against pick-like DBMS's in other circumstances, while RDBMS's might shine. I think we can agree to agree here. - Dan All the same tools are there, as they are in an RDBMS, but they > just aren't required by the database. > [quoted text clipped - 7 lines] > > Bill > Dan: > > >"Dan" <guntermannxxx@verizon.com> wrote in message > > [snipped] <snip> Unlike other RDBMS products, pick-like applications control the dbms, not > the other way around. I always look at an RDBMS like the students in a > religious school: uniforms, clean, sitting up straight, saying "yes > sir/mam", doing the work quietly, etc. I see a pick-like dbms as a public > high school, where everyone wears different clothes, draws grafitti on the > lockers, smokes out back by the auto shop, talks in class, etc. Very good -- made me smile. However, I would add that this shows up one of the RDBMS mindsets -- there is an implied power hierarchy with the DBA's (teachers) protecting the database (society) from the application software developers (students). With PICK, as with old indexed sequential file systems (VSAM,ISAM) the developer can botch up a lot of things, but I've never seen an RDBMS (or DBMS) environment where the app developer couldn't do that anyway. A software developer sometimes thinks like the following: "constraints that I, personally, cannot remove are obstacles in my path and I have to figure out how to work around them". Working around obstacles is what an application software developer needs to do all throughout the development process -- they are good at it. In shops or people where there is not a sense that the application software developer has "power" to make their own path in altering constraints, they work around them, sometimes coming up with really clever work-arounds (and that is NOT what we want, right?). Give software developers freedom and they will take responsibility. --dawn >Unlike other RDBMS products, pick-like applications control the dbms, not >the other way around. I always look at an RDBMS like the students in a [quoted text clipped - 6 lines] >structure. All the same tools are there, as they are in an RDBMS, but they >just aren't required by the database. Okay, this is now the UK so my terminology may be strange, but a *good* comprehensive (your public high) will ALWAYS get better top results than a grammar school, while a *bad* comprehensive will get worse results than a secondary modern (a school for grammar school rejects - that's unfair but that's what they were perceived as). In other words, sticking with the analogy, I'd say a good Pick shop will outperform a good Oracle shop. But a crap Oracle shop will outperform a crap Pick shop - the restrictions of Oracle hamper both the genius in his search of perfection and the idiot in his search for crap :-) Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > In other words, sticking with the analogy, I'd say a good Pick shop will > outperform a good Oracle shop. But a crap Oracle shop will outperform a > crap Pick shop - the restrictions of Oracle hamper both the genius in > his search of perfection and the idiot in his search for crap :-) That's ocersimplification. There are problems for which PICK is the better tool and there are problems for which Oracle is the better tool. The best shops are the ones that choose the right tool for the job. >You do make good points, but evolving business requirements and the >adaptability/flexibility of the system seem to pose as great in not greater [quoted text clipped - 10 lines] >make 'em pay". I'd recommend reading the whole thread to anyone who is >interested. But, as is pointed out, this whole thing comes down to poor design. >This makes as good ancedoctal evidence anything else. And, as is pointed out, this SAME MISTAKE is extremely common in SAP - which is a relational system. Poor design ALWAYS bites you. Pick is no better or worse than relational. Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > >You do make good points, but evolving business requirements and the > >adaptability/flexibility of the system seem to pose as great in not greater [quoted text clipped - 12 lines] > > But, as is pointed out, this whole thing comes down to poor design. This is what I call jumping to conclusions. The design sufficed for over 15 years. > >This makes as good ancedoctal evidence anything else. > > And, as is pointed out, this SAME MISTAKE is extremely common in SAP - > which is a relational system. SAP uses underlying SQL databases, but never in a relational sense. In fact, most ERP systems basically nullify the total benefits of relational databases, partially because of the various DBMS vendors inability to keep propietary physical properties of a data model separate from the logical aspects, and partly because ERP systems have to generalize to an extent that accomodate most primary specializations of a business, but never all of them. Thus, many datamanagement functions are hand-coded rather than enforced by a database. I imagine direct ad-hoc access is absolutely *verboten." It would be even more exacerbated with PICK, but the comparison is merely a matter of relativity. Unfortunately, PICK supporters argue for arguments sake here in this group. Most support is in the form of "I heard a story that.." or "I believe that so and so", or "I have this opinion, so it must be true", or "I'm a scientist, so I'll bring up topics that have no relevance to data management or database theory." If you believe you have a case, then either develop and publish a case study, or offer to compete a PICK product against the TCP benchmarks, which are very well known, and though not perfectly objective, serve the best place for you to prove your case in terms of competitiveness against current relational implementations. > Poor design ALWAYS bites you. Pick is no better or worse than > relational. Perhaps that is the case if I were conviced that this particular instance was a case of poor design, but I'm not. One of the benefits of the relational theory is that it provides a basis and outline for good design (e.g. normalization). I have yet to see an analog with the same rigorous foundations with PICK. Perhaps you could point them out. And if you want to argue that normalization is harmful, then I would love to see a peer reviewed article in ACM's SIGMOD telling everyone why they are loony for having been convinced of its benefits for all these years. I'm sure a formal argument and proof should be a trivial task for one of your scientific stature. Because there is a natural tendency for businesses to change, driving natural growth and change in the universe of discourse, leading to growth and change in data structures, one should not then call a system bad design because it has no consistent mechanism to isolate users from underlying physical structure. None of us know what the future will hold except that it brings changes. Relational offers some degree of immunity from this as a model, PICK does not, except for where hacks were built upon the implementation over the years, such as the dictionary, to give it some isolation. By hack, I mean that it was not part of a comprehensive framework for a database and there is little evidence that any PICK implementation will serve the purpose in a consistent and predictable way. Let's get back to interesting aspects of database theory here, OK? Regards, Dan > Cheers, > Wol >Unfortunately, PICK supporters argue for arguments sake here in this group. >Most support is in the form of "I heard a story that.." or "I believe that [quoted text clipped - 5 lines] >serve the best place for you to prove your case in terms of competitiveness >against current relational implementations. If I'm correct, one of the biggest complaints of the non-relational world about TCP is that it *assumes* that the underlying database is relational. How can we fairly compare different database models, if the benchmark assumes one of those models? If we make Pick pretend to be a relational database, then any benchmarketing comparison must, by its very nature, be flawed. I think Pickies would like an unbiased study, but the last time I mentioned a study, the reaction was not exactly favourable... Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > >You do make good points, but evolving business requirements and the > >adaptability/flexibility of the system seem to pose as great in not greater [quoted text clipped - 12 lines] > > But, as is pointed out, this whole thing comes down to poor design. Let's make this premise: "If a pick application is poorly designed, then it will break and have to be redesigned." Let's assign A to the proposition "the pick application is/was poorly designed." Let's assign B to the proposition "the pick application breaks." Let's assign C to the proposition "the pick application needs to be redesigned." So, we get If A, then B ^ C. Now, in the thread, the following were posited: The pick application is broken and it will have to be redesigned. We then get the following argument, without even considering whether the premises are true or not: A->(B ^ C) B C Therefore A. I realize you have a preference for inductive reasoning, but perhaps you can find and point out why this argument form is invalid using rules of inference (i.e. modus pollens)? Regards, Dan Jan, PS, Now that I see where Dawn and Nick are really coming from, I'm starting to lose interest, fast. > Jan, > PS, Now that I see where Dawn and Nick are really coming from, I'm > starting to lose interest, fast. Golly gee, what does THAT mean? I'm coming from trying to figure out why relational theory is taught and marketed big time when my way-too-many-years of practice have given me the impression (not the proof) that other approaches work better. I'm really on a search for why this difference exists -- between what I have learned from books and seem with my eyes -- I'm still learning, so when I get to preachin' instead, feel free to call me on it.. I'm also a future-thinker and it seems to me that RDBMS's will need to change significantly if they don't want to lose that king-of-the-hill position. It was quite amusing to me to see that the XML model looked like the old PICK products I'm accustomed to -- makes me think that perhaps theory and practice might actually come to the same conclusion once we have a better theory. smiles. --dawn > [...] I'm coming from trying to figure out why > relational theory is taught and marketed big time when my way-too-many-years > of practice have given me the impression (not the proof) that other > approaches work better. As far as teaching theory goes, the answer is quite simple. It is because we have a formal description of the relational model that it is possible to do develop theory around it. And because it is based on other theories with a long pedigree such as set theory and logic we can re-use the already known results of those fields. So there is a big corpus of theory concerning all kinds of issues such as complexity theory, query optimization, concurrency theory, logical deduction, constraint checking, et cetera, that can be taught. I haven't seen such a formal description for Pick, and in fact most of its proponents I have spoken to, don't even seem to realize its importance. So there you go. We cannot teach theory that we do not have. > [...] It was quite amusing to me to see that the XML model looked like > the old PICK products I'm accustomed to -- makes me think that perhaps > theory and practice might actually come to the same conclusion once we have > a better theory. Not even the staunchest defenders of native XML databases are claiming that they will replace RDBMSs. See for example the remarks by Dana Florescu at SD2004: http://www.webservicessummit.com/People/DFlorescu.htm There's a very simple reason for that. Many of these people used to do research on relational databases and know very well what their advantages can be. Also interesting in that respect is the fact that if you look at the current research on query optimization for XML the bigger successes in scalability and performance such as demonstrated in Efficient Algorithms for Processing XPath Queries. Georg Gottlob, Christoph Koch, and Reinhard Pichler. In Proc. VLDB 2002 and T. Grust, J. Teubner, M. van Keulen. Accelerating XPath Evaluation in Any RDBMS, in ACM Transactions on Database Systems (TODS), 29(1), pages 91-131, March 2004. are applying / extending techniques that were already known from relational research. This suggests that even if you have data that has a typical XML structure and is accessed in a typical XML way (XPath expressions) the relational model is very often still an excellent choice for your underlying logical data model. -- Jan Hidders >are applying / extending techniques that were already known from >relational research. This suggests that even if you have data that has >a typical XML structure and is accessed in a typical XML way (XPath >expressions) the relational model is very often still an excellent >choice for your underlying logical data model. Agreed. But that's one of the reasons I dislike relational, actually :-) It seeks to divorce the logical from the physical. With Pick, I let the real world dictate the physical data structure. I then impose relational theory over it. The relational model as implemented divorces the real world from the physical data structure by imposing set theory as a wall between the two :-( That is a MAJOR failing imho! Cheers, Wol SignatureAnthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 > Jan, > PS, Now that I see where Dawn and Nick are really coming from, I'm > starting to lose interest, fast. I don't think that is fair towards Dawn. Nick's postings are so moronoic that he is clearly either a complete ignoramus or a troll, and is therefore best ignored. But try as I might, I cannot find much fault with Dawn. She knows here stuff and admits it when she doesn't. She asks the right questions and is clearly smart enough to judge the quality of the answers given. She acknowledges the possibility of bias and tries to take that into account. In many ways her attitude is more scientific than that of some of the dbdebunk-disciples in this newsgroup. -- Jan Hidders For some reason, the first post I read from Nick was signed, "Nick and Dawn". That's why I put the two names together. > It's been claimed in this forum that there's no empirical data to compare > TCO between Oracle and PICK. [quoted text clipped - 3 lines] > I would never claim that it's conclusive evidence. But it is evidence. And > I can't believe it's unrelated to TCO. (Yes, I'm returning to the original statement, bypassing all the replies of those with fists and hackles raised in defense of their own opinions, some of them even resorting to name calling.) Although market share CAN indicate TCO, it's more an indicator of marketing expertise and $$$. TCO (containing the word "Total") comprises a lot of things. What is the initial investment (OS, Application and ancillary software, hardware, infrastructure, etc.)? What are recurring fees? What does it cost to maintain? How much do we pay for personnel? Since I have been involved in both camps here represented, I'd like to just comment that, in my experience, at times the relational model has been more appropriate and held a lower TCO than the MV (MultiValue or "Pick") model. In most cases, however, the reverse has been true. But, I think this is has more to do with the fact that my situation deals predominantly with businesses and even more specifically with manufacturers. Why, in these cases, has the TCO been lower for the MV model? Going back to the above mentioned components of TCO, the MV model surpassed the relational model on the initial investment (check out licensing fees, the rest like hardware and infrastructure can be similar if not identical), the recurring fees (license renewals, etc.), maintenance fees (look 'em up...they're all published and maintenance programming and professional services by MV professionals is 2/3 or less of what is standard by Oracle and other relational professionals) and personnel costs (MV does not require DBA's...no, nary a one! Of course, it is advisable to have someone knowledgeable on staff). There is more, but these things represent the bulk of TCO, IMHO and in these cases. This, my evidence, has been measured in monies paid to me (reflecting the word "COST" in TCO) and my various partners over the course of 22 years (is this a long enough test period???) and MV has "won out" in most cases DUE to a lower TCO. Referring back to some posts with references to scientific studies and articles/books published touting the advantages and strengths of the relational model I say, "So what?" The bottom line in a business cares little for what technology is published or not! The bottom line IS "the bottom line!" There are businesses who are Oracle shops out of snobbery only. They care not about TCO. The same happens in the MV community. Sometimes they go the MV route BECAUSE of TCO and care not about appropriate technological "fit". Both get hosed over the long run. Therefore, I shall end by saying that both technologies obviously have their place and, when utilized to the advantages and strengths of each, they have and will continue to work well and will provide a low TCO. In some instances, the relational model is appropriate. The same goes for the MV model. My 2? I now return you to your infighting. --Bruce (MCSA, MCSE, CLIPPER/dbase/FoxBASE/SQL Server/Access programmer, MV professional for 22 years, in IT since 1976) > in my experience, at times the relational model has been more appropriate > and held a lower TCO than the MV (MultiValue or "Pick") model. In most obviously have their > place and, when utilized to the advantages and strengths of each, they have > and will continue to work well and will provide a low TCO. In some > instances, the relational model is appropriate. The same goes for the MV > model. Agreed. As I said, market share is far from conclusive. And it's presumptuous to think, without further evidence, that either the ones who chose PICK or the ones who chose Oracle made a mistake. It sounds like, in some cases, you have the further evidence. But I'd generalize, and say that, in most cases, most customers know what they are doing. I just object to the argument that Oracle's market success is irrelevant to the TCO of the product. > > in my experience, at times the relational model has been more appropriate > > and held a lower TCO than the MV (MultiValue or "Pick") model. In most [quoted text clipped - 6 lines] > > Agreed. yup > As I said, market share is far from conclusive. And it's presumptuous to > think, without further evidence, that either the ones who chose PICK or > the ones who chose Oracle made a mistake. It sounds like, in some cases, > you have the further evidence. But I'd generalize, and say that, in most > cases, most customers know what they are doing. hmmm, most? Large shops might have an advantage, given more coverage of the overall skillsets required to develop software applications, but I don't think I agree with your last statement here. > I just object to the argument that Oracle's market success is irrelevant to > the TCO of the product. I agree that it is not irrelevant -- I'm not sure what the relevance is, but it is a worthwhile piece of information to have. I've never seen PICK show up on any database pie charts ever during my time in IT, so I don't know what the comparisons might be. One metric I have tried (and failed) to get from IBM is their gross dollars for their various database per software engineer they have assigned to maintain the database, or else their net return by database (DB2, IMS, Informix, UniData, UniVerse, Cloudscape, and whatever others they have). IBM is in a better position than most to see from a vendor standpoint where the PICK-based tools, the hierarchical database tool (yes, I'll admit that IMS and I had a thing going in the early 80's), and DB2, their relational model tool. --dawn [snip] > One metric I have tried (and failed) to get from IBM is their gross > dollars for their various database per software engineer they have [quoted text clipped - 6 lines] > > --dawn Dawn, I used to work for Unisys back in the dark ages when we were considered an alternative to IBM and I can assure you that the gross dollars per software engineer is a meaningless metric. The number of software engineers working on maintaining a particular DBMS as opposed to those working on enhancing the product is quite small. It would not surprise me to know that IBM has fewer than a dozen software engineers assigned to the maintenance of each of the products you mentioned. These products are all very well tested before they are released and as a result there are relatively few unknown bugs in them. In general there are known bugs, but they are scheduled to be fixed in future releases and no maintenance time is devoted to them. Jerry >> in my experience, at times the relational model has been more appropriate >> and held a lower TCO than the MV (MultiValue or "Pick") model. In most [quoted text clipped - 12 lines] >you have the further evidence. But I'd generalize, and say that, in most >cases, most customers know what they are doing. Yes. Empire building? >I just object to the argument that Oracle's market success is irrelevant to >the TCO of the product. Success doesn't always bear any resemblance to cost. Initial adoption often depends on cost. Were the big databases of the 60s available for free to Universities? Don't forget |
Enable EMail Alerts
Start New Thread
Reply to this Message