Unfortunately not.

Silly me, I seem to recall that Larry Ellison sits on Apples board. Or am I
dating myself? ;-)

A certain Apple exec once joked to me (again, many moons ago) that if there
were a database port to Apple, it would probably be an Oracle port since
Steve and Larry are such good friends.

Having said that, there's this thing called "location based services". This
is a very young industry and there's a lot of things that have been talked
about, but if you get down to it, the logistics are a killer. (Meaning the
concept looks good, but try to implement them and you're in a world of
trouble.)

I think that there's one DB that could work, and no, its not DB2 and no, its
not Oracle.
(I'll leave it to your imagination who's left.... ;-)

;-)

-G


>From: "Jean Georges Perrin" <jgp@jgp.net>
>To: "'Fernando Nunes'" <spam@domus.online.pt>,<informix-list@iiug.org>
>Subject: RE: IDS on a Mac?
>Date: Wed, 17 Oct 2007 22:44:43 -0700
>MIME-Version: 1.0
>Received: from perform.iiug.org ([216.177.38.211]) by
>bay0-mc5-f1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 17
>Oct 2007 22:45:11 -0700
>Received: from localhost (localhost [127.0.0.1])by perform.iiug.org
>(Postfix) with ESMTP id EB92EAD0B;Thu, 18 Oct 2007 01:45:04 -0400 (EDT)
>Received: from perform.iiug.org ([127.0.0.1])by localhost (perform.iiug.org
>[127.0.0.1]) (amavisd-new, port 10024)with ESMTP id vJYTizXqxTfM; Thu, 18
>Oct 2007 01:44:58 -0400 (EDT)
>Received: by perform.iiug.org (Postfix, from userid 60001)id 4EE0DAD08;
>Thu, 18 Oct 2007 01:44:58 -0400 (EDT)
>Received: from perform.iiug.org (localhost [127.0.0.1])by perform.iiug.org
>(Postfix) with ESMTP id 536BCA473;Thu, 18 Oct 2007 01:44:54 -0400 (EDT)
>Received: from localhost (localhost [127.0.0.1])by perform.iiug.org
>(Postfix) with ESMTP id 7B06DA46Ffor <informix-list@iiug.org>; Thu, 18 Oct
>2007 01:44:51 -0400 (EDT)
>Received: from perform.iiug.org ([127.0.0.1])by localhost (perform.iiug.org
>[127.0.0.1]) (amavisd-new, port 10024)with ESMTP id giD5HDayjpiI for
><informix-list@iiug.org>;Thu, 18 Oct 2007 01:44:50 -0400 (EDT)
>Received: by perform.iiug.org (Postfix, from userid 60001)id 80865A6CC;
>Thu, 18 Oct 2007 01:44:50 -0400 (EDT)
>Received: from moutng.kundenserver.de
>(moutng.kundenserver.de[212.227.126.188])by perform.iiug.org (Postfix) with
>SMTP id 4AB0CA46Ffor <informix-list@iiug.org>; Thu, 18 Oct 2007 01:44:48
>-0400 (EDT)
>Received: from taz (wsip-70-165-194-40.lv.lv.cox.net [70.165.194.40])by
>mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis)id
>0ML2xA-1IiOBa19d4-0001S3; Thu, 18 Oct 2007 07:44:47 +0200
>X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
>X-Message-Info:
>ZLIeWzn802T2hmZ0PdUhe3+A+Ae9VErc3tDmTaQnjRxDklexm pfA/Bgu1LyubvPfKE8B0Ao3i5VYswHyXnotYQ==
>X-Virus-Scanned: amavisd-new at iiug.org
>X-Original-To: informix-list@iiug.org
>Delivered-To: informix-list@iiug.org
>X-Virus-Scanned: amavisd-new at iiug.org
>X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
>References:
><mailman.245.1192668380.26742.informix-list@iiug.org><ff6c5c$hqf$1@aioe.org>
>Organization: JGP.net
>X-Mailer: Microsoft Office Outlook 12.0
>Thread-Index: AcgRJRaPWHwLHptQRX6p69NJ9NfB8wAJNd+Q
>Content-Language: en-us
>X-Provags-ID:
>V01U2FsdGVkX18pYJ/28UAwhSXQ+hJVXlviRF1jhBGpoEebBIKoQkl3ciIPND20HvVdO 97c3E2UhlGiQeyRl6sUNpjiZZMy34yud/XPxGI4tj7e9sQqmlkPdw==
>X-BeenThere: informix-list@iiug.org
>X-Mailman-Version: 2.1.6
>Precedence: list
>List-Id: "comp.databases.informix" <informix-list.iiug.org>
>List-Unsubscribe:
><http://www.iiug.org/mailman/listinfo/informix-list>,<mailto:informix-list-request@iiug.org?subject=unsubscribe>
>List-Archive: <http://www.iiug.org/pipermail/informix-list>
>List-Post: <mailto:informix-list@iiug.org>
>List-Help: <mailto:informix-list-request@iiug.org?subject=help>
>List-Subscribe:
><http://www.iiug.org/mailman/listinfo/informix-list>,<mailto:informix-list-request@iiug.org?subject=subscribe>
>Errors-To: informix-list-bounces@iiug.org
>Return-Path: informix-list-bounces@iiug.org
>X-OriginalArrivalTime: 18 Oct 2007 05:45:11.0665 (UTC)
>FILETIME=[0C98C610:01C8114A]
>
>Gumby's probably trahsed... specially as he works daily on O...
>
> > -----Original Message-----
> > From: informix-list-bounces@iiug.org [mailto:informix-list-
> > bounces@iiug.org] On Behalf Of Fernando Nunes
> > Sent: Wednesday, October 17, 2007 18:18
> > To: informix-list@iiug.org
> > Subject: Re: IDS on a Mac?
> >
> > Ian Michael Gumby wrote:
> > >
> > > This is interesting.
> > > Politically speaking that is...
> > >
> > > Wonder when Oracle will announce their port, or has Larry stepped
> > away
> > > from the helm and is no longer buddy buddy with Steve.
> > >
> > > Or could it be due to location based services and the iPhone getting
> > GPS?
> > >
> > > But hey! What do I know? ;-)
> > > (Seriously I know nothing... ;-)
> >
> > Wake up
> > It's already out there...
> > Regards.
> >
> >
> > --
> > Fernando Nunes
> > Portugal
> >
> > http://informix-technology.blogspot.com
> > My email works... but I don't check it frequently...
> > _______________________________________________
> > Informix-list mailing list
> > Informix-list@iiug.org
> > http://www.iiug.org/mailman/listinfo/informix-list
>
>_______________________________________________
>Informix-list mailing list
>Informix-list@iiug.org
>http://www.iiug.org/mailman/listinfo/informix-list

