Re: IDS on a Mac?

Serge Rielau wrote: > Ian Michael Gumby wrote: >>> From: Serge Rielau <srielau@ca.ibm.com> > The OP's statement most >>> likely stems from not understanding the >>> > differences between the two products. >>> I don't think so.... >>> Here is my take: >>> The advantage of session-local temporary tables, that is tables who's >>> definition is not persisted in the catalog has the advantage that ad-hoc >>> tables can be created quickly without impacting the catalog and without >>> a care whether some other session may have a table with the same name >>> (but a different signature) >>> The downside of this behavior is that it's somewhat challenging to use >>> these kinds of tables across multiple objects because there is no >>> guarantee that the procedure that is trying to use Temp1 actually gets >>> Temp1 in the shape it expects it to be. >> >> You're going to have to be a bit more specific in how you define >> "object". "Object" has different meanings to different people.... >> >> The disadvantage that you state is kind of meaningless in practice. If >> you think about it, the temp table is only persistant during a >> connection. So that the calling app that instantiated the connection >> should know how or what is defined by the temp table. And the name >> temp1 has to be unique per connection. (Meaning that connection A can >> create a temp1 table and connection B can create a temp table temp1 >> but they will be different objects...) >> >> The huge problem with Oracle's temp tables is that their definition >> isnt temp, its global. What is temporary is the data that you can >> maintain in the temp will last only as long as the session. So what >> happens if I want to load in 300,000 rows of temp data in to the temp >> table and there's no index on the table? (Hint: SEQUENTIAL SCAN OF THE >> TABLE). In Oracle, you can't create an index on a temp table if there >> are any rows in it, and you can't control who/what someone else does >> to the temp table. > Interesting. I didn't know Oracle had this funny limitation. > Either way that limitation is not core to the "concept" of a CREATEd > temporary table. > Speaking about limitations / differences... Are inserts / deletes / updates on Oracle temp tables still logged? I remember "older versions" and I believe this was so, but I'm not sure as to whether it was or still is . . . . JWC

