Re: Is IBM actually doing something with IDS?

Fred Pratt wrote: > IBM gives away DB2 in the form of DB2 Express C because DB2 is probably not > usable for bread-and-butter apps (OLTP) without help from IBM support. Strong words. Too strong to agree. But for an OLT app it's more likely you need support for a DB2 app than for an IDS app. The way this works is that each products aims to excel in their areas of strength. DB2 for LUW's strength is in the warehouse and XML. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

I agree with that. And I understand that DB2 is IBM's engine for warehouse and XML. But surely, a user of even average intelligence and patience can download DB2 Express C, install, and get *decent* OLTP performance without tweaking. You can do this with even MySQL and Oracle (yup, they have a free version also). I noticed that the machine limits for DB2 C are *very* generous (2 CPU, 4 GB RAM, and NO database size limit). This is plenty for most SMB apps. And yet DB2 seems to be getting very little traction in the SMB space (leaving out iSeries). And except for perhaps large SMP boxes, I don't think it's going anywhere in the LUW space either. Since the whole idea behind these "free" databases is to build developer mindshare by making it easy to evaluate and write apps to, why can't IBM give Informix a little oxygen on the low end? If not with IDS, then how about OnLine? Or SE? In the LU space, Oracle fears Informix much more than it does DB2. Fred -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Serge Rielau Sent: Tuesday, May 29, 2007 4:08 PM To: informix-list@iiug.org Subject: Re: Is IBM actually doing something with IDS? Fred Pratt wrote: > IBM gives away DB2 in the form of DB2 Express C because DB2 is > probably not usable for bread-and-butter apps (OLTP) without help from IBM support. Strong words. Too strong to agree. But for an OLT app it's more likely you need support for a DB2 app than for an IDS app. The way this works is that each products aims to excel in their areas of strength. DB2 for LUW's strength is in the warehouse and XML. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list

Serge Rielau said: > Fred Pratt wrote: >> IBM gives away DB2 in the form of DB2 Express C because DB2 is probably >> not >> usable for bread-and-butter apps (OLTP) without help from IBM support. > Strong words. Too strong to agree. But for an OLT app it's more likely > you need support for a DB2 app than for an IDS app. > > The way this works is that each products aims to excel in their areas of > strength. DB2 for LUW's strength is in the warehouse and XML. You say that, Serge, but isn't that just marketing spin because people weren't buying DB2 for OLTP? If IBM hadn't bought Informix, they'd still be desperately trying to convince people of the merits of SELECT FROM INSERT cursors for OLTP. -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Obnoxio The Clown wrote: > Serge Rielau said: >> Fred Pratt wrote: >>> IBM gives away DB2 in the form of DB2 Express C because DB2 is probably >>> not >>> usable for bread-and-butter apps (OLTP) without help from IBM support. >> Strong words. Too strong to agree. But for an OLT app it's more likely >> you need support for a DB2 app than for an IDS app. >> >> The way this works is that each products aims to excel in their areas of >> strength. DB2 for LUW's strength is in the warehouse and XML. > > You say that, Serge, but isn't that just marketing spin because people > weren't buying DB2 for OLTP? If IBM hadn't bought Informix, they'd still > be desperately trying to convince people of the merits of SELECT FROM > INSERT cursors for OLTP. What's marketing spin about acknowledging that IDS has OLTP strength and DB2 for LUW less so? If it were marketing spin it wouldn't be true. Now saying that would sure get me in trouble here. ;-) Do you mean SELECT * FROM NEW TABLE(INSERT INTO ...)? What has that harmless statement done to you to gain your wrath? Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Serge Rielau said: > Do you mean SELECT * FROM NEW TABLE(INSERT INTO ...)? > What has that harmless statement done to you to gain your wrath? It's a manifestation of overkill, where people keep coming up with more and more abstruse and ludicrous functionality to pretend that something is moving forward. -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Obnoxio The Clown wrote: > Serge Rielau said: >> Do you mean SELECT * FROM NEW TABLE(INSERT INTO ...)? >> What has that harmless statement done to you to gain your wrath? > It's a manifestation of overkill, where people keep coming up with more > and more abstruse and ludicrous functionality to pretend that something is > moving forward. Perfect, you are making my point. You do have an OLTP view of the world. I (who pushed that language instead of INSERT WITH RETURN) have a data warehousing view of the world. We have completely different priorities and they are reflected in the products we each prefer. This manifestation of overkill was acknowledged to be good my Oracle techies at VLDB. And MS has approached us to get it into the SQL Standard because their brand spanking new simple version wasn't good enough they realized. SELECT FROM INSERT/UPDATE/DELETE/MERGE is not geared towards OLTP. INSERT WITH RETURN or a parking the identity column value in a SQLCA.ERRD field does not help in the warehouse, when ingesting tens of thousand of rows in one gulp. I have no issue with an INSERT WITH RETURN syntactic sugar for the simple single row OLTP case and I suspect the standard will provide for both and DB2 will too. When you design a language you must design for the future and then simplify the simple cases. Anything else is "painting yourself into a corner". BTW, I am the guy who made that language happen. I am the proverbial horse's mouth :-) Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Serge Rielau said: > Obnoxio The Clown wrote: >> Serge Rielau said: >>> Do you mean SELECT * FROM NEW TABLE(INSERT INTO ...)? >>> What has that harmless statement done to you to gain your wrath? >> It's a manifestation of overkill, where people keep coming up with more >> and more abstruse and ludicrous functionality to pretend that something >> is >> moving forward. > Perfect, you are making my point. You do have an OLTP view of the world. > I (who pushed that language instead of INSERT WITH RETURN) have a data > warehousing view of the world. We have completely different priorities > and they are reflected in the products we each prefer. Horseshit. When I asked you to explain this feature when you were crowing about it years ago, you used an order entry example. If that's not OLTP, I don't know what is. > This manifestation of overkill was acknowledged to be good my Oracle > techies at VLDB. And MS has approached us to get it into the SQL > Standard because their brand spanking new simple version wasn't good > enough they realized. > > SELECT FROM INSERT/UPDATE/DELETE/MERGE is not geared towards OLTP. > INSERT WITH RETURN or a parking the identity column value in a > SQLCA.ERRD field does not help in the warehouse, when ingesting tens of > thousand of rows in one gulp. Horseshit again. You're changing a language just to cope with one possible way of loading up a table. Even worse, you're extending the language in such a way as to possibly make people not have to think about what they're doing. Six months later, someone in tech support or some sucker business partner is going to spend the rest of their life picking up the pieces of your encouragement of their laziness. > BTW, I am the guy who made that language happen. I am the proverbial > horse's mouth :-) Really? I thought you might be the other end. -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Obnoxio The Clown wrote: > Horseshit. When I asked you to explain this feature when you were crowing > about it years ago, you used an order entry example. If that's not OLTP, I > don't know what is. You aren't accusing Serge of painting the target after the arrow was shot are you? <g> -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