__________________________________________________ _______________
Boo!*Scare away worms, viruses and so much more! Try Windows Live OneCare
http://onecare.live.com/standard/en-...wl_hotmailnews

Ian Michael Gumby wrote:
> Unfortunately not.
>
> Silly me, I seem to recall that Larry Ellison sits on Apples board. Or
> am I dating myself? ;-)
>
> A certain Apple exec once joked to me (again, many moons ago) that if
> there were a database port to Apple, it would probably be an Oracle port
> since Steve and Larry are such good friends.

Apple certified Panther, 10.3.6, for Oracle 10.1.0.3 but then failed to
follow through with Tiger ending, for the second time, their fainted
hearted move into the enterprise data center. There are rumors that the
internal battles at Apple have led them to again make the move and that
Oracle 11g will have support for the MacOS but there is nothing
official.

It would be great if Apple finally decided it wasn't just a consumer
products company because they have some of the best servers around.
--
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 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:

> BTW, when will Oracle get their act together and do temp tables right?
> Anyone who's had to suffer through their bastardized "global" temp tables
> can appreciate that a *real* database allows users to create temp tables on
> the fly as part of their adhoc queries.
>
> __________________________________________________ _______________

How do Oracle temp tables work? What is the problem with them?

david@smooth1.co.uk wrote:
> On 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
>
>> BTW, when will Oracle get their act together and do temp tables right?
>> Anyone who's had to suffer through their bastardized "global" temp tables
>> can appreciate that a *real* database allows users to create temp tables on
>> the fly as part of their adhoc queries.
>>
>> __________________________________________________ _______________
>
> How do Oracle temp tables work? What is the problem with them?