John Carlson wrote: > Serge Rielau wrote: >> Ian Michael Gumby wrote: >>>> From: Serge Rielau <srielau@ca.ibm.com> > The OP's statement most >>>> likely stems from not understanding the >>>> > differences between the two products. >>>> I don't think so.... >>>> Here is my take: >>>> The advantage of session-local temporary tables, that is tables who's >>>> definition is not persisted in the catalog has the advantage that >>>> ad-hoc >>>> tables can be created quickly without impacting the catalog and without >>>> a care whether some other session may have a table with the same name >>>> (but a different signature) >>>> The downside of this behavior is that it's somewhat challenging to use >>>> these kinds of tables across multiple objects because there is no >>>> guarantee that the procedure that is trying to use Temp1 actually gets >>>> Temp1 in the shape it expects it to be. >>> >>> You're going to have to be a bit more specific in how you define >>> "object". "Object" has different meanings to different people.... >>> >>> The disadvantage that you state is kind of meaningless in practice. >>> If you think about it, the temp table is only persistant during a >>> connection. So that the calling app that instantiated the connection >>> should know how or what is defined by the temp table. And the name >>> temp1 has to be unique per connection. (Meaning that connection A can >>> create a temp1 table and connection B can create a temp table temp1 >>> but they will be different objects...) >>> >>> The huge problem with Oracle's temp tables is that their definition >>> isnt temp, its global. What is temporary is the data that you can >>> maintain in the temp will last only as long as the session. So what >>> happens if I want to load in 300,000 rows of temp data in to the temp >>> table and there's no index on the table? (Hint: SEQUENTIAL SCAN OF >>> THE TABLE). In Oracle, you can't create an index on a temp table if >>> there are any rows in it, and you can't control who/what someone else >>> does to the temp table. >> Interesting. I didn't know Oracle had this funny limitation. >> Either way that limitation is not core to the "concept" of a CREATEd >> temporary table. >> > > Speaking about limitations / differences... > > Are inserts / deletes / updates on Oracle temp tables still logged? I > remember "older versions" and I believe this was so, but I'm not sure as > to whether it was or still is . . . . > > JWC Global temporary tables have several major benefits: 1. Non-interference between private sets of data. 2. Ease of getting rid of 'scratch' data. In a heap table you either rollback, or delete it. But in a GTT, you can truncate explicitly, without affecting anyone else (or allow the implicit "truncate on commit / exit" effect to do the same thing). 3. Decreased redo generation as, by definition, they are non-logging. No decreased ... not zero. create table reg_tab (testcol VARCHAR2(100)); CREATE GLOBAL TEMPORARY TABLE gtt_ocd ( testcol VARCHAR2(100)) ON COMMIT DELETE ROWS; CREATE GLOBAL TEMPORARY TABLE gtt_ocp ( testcol VARCHAR2(100)) ON COMMIT PRESERVE ROWS; col value format 999999999999 -- get baseline redo value SELECT value FROM sys.v_$sysstat WHERE name = 'redo size'; -- load 1000 rows into a heap table BEGIN FOR i IN 1 .. 1000 LOOP INSERT INTO reg_tab (testcol) VALUES (RPAD('X', 99)); END LOOP; COMMIT; END; / -- record the redo generated SELECT value FROM sys.v_$sysstat WHERE name = 'redo size'; -- load 1000 rows into a GTT with ON COMMIT DELETE ROWS BEGIN FOR i IN 1 .. 1000 LOOP INSERT INTO gtt_ocd (testcol) VALUES (RPAD('X', 99)); END LOOP; COMMIT; END; / -- record the redo generated SELECT value FROM sys.v_$sysstat WHERE name = 'redo size'; -- load 1000 rows into a GTT with ON COMMIT PRESERVE ROWS BEGIN FOR i IN 1 .. 1000 LOOP INSERT INTO gtt_ocp (testcol) VALUES (RPAD('X', 99)); END LOOP; COMMIT; END; / -- record the redo generated SELECT value FROM sys.v_$sysstat WHERE name = 'redo size'; Description Value Redo Generated Baseline 254269080 - Regular Table Run 254605916 336836 On Commit Delete 254742528 136612 On Commit Preserve 254879140 136612 Be sure this is part of the compatibility feature set. <g> -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org