DA Morgan said: > Obnoxio The Clown wrote: > >> Horseshit. When I asked you to explain this feature when you were >> crowing >> about it years ago, you used an order entry example. If that's not OLTP, >> I >> don't know what is. > > You aren't accusing Serge of painting the target after the arrow was > shot are you? <g> That's one way of putting it. :o) -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Obnoxio The Clown wrote: > DA Morgan said: >> Obnoxio The Clown wrote: >> >>> Horseshit. When I asked you to explain this feature when you were >>> crowing >>> about it years ago, you used an order entry example. If that's not OLTP, >>> I >>> don't know what is. >> You aren't accusing Serge of painting the target after the arrow was >> shot are you? <g> > > That's one way of putting it. :o) > Using much less controversial language though and without dragging me into his fantasies. What's with that fixation on horses behinds? ;-) I indeed used order entry examples and I keep using them. Just because the primary target of the language OLTP doesn't mean it's useless in OLTP. In fact the cause to implement was TPC-C. It's just fluffy language wise, but SQL isn't exactly known to be easy on the keyboard to begin with. ;-) Since we have Daniel on board now - oh joy - maybe he can tell us how one moves (not just copies) data from one table to another in his world. How would you do it IDS? When we started planning for "returning modified rows" in DB2 V7 (identity columns) the straw man was to use the Oracle syntax. It sure did the job, but we hated having to dump the data outside SQL. The immediate implication are in-memory tables (associative arrays, index by tables, blah...), bulk-collect, temp tables, etc... lot's of infrastructure just to park data you want to keep processing. Not for a single row OLTP case, but for multiple row stuff. What about aggregations on the modified data, data move, data dispatch from a staging table into multiple target tables? So we looked at alternatives. It sure was more work than following Oracle's syntax. Since we are on memory lane I think this was the time when I conceded that Oracle is the best procedural DBMS out there. ;-) Anyway, I think we have sufficiently deviated from the original thread that I have to invite you either to take this offline or at least move to c.d.ibm-db2. I'll gladly stand trial for my "invention" there ;-) Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Serge Rielau wrote: > Obnoxio The Clown wrote: >> DA Morgan said: >>> Obnoxio The Clown wrote: >>> >>>> Horseshit. When I asked you to explain this feature when you were >>>> crowing >>>> about it years ago, you used an order entry example. If that's not >>>> OLTP, >>>> I >>>> don't know what is. >>> You aren't accusing Serge of painting the target after the arrow was >>> shot are you? <g> >> >> That's one way of putting it. :o) >> > Using much less controversial language though and without dragging me > into his fantasies. What's with that fixation on horses behinds? ;-) > > I indeed used order entry examples and I keep using them. > Just because the primary target of the language OLTP doesn't mean it's > useless in OLTP. In fact the cause to implement was TPC-C. > It's just fluffy language wise, but SQL isn't exactly known to be easy > on the keyboard to begin with. ;-) > > Since we have Daniel on board now - oh joy - maybe he can tell us how > one moves (not just copies) data from one table to another in his world. Well first we start by asking the customer the following questions. 1. What version of what product to what version of what product? 2. What volume of data? Are we talking single transactions or GB? 3. What is the windows? One second or one day? 4. How close to real-time? Milliseconds? 24 hours? 5. With or without transformation? 6. With or without audit trail and compliance requirements? 7. For what purpose? 8. One time only or as a regularly scheduled job? There is a huge difference between copying to a DR site real time and copy to a reporting database on a separate server and copying within a single stand-alone database-instance. The best practice answer depends on many factors and technologies that come to mind. In an Oracle environment, they would range from transportable tablespaces to Streams to Change Data Capture to Data Guard to external tables to datapump export-import to database links to spooling it out as a text file. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org