In Oracle the tables are not temporary ... no need for them to be due to
the difference in locking and transaction architecture. Rather it is the
data within them that is transitory.

There are two types of temp tables in Oracle ... the first for example:

CREATE GLOBAL TEMPORARY TABLE gtt_zip2 (
zip_code VARCHAR2(5),
by_user VARCHAR2(30),
entry_date DATE)
ON COMMIT DELETE ROWS;

does precisely what the syntax indicates. The second has a different
behavior:

CREATE GLOBAL TEMPORARY TABLE gtt_zip3 (
zip_code VARCHAR2(5),
by_user VARCHAR2(30),
entry_date DATE)
ON COMMIT PRESERVE ROWS;

and empties itself at the end of a session.

The advantages of Oracle's version of temp tables relates specifically
to Oracle's use of undo segments and multiversion read consistency and
would make no sense in Informix thus I can understand the attitude. In
Oracle building Informix-type temp tables would be similarly bad design.

The OP's statement most likely stems from not understanding the
differences between the two products.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Serge Rielau wrote:
> DA Morgan wrote:
>> david@smooth1.co.uk wrote:
>>> On 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
>>>
>>>> BTW, when will Oracle get their act together and do temp tables right?
>>>> Anyone who's had to suffer through their bastardized "global" temp
>>>> tables
>>>> can appreciate that a *real* database allows users to create temp
>>>> tables on
>>>> the fly as part of their adhoc queries.
>>>>
>>>> __________________________________________________ _______________
>>>
>>> How do Oracle temp tables work? What is the problem with them?
>>
>> In Oracle the tables are not temporary ... no need for them to be due to
>> the difference in locking and transaction architecture. Rather it is the
>> data within them that is transitory.
>>
>> There are two types of temp tables in Oracle ... the first for example:
>>
>> CREATE GLOBAL TEMPORARY TABLE gtt_zip2 (
>> zip_code VARCHAR2(5),
>> by_user VARCHAR2(30),
>> entry_date DATE)
>> ON COMMIT DELETE ROWS;
>>
>> does precisely what the syntax indicates. The second has a different
>> behavior:
>>
>> CREATE GLOBAL TEMPORARY TABLE gtt_zip3 (
>> zip_code VARCHAR2(5),
>> by_user VARCHAR2(30),
>> entry_date DATE)
>> ON COMMIT PRESERVE ROWS;
>>
>> and empties itself at the end of a session.
>>
>> The advantages of Oracle's version of temp tables relates specifically
>> to Oracle's use of undo segments and multiversion read consistency and
>> would make no sense in Informix thus I can understand the attitude. In
>> Oracle building Informix-type temp tables would be similarly bad design.
> Huh? DB2 for zOS has the same kind of temp tables (they are in the SQL
> Standard actually).

Excuse me Serge but this isn't the DB2 usenet group. It's over there on
your right. This is Informix and Oracle's temp table implementation is
Oracle's.

>> 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)

True. But consider the improved efficiency of not running the DDL in the
first place. Consider that in Oracle the DDL is run one time during
schema creation and never run again. A substantially lower overhead than
300,000 people simultaneously connected and all running essentially
identical DDL to create 300,000 essentially identical tables. If
everyone, as in Oracle, can use the same table without any chance of
corrupting or altering another session's data no need for more than one.

> CREATED temporary tables on the other hand provide the same certainty
> about the table's signature as persistent tables.

With a lot of overhead running the DDL to create and then drop them.

> So how does Oracle get around this downside?
>
> Cheers
> Serge

You'll have to ask Mark. <g>

While you're at it ask him for a job. Tomorrow's forecast:
Redwood Shores 76 and sunny
Toronto 58 and raining

And it is only going to get a lot worse.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

david@smooth1.co.uk wrote:
> On 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
>
>> BTW, when will Oracle get their act together and do temp tables right?
>> Anyone who's had to suffer through their bastardized "global" temp tables
>> can appreciate that a *real* database allows users to create temp tables on
>> the fly as part of their adhoc queries.
>>
>> __________________________________________________ _______________
>
> How do Oracle temp tables work? What is the problem with them?
>

They are global, in that they are defined by someone with DBA
privileges, and the definitions are shared across all user sessions.
Different user sessions can then use them, and their specific data
extents are then local to that particular session, and can be temporary
(or can be persisted if required). So average joe blow user session
cannot create them.