>From: DA Morgan <damorgan@psoug.org> [SNIP] Sigh. This is a design issue that shows that while there are general concepts which are the same across different platforms, there some subtle differences which will impact performance. The implementation of Temp tables in Oracle is wrong. Ugly, inefficient and barely supports the idea of the "INTO TEMP" clause that I believe is part of the SQL standard. Now when I say "WRONG", I'm talking from a purely design perspective. (In truth there is no right or wrong, its a question about how to interpret the requirements and does the solution meet the stated goals. ) However, as a developer if I want to KISS (that's an engineering term), I want to have my temp tables defined dynamically and be unique in that I don't incur overhead or issues from other implementations. The example I've used is that you can not create an index on a temp table if the table has data anywhere. That is even if I trunc my data, a different user could still have data in the temp table. So I can't create an index. While this may seem like a small nit, its not. When you're doing some computations on a subset, or need to create a functional index on the subset. So creating and dropping indexes on subsets is not possible. An example? Suppose I have a field where the value is a bitmask and I only want to select a certain portion for processing. I can't easily do this with Oracle's temp tables. Hence the issue. The "right" solution allows the developer a lot of freedom and still conforms to the spec. Hence the preference for IDS. On a completely different topic, is the extensibility issue. (Don't get me started on Oracle's "extensibility....". And to keep this issue simple, lets talk about Sybase's adaptive server. Its extensible, however, they didn't fence in the user/developer's code so that if there is ineffcient code, it will kill the performance of the entire database. Note that even if the code looks clean, it can still be inefficient. Again kudos to IDS's developers who thought things out before implementations. ER/HDR anyone? That is the point. Its a better designed system. And DA, you keep citing statistics about open rec's for FTEs. Here's an example I think you might be able to grasp. Porsche doesn't have a "green" car in its line up. The company defended itself by saying that if you took all the Porsche vehicles off the road, you'd have a less than 1% impact on CO2 emmissions from automobiles. So when you ask a customer, that for the same price, would you rather be driving an econobox or a Porsche, what do you think they'll say? ;-) _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i'm Initiative now. http://im.live.com/messenger/im/home/?source=TAGHM

Ian Michael Gumby wrote: > > > >> From: DA Morgan <damorgan@psoug.org> > [SNIP] > > Sigh. > > This is a design issue that shows that while there are general concepts > which are the same across different platforms, there some subtle > differences which will impact performance. > > The implementation of Temp tables in Oracle is wrong. Ugly, inefficient > and barely supports the idea of the "INTO TEMP" clause that I believe is > part of the SQL standard. This is the most preposterous statement I've heard in quite awhile not because, quite simply, there is no basis in fact. Allow me to prove it. 1. On what version of Oracle did you test Oracle's temp tables? 2. Which temp table types did you test? 3. With what tool did you gather the metrics? 4. Post the test design, the DDL, the DML, and the results. Your statement has as much basis in fact as saying swordfish is better than salmon. You think what Informix does, is better. Put up the test case. > Now when I say "WRONG", I'm talking from a purely design perspective. And purely from the perspective of someone who doesn't work with undo segments and undo tablespaces and doesn't understand the architecture underlying MVRC and has no actual basis for the opinion other than that he likes blue more than red. > (In truth there is no right or wrong, its a question about how to > interpret the requirements and does the solution meet the stated goals. ) Closer to the facts but a waffle given the above rant. > However, as a developer if I want to KISS (that's an engineering term), > I want to have my temp tables defined dynamically and be unique in that > I don't incur overhead or issues from other implementations. Which means you don't want to write code the creates and drops them on-the-fly. Far better to create them, index them, constrain them, and let them take care of themselves forever. But that would conflict with your overriding prejudice against anything non-Informix. > The example I've used is that you can not create an index on a temp > table if the table has data anywhere. Of course not. Buiding indexes on-the-fly in a production database is not just silly it is counterproductive adding unnecessary overhead. If you design systems rather than just throw them over the cubicle wall then you design your table, you design your indexes, you build them during schema creation, and you leave them alone for all to use and for the life of the application. Complaining that an implementation doesn't let you create objects that the optimizer might want to know about any time you feel like it is the very core of bad practice. > That is even if I trunc my data, a > different user could still have data in the temp table. So I can't > create an index. While this may seem like a small nit, its not. When > you're doing some computations on a subset, or need to create a > functional index on the subset. So creating and dropping indexes on > subsets is not possible. Nor should it be. Do you think creating and dropping objects has no cost? > An example? Suppose I have a field where the value is a bitmask and I > only want to select a certain portion for processing. I can't easily do > this with Oracle's temp tables. Hence the issue. Sure you can. Of course provided you know how. If you have a problem why don't you tell us about it in the Oracle usenet group and we will help you solve it. > The "right" solution allows the developer a lot of freedom and still > conforms to the spec. Hence the preference for IDS. So far you've not given a single example of this but I doubt that will stop you ... you're on a roll. > On a completely different topic, is the extensibility issue. (Don't get > me started on Oracle's "extensibility....". And to keep this issue > simple, lets talk about Sybase's adaptive server. Why not other than, it would seem, the fact that you know nothing about it with respect to any currently supported version of the product. > Its extensible, however, they didn't fence in the user/developer's code > so that if there is ineffcient code, it will kill the performance of the > entire database. Note that even if the code looks clean, it can still be > inefficient. Explaining, it would seem, why it is that Sybase is currently outselling Informix by a wide margin. And why Sybase shops are looking for employees for real-work while Informix shops are not: dice.com monster.com hotjobs.com Sybase 2,146 304 548 Informix 343 43 173 jobs available as of 5 November, 2007. You are presiding over a funeral so it is understandable that you would praise the departed. > Again kudos to IDS's developers who thought things out before > implementations. ER/HDR anyone? And curses to Informix and IBM management: antipathy in action. > That is the point. Its a better designed system. Just like WordStar, just like Lotus 123, just like Borland Pascal. > And DA, you keep citing statistics about open rec's for FTEs. Amazing how some people actually think getting paid for what they do has value: Go figure. > Here's an example I think you might be able to grasp. Why? Do you think your readers too stupid too see a lack of jobs as relevant? > Porsche doesn't have a "green" car in its line up. The company defended > itself by saying that if you took all the Porsche vehicles off the road, > you'd have a less than 1% impact on CO2 emmissions from automobiles. And this somehow trumps the fact that not a single college or university on the planet offers a single class for Informix. The next generation of developers and DBAs is coming from where? Apparently the same place new sales are coming from? The tooth fairy. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org

DA Morgan wrote: > Ian Michael Gumby wrote: >> >> >> >>> From: DA Morgan <damorgan@psoug.org> >> [SNIP] >> >> Sigh. >> >> This is a design issue that shows that while there are general >> concepts which are the same across different platforms, there some >> subtle differences which will impact performance. >> >> The implementation of Temp tables in Oracle is wrong. Ugly, >> inefficient and barely supports the idea of the "INTO TEMP" clause >> that I believe is part of the SQL standard. > > This is the most preposterous statement I've heard in quite awhile not > because, quite simply, there is no basis in fact. Allow me to prove it. > > 1. On what version of Oracle did you test Oracle's temp tables? > 2. Which temp table types did you test? > 3. With what tool did you gather the metrics? > 4. Post the test design, the DDL, the DML, and the results. > > Your statement has as much basis in fact as saying swordfish is better > than salmon. > > You think what Informix does, is better. Put up the test case. > >> Now when I say "WRONG", I'm talking from a purely design perspective. > > And purely from the perspective of someone who doesn't work with undo > segments and undo tablespaces and doesn't understand the architecture > underlying MVRC and has no actual basis for the opinion other than that > he likes blue more than red. > >> (In truth there is no right or wrong, its a question about how to >> interpret the requirements and does the solution meet the stated goals. ) > > Closer to the facts but a waffle given the above rant. > >> However, as a developer if I want to KISS (that's an engineering >> term), I want to have my temp tables defined dynamically and be unique >> in that I don't incur overhead or issues from other implementations. > > Which means you don't want to write code the creates and drops them > on-the-fly. Far better to create them, index them, constrain them, and > let them take care of themselves forever. But that would conflict with > your overriding prejudice against anything non-Informix. > >> The example I've used is that you can not create an index on a temp >> table if the table has data anywhere. > > Of course not. Buiding indexes on-the-fly in a production database is > not just silly it is counterproductive adding unnecessary overhead. > > If you design systems rather than just throw them over the cubicle wall > then you design your table, you design your indexes, you build them > during schema creation, and you leave them alone for all to use and for > the life of the application. > > Complaining that an implementation doesn't let you create objects that > the optimizer might want to know about any time you feel like it is > the very core of bad practice. > >> That is even if I trunc my data, a different user could still have >> data in the temp table. So I can't create an index. While this may >> seem like a small nit, its not. When you're doing some computations on >> a subset, or need to create a functional index on the subset. So >> creating and dropping indexes on subsets is not possible. > > Nor should it be. Do you think creating and dropping objects has no > cost? > >> An example? Suppose I have a field where the value is a bitmask and I >> only want to select a certain portion for processing. I can't easily >> do this with Oracle's temp tables. Hence the issue. > > Sure you can. Of course provided you know how. If you have a problem > why don't you tell us about it in the Oracle usenet group and we will > help you solve it. > >> The "right" solution allows the developer a lot of freedom and still >> conforms to the spec. Hence the preference for IDS. > > So far you've not given a single example of this but I doubt that will > stop you ... you're on a roll. > >> On a completely different topic, is the extensibility issue. (Don't >> get me started on Oracle's "extensibility....". And to keep this issue >> simple, lets talk about Sybase's adaptive server. > > Why not other than, it would seem, the fact that you know nothing about > it with respect to any currently supported version of the product. > >> Its extensible, however, they didn't fence in the user/developer's >> code so that if there is ineffcient code, it will kill the performance >> of the entire database. Note that even if the code looks clean, it can >> still be inefficient. > > Explaining, it would seem, why it is that Sybase is currently outselling > Informix by a wide margin. And why Sybase shops are looking for > employees for real-work while Informix shops are not: > > dice.com monster.com hotjobs.com > Sybase 2,146 304 548 > Informix 343 43 173 > > jobs available as of 5 November, 2007. Back on that soapbox, Daniel? I was kinda wondering how long it would take . . . . Some more noteworthy quotes . . . > > You are presiding over a funeral so it is understandable that you would > praise the departed. > > Just like WordStar, just like Lotus 123, just like Borland Pascal. > > And this somehow trumps the fact that not a single college or university > on the planet offers a single class for Informix. The next generation of > developers and DBAs is coming from where? Apparently the same place new > sales are coming from? The tooth fairy. More value-added blather for c.d.i. JWC