There has always been some discussion about which approach is more
"correct". Obviously we at Oracle think this approach is better, for a
number of really good reasons. We could also do temp tables the same way
as informix and SQL Server, but have chosen to not implement them yet,
also for a number of good reasons. It does make migration from these
databases to Oracle a little problematic however

>> How do Oracle temp tables work? What is the problem with them?
>>
>
> They are global, in that they are defined by someone with DBA
> privileges, and the definitions are shared across all user sessions.
> Different user sessions can then use them, and their specific data
> extents are then local to that particular session, and can be temporary
> (or can be persisted if required). So average joe blow user session
> cannot create them.
>
> There has always been some discussion about which approach is more
> "correct". Obviously we at Oracle think this approach is better, for a
> number of really good reasons. We could also do temp tables the same way
> as informix and SQL Server, but have chosen to not implement them yet,
> also for a number of good reasons. It does make migration from these
> databases to Oracle a little problematic however

Apologies - I now see that I glommed into the thread a little late.
Something to do with a red-eye back from Argentina and leaping before I
look. Serge's description of the differences is a good one.

DA Morgan wrote:
> Serge Rielau wrote:
>> DA Morgan wrote:
>>> david@smooth1.co.uk wrote:
>>>> On 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
>>>>
>>>>> BTW, when will Oracle get their act together and do temp tables right?
>>>>> Anyone who's had to suffer through their bastardized "global" temp
>>>>> tables
>>>>> can appreciate that a *real* database allows users to create temp
>>>>> tables on
>>>>> the fly as part of their adhoc queries.
>>>>>
>>>>> __________________________________________________ _______________
>>>>
>>>> How do Oracle temp tables work? What is the problem with them?
>>>
>>> In Oracle the tables are not temporary ... no need for them to be due to
>>> the difference in locking and transaction architecture. Rather it is the
>>> data within them that is transitory.
>>>
>>> There are two types of temp tables in Oracle ... the first for example:
>>>
>>> CREATE GLOBAL TEMPORARY TABLE gtt_zip2 (
>>> zip_code VARCHAR2(5),
>>> by_user VARCHAR2(30),
>>> entry_date DATE)
>>> ON COMMIT DELETE ROWS;
>>>
>>> does precisely what the syntax indicates. The second has a different
>>> behavior:
>>>
>>> CREATE GLOBAL TEMPORARY TABLE gtt_zip3 (
>>> zip_code VARCHAR2(5),
>>> by_user VARCHAR2(30),
>>> entry_date DATE)
>>> ON COMMIT PRESERVE ROWS;
>>>
>>> and empties itself at the end of a session.
>>>
>>> The advantages of Oracle's version of temp tables relates specifically
>>> to Oracle's use of undo segments and multiversion read consistency and
>>> would make no sense in Informix thus I can understand the attitude. In
>>> Oracle building Informix-type temp tables would be similarly bad design.
>> Huh? DB2 for zOS has the same kind of temp tables (they are in the SQL
>> Standard actually).
>
> Excuse me Serge but this isn't the DB2 usenet group. It's over there on
> your right. This is Informix and Oracle's temp table implementation is
> Oracle's.
This has nothing to do with implementation. Semantics dictate
implementation. Nothing you described has anything to do with Orcale's
vs. IDSs (and DB2, and SQL Server's) design.
It is about DECLAREd TEMPS vs. CREATEd TEMPS.
A DECLARE'd temp doesn't have any of that heavy code path overhead you
describe. Whether you call it an index by table or a DGTT or a local temp...

If you could take of those blinders and think of SQL as a language
instead of as a binary shipped by Oracle vs. IBM you could follow me.

Cheers
Serge

PS: There is more to once life choices than Fahrenheit. I'm in the right
spot at the right time.

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Mark Townsend wrote:
>>> How do Oracle temp tables work? What is the problem with them?
>>>
>>
>> They are global, in that they are defined by someone with DBA
>> privileges, and the definitions are shared across all user sessions.
>> Different user sessions can then use them, and their specific data
>> extents are then local to that particular session, and can be
>> temporary (or can be persisted if required). So average joe blow user
>> session cannot create them.
>>
>> There has always been some discussion about which approach is more
>> "correct". Obviously we at Oracle think this approach is better, for a
>> number of really good reasons. We could also do temp tables the same
>> way as informix and SQL Server, but have chosen to not implement them
>> yet, also for a number of good reasons. It does make migration from
>> these databases to Oracle a little problematic however
>
> Apologies - I now see that I glommed into the thread a little late.
> Something to do with a red-eye back from Argentina and leaping before I
> look. Serge's description of the differences is a good one.
Tx, so is yours. Also agree on the migration issue. The impedance
mismatch is a challenge.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Serge Rielau wrote:
> DA Morgan wrote:
>> Serge Rielau wrote:
>>> DA Morgan wrote:
>>>> david@smooth1.co.uk wrote:
>>>>> On 18 Oct, 16:29, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
>>>>>
>>>>>> BTW, when will Oracle get their act together and do temp tables
>>>>>> right?
>>>>>> Anyone who's had to suffer through their bastardized "global" temp
>>>>>> tables
>>>>>> can appreciate that a *real* database allows users to create temp
>>>>>> tables on
>>>>>> the fly as part of their adhoc queries.
>>>>>>
>>>>>> __________________________________________________ _______________
>>>>>
>>>>> How do Oracle temp tables work? What is the problem with them?
>>>>
>>>> In Oracle the tables are not temporary ... no need for them to be
>>>> due to
>>>> the difference in locking and transaction architecture. Rather it is
>>>> the
>>>> data within them that is transitory.
>>>>
>>>> There are two types of temp tables in Oracle ... the first for example:
>>>>
>>>> CREATE GLOBAL TEMPORARY TABLE gtt_zip2 (
>>>> zip_code VARCHAR2(5),
>>>> by_user VARCHAR2(30),
>>>> entry_date DATE)
>>>> ON COMMIT DELETE ROWS;
>>>>
>>>> does precisely what the syntax indicates. The second has a different
>>>> behavior:
>>>>
>>>> CREATE GLOBAL TEMPORARY TABLE gtt_zip3 (
>>>> zip_code VARCHAR2(5),
>>>> by_user VARCHAR2(30),
>>>> entry_date DATE)
>>>> ON COMMIT PRESERVE ROWS;
>>>>
>>>> and empties itself at the end of a session.
>>>>
>>>> The advantages of Oracle's version of temp tables relates specifically
>>>> to Oracle's use of undo segments and multiversion read consistency and
>>>> would make no sense in Informix thus I can understand the attitude. In
>>>> Oracle building Informix-type temp tables would be similarly bad
>>>> design.
>>> Huh? DB2 for zOS has the same kind of temp tables (they are in the
>>> SQL Standard actually).
>>
>> Excuse me Serge but this isn't the DB2 usenet group. It's over there on
>> your right. This is Informix and Oracle's temp table implementation is
>> Oracle's.
> This has nothing to do with implementation. Semantics dictate
> implementation. Nothing you described has anything to do with Orcale's
> vs. IDSs (and DB2, and SQL Server's) design.
> It is about DECLAREd TEMPS vs. CREATEd TEMPS.
> A DECLARE'd temp doesn't have any of that heavy code path overhead you
> describe. Whether you call it an index by table or a DGTT or a local
> temp...
>
> If you could take of those blinders and think of SQL as a language
> instead of as a binary shipped by Oracle vs. IBM you could follow me.
>
> Cheers
> Serge
>
> PS: There is more to once life choices than Fahrenheit. I'm in the right
> spot at the right time.

You and Mark seem to have a bit of a disagreement with respect to the
proper implementation. No doubt that will be resolved with new
"compatibility" features.

My point was that you were responding in an Informix group by discussing
DB2. Had your response been about Informix I'd not have pointed out
where the discussion was taking place.

I don't open up discussions here about Oracle ... those who are regulars
here do. In the same way I think the same should apply to DB2. Don't
bring it up unless they do. This is, after all, their group, not ours.
My entry into this thread was that we have had Apple twice cozy up to
Oracle just to walk away and orphan those who used their hardware and
OS, however great, and I didn't want those here to not have a bit of
that history to consider. What DB2 has to do with IDS and Mac? I still
can't make the connection.

BTW: Obnoxio ... likely be in B'ham first week of December. I think I
still owe you a drink if you are in the neighborhood.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)