John Carlson wrote: > DA Morgan wrote: >> Ian Michael Gumby wrote: >>> >>> >>> >>>> From: DA Morgan <damorgan@psoug.org> >>> [SNIP] >>> >>> Sigh. >>> >>> This is a design issue that shows that while there are general >>> concepts which are the same across different platforms, there some >>> subtle differences which will impact performance. >>> >>> The implementation of Temp tables in Oracle is wrong. Ugly, >>> inefficient and barely supports the idea of the "INTO TEMP" clause >>> that I believe is part of the SQL standard. >> >> This is the most preposterous statement I've heard in quite awhile not >> because, quite simply, there is no basis in fact. Allow me to prove it. >> >> 1. On what version of Oracle did you test Oracle's temp tables? >> 2. Which temp table types did you test? >> 3. With what tool did you gather the metrics? >> 4. Post the test design, the DDL, the DML, and the results. >> >> Your statement has as much basis in fact as saying swordfish is better >> than salmon. >> >> You think what Informix does, is better. Put up the test case. >> >>> Now when I say "WRONG", I'm talking from a purely design perspective. >> >> And purely from the perspective of someone who doesn't work with undo >> segments and undo tablespaces and doesn't understand the architecture >> underlying MVRC and has no actual basis for the opinion other than that >> he likes blue more than red. >> >>> (In truth there is no right or wrong, its a question about how to >>> interpret the requirements and does the solution meet the stated >>> goals. ) >> >> Closer to the facts but a waffle given the above rant. >> >>> However, as a developer if I want to KISS (that's an engineering >>> term), I want to have my temp tables defined dynamically and be >>> unique in that I don't incur overhead or issues from other >>> implementations. >> >> Which means you don't want to write code the creates and drops them >> on-the-fly. Far better to create them, index them, constrain them, and >> let them take care of themselves forever. But that would conflict with >> your overriding prejudice against anything non-Informix. >> >>> The example I've used is that you can not create an index on a temp >>> table if the table has data anywhere. >> >> Of course not. Buiding indexes on-the-fly in a production database is >> not just silly it is counterproductive adding unnecessary overhead. >> >> If you design systems rather than just throw them over the cubicle wall >> then you design your table, you design your indexes, you build them >> during schema creation, and you leave them alone for all to use and for >> the life of the application. >> >> Complaining that an implementation doesn't let you create objects that >> the optimizer might want to know about any time you feel like it is >> the very core of bad practice. >> >>> That is even if I trunc my data, a different user could still have >>> data in the temp table. So I can't create an index. While this may >>> seem like a small nit, its not. When you're doing some computations >>> on a subset, or need to create a functional index on the subset. So >>> creating and dropping indexes on subsets is not possible. >> >> Nor should it be. Do you think creating and dropping objects has no >> cost? >> >>> An example? Suppose I have a field where the value is a bitmask and I >>> only want to select a certain portion for processing. I can't easily >>> do this with Oracle's temp tables. Hence the issue. >> >> Sure you can. Of course provided you know how. If you have a problem >> why don't you tell us about it in the Oracle usenet group and we will >> help you solve it. >> >>> The "right" solution allows the developer a lot of freedom and still >>> conforms to the spec. Hence the preference for IDS. >> >> So far you've not given a single example of this but I doubt that will >> stop you ... you're on a roll. >> >>> On a completely different topic, is the extensibility issue. (Don't >>> get me started on Oracle's "extensibility....". And to keep this >>> issue simple, lets talk about Sybase's adaptive server. >> >> Why not other than, it would seem, the fact that you know nothing about >> it with respect to any currently supported version of the product. >> >>> Its extensible, however, they didn't fence in the user/developer's >>> code so that if there is ineffcient code, it will kill the >>> performance of the entire database. Note that even if the code looks >>> clean, it can still be inefficient. >> >> Explaining, it would seem, why it is that Sybase is currently outselling >> Informix by a wide margin. And why Sybase shops are looking for >> employees for real-work while Informix shops are not: >> >> dice.com monster.com hotjobs.com >> Sybase 2,146 304 548 >> Informix 343 43 173 >> >> jobs available as of 5 November, 2007. > > Back on that soapbox, Daniel? I was kinda wondering how long it would > take . . . . > > Some more noteworthy quotes . . . >> >> You are presiding over a funeral so it is understandable that you would >> praise the departed. >> >> Just like WordStar, just like Lotus 123, just like Borland Pascal. >> >> And this somehow trumps the fact that not a single college or university >> on the planet offers a single class for Informix. The next generation of >> developers and DBAs is coming from where? Apparently the same place new >> sales are coming from? The tooth fairy. > > More value-added blather for c.d.i. > > JWC If you choose to discuss Oracle here ... then I will post. If you don't I won't. Funny thing no one in the DB2, Oracle, SQL Server, and Sybase forums ever brings up Informix. I guess people with real products to work with don't feel compelled to bash products they don't know. What is interesting here is that my posts are almost always with respect to clearing up FUD about Oracle posted by people who haven't used a currently supported version. If you folks had real work to do you wouldn't be spending so much time focusing on the make-believe faults of a product that has the lion's share of the marketplace. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org

On 6 Nov, 02:42, DA Morgan <damor...@psoug.org> wrote: > > If you choose to discuss Oracle here ... then I will post. If you don't > I won't. Funny thing no one in the DB2, Oracle, SQL Server, and Sybase > forums ever brings up Informix. So I thought I'd have a look. You're actually wrong - I find 2,610 results searching for "Informix" in C.D.O.S, as well as the interesting fact that whenever the word is raised, your name is right there in the frame, every time. Pavlov would be proud, the way your kneejerk kicks in as soon it is mentioned. Methinks the man protests too much. Looks like you're scared, Dan. And all I can find is your pretentious, self-aggrandising, overblown rhetoric and spurious highly selective 'statistics', and hiding behind NDAs whenever you're questioned. Fuck off, Dan. You're a troll. !PLONK!

>From: iiug@perrior.net >Methinks the man protests too much. Looks like you're scared, Dan. >And all I can find is your pretentious, self-aggrandising, overblown >rhetoric and spurious highly selective 'statistics', and hiding behind >NDAs whenever you're questioned. >Fuck off, Dan. You're a troll. >!PLONK! > Don't blame him. He's been brain washed. I see it all the time. Someone learns Oracle, becomes an "expert" in oracle, even drinks the cool-aid. So they believe that Oracle is the best despite all the facts. After all, it pays their bills. Do it enough times, and you'll get yourself an army of evangelists. Oh I do work with a lot of different databases and I'll bash Oracle a lot on their design. The truth is I can make most anything work on any platform, but will it work well? Take timeseries for example. I can cobble something together on any database that supports blobs. But it wouldn't be as efficient unless I have a certain amount of extensibility ... But hey, what can I say? I'll drink a lot of things, but I won't drink a company's cool-aid. -G _________________________________________________________________ Make distant family not so distant with Windows Vista' + Windows Live'. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGHM_CPC_VideoChat_distantfamily_102007

>From: DA Morgan <damorgan@psoug.org> > >John Carlson wrote: > > DA Morgan wrote: > >> Ian Michael Gumby wrote: [SNIP] > >> > >> If you design systems rather than just throw them over the cubicle wall > >> then you design your table, you design your indexes, you build them > >> during schema creation, and you leave them alone for all to use and for > >> the life of the application. > >> > >> Complaining that an implementation doesn't let you create objects that > >> the optimizer might want to know about any time you feel like it is > >> the very core of bad practice. > >> [SNIP] I'm going to step in here because Daniel is yet again talking out of his ass and doesn't grok what it means to be an app developer, let alone how to maintain data quality on a very large datawarehouse... Caveat. I can't talk directly what I'm working on. That would be a violation of my NDA. What I can say is that I'm working on *the* *largest* geo spatial database in the world. Part of the problem is that we take in data from third parties which may or may not be correct, along with continual enhancement to our model. So now I have to write a script that will allow me to check a field in one table and decide if I need to create ancillary data in another table. Only its not that simple. To get the rows in the one table that need to be updated, I have to do a couple of table joins to get the data. And then I need to store them in a temp table. Now the fun part. If you join against the temp table, and you have over 10,000 rows. You're pretty much screwed. (And before Daniel opens his mouth, there's about a million rows in the base table and my temp table has around 150,000 rows, based on the data I want to update. So my query goes to shit unless I can index my temp table. What that means is that I need to create a GLOBAL TEMP table and then drop it at the end of my python script. (Why Python? Cause I have to do some processing that is easier in a scripting language than in PL/SQL) The reason I can't use an existing GLOBAL TEMP table is that I need to create the index. But I can't create an index because someone else may have data in that temp table. (Yes, even if my data set is blank, I can't create the index.) So I have to create the table, create the index and then do my work. Oh and Daniel, depending on the data I'm updating to fit the new model, That index will change. A real life case daniel of "not throwing some design over the wall". The model changes and you have to either populate the data or change/cleanse it. REAL LIFE BABY! With Informix, I can create the table on the fly and when I exit, it all goes away. Oh and if I'm trying to run a couple of these scripts in parallel, I have to pass in a unique global temp table so that when I need to create a different index, I can, and at the end, I can delete the table. Oh and to make matters worse.... The statements to create and drop the table are auto commits, so I have to make sure that I want to commit the changes prior to droping the tables. > >>> An example? Suppose I have a field where the value is a bitmask and I > >>> only want to select a certain portion for processing. I can't easily > >>> do this with Oracle's temp tables. Hence the issue. > >> > >> Sure you can. Of course provided you know how. If you have a problem > >> why don't you tell us about it in the Oracle usenet group and we will > >> help you solve it. > >> Daniel, You just want to shoot your mouth off instead of reading what was written. YOU CAN NOT CREATE AN INDEX ON A TEMP TABLE THAT ALREADY HAS DATA. SINCE ORACLE CREATES GLOBAL TEMP TABLES AND YOU CAN'T CONTROL WHAT OTHER USER IS USING THIS GLOBAL TEMP TABLE, IT IS VERY LIKELY THAT THERE IS ALREADY DATA WITHIN THE TEMP TABLE. THIS IS WHAT FORCES YOU TO CREATE AND DROP "GLOBAL TEMP TABLES" on the fly. THERE IS NO "WORK AROUND" other than doing what I am doing. I'm sitting next to a guy who's written a couple of Oracle books and another guy who's an ex-Oracle developer. You don't think I stop by to pick there brains? > >> > >>> On a completely different topic, is the extensibility issue. (Don't > >>> get me started on Oracle's "extensibility....". And to keep this > >>> issue simple, lets talk about Sybase's adaptive server. > >> > >> Why not other than, it would seem, the fact that you know nothing about > >> it with respect to any currently supported version of the product. > >> Really daniel? Client is on 9i. It takes a lot to move to the next generation. Unlike Informix which is a lot simpler. > >> Explaining, it would seem, why it is that Sybase is currently >outselling > >> Informix by a wide margin. And why Sybase shops are looking for > >> employees for real-work while Informix shops are not: > >> > >> dice.com monster.com hotjobs.com > >> Sybase 2,146 304 548 > >> Informix 343 43 173 > >> > >> jobs available as of 5 November, 2007. > > LOL... No daniel, the number of jobs is that Sybase types are running away from their jobs and are trying to work with new technology. Hence the demand for sybase DBAs. Of course I just love how you toss out a meaningless and irrelevant fact to try and strengthen your case. I mean, heck here in Chicago, I'll get 5 calls about the same job. So when there's one opening you can get 5 - 10 companies posting on the boards looking for bodies. Informix shops don't really do that. Why? Cause they don't need an army to keep things afloat. Keep dreaming Daniel. -G _________________________________________________________________ Be the first to know who's in and who's out.' Check out the xRank. http://search.live.com/xrank/results.aspx?q=britney+spears&FORM=MGCC01

I thought the title of the thread was "IDS on Mac OSX". Why don't you just create a new thread and move all the Oracle vs. Informix and all the personal bashing over there????

Well *he* started it. It was about IDS on Mac. I thought that it was interesting because Oracle would have been there first. Turns out it was. Only that Oracle didn't want to continue to pay for certifying a port that doesn't generate revenue. I don't think that IDS on Mac would be a major revenue generator, however I do think that it will help seed other sales. IDS isn't tied to a strict ERP type of application. IDS is really all around, despite Daniel's blowhard inability to face reality. Does IDS have the marketshare of Oracle? Naw. Does that mean IDS is inferior? Naw. IMHO if IBM were smurt, they'd ditch DB2 distributed and focus on IDS and leave DB2 on the mainframe. But hey! What do I know? ;-) CHeers! -G >From: Zachi <zklopman@gmail.com> >I thought the title of the thread was "IDS on Mac OSX". Why don't you >just create a new thread and move all the Oracle vs. Informix and all >the personal bashing over there???? > >_______________________________________________ >Informix-list mailing list >Informix-list@iiug.org >http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Be the first to know who's in and who's out.' Check out the xRank. http://search.live.com/xrank/results.aspx?q=britney+spears&FORM=MGCC01

Ian Michael Gumby wrote: > Well *he* started it. > > It was about IDS on Mac. > I thought that it was interesting because Oracle would have been there > first. > > Turns out it was. Only that Oracle didn't want to continue to pay for > certifying a port that doesn't generate revenue. That's a pile of rubbish and you know it. I very clearly stated that Oracle created the port at its own expense and that Apple refused to live up to its part of the bargain when they released Tiger. I little integrity would be both appropriate and appreciated. As to whether Oracle supports things that don't bring in revenue? http://oss.oracle.com/ Other people may have other opinions. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)