Re: Let's approach stored procedures

2001-09-13 Thread Endre Stølsvik

On Tue, 11 Sep 2001, Arnulf Kristiansen wrote:

| I have just started to look into the stored procedure issue. We will come up with a
| definite plan within a short period of time.

But does this mean that you won't welcome any other initiative or ideas
from other programmers?

|
| It is true that there are solutions that would make transitions from another DBMS to 
|MySQL
| easier however, I am leaning towards the ANSI standard rather than PL/SQL or 
|Transact-SQL.
| If we still need to provide other languages or subsets of languages for 
|compatibility and
| easy transition, we might provide this later.

Again, if two persons (groups) were working on this at the same time, then
you could take ideas from both, ditch one of the implementations and use
the other one's ideas in the remaining. Much faster development, and will
problaby be better.

| Widening the existing SQL functionality is most likely going to be the
| first step.

Why is this a first step? As I see it, SQL (as in the query language) is a
rather different thing than an scripting language or similar (read
stored procedures).

-- 
Mvh,
Endre.



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-13 Thread James Clifford

newbie DB developer question
Are stored procedures scripts or compiled code ?
James

- Original Message -
From: Endre Stølsvik [EMAIL PROTECTED]
To: Arnulf Kristiansen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, September 13, 2001 5:09 PM
Subject: Re: Let's approach stored procedures


On Tue, 11 Sep 2001, Arnulf Kristiansen wrote:

| I have just started to look into the stored procedure issue. We will come
up with a
| definite plan within a short period of time.

But does this mean that you won't welcome any other initiative or ideas
from other programmers?

|
| It is true that there are solutions that would make transitions from
another DBMS to MySQL
| easier however, I am leaning towards the ANSI standard rather than PL/SQL
or Transact-SQL.
| If we still need to provide other languages or subsets of languages for
compatibility and
| easy transition, we might provide this later.

Again, if two persons (groups) were working on this at the same time, then
you could take ideas from both, ditch one of the implementations and use
the other one's ideas in the remaining. Much faster development, and will
problaby be better.

| Widening the existing SQL functionality is most likely going to be the
| first step.

Why is this a first step? As I see it, SQL (as in the query language) is a
rather different thing than an scripting language or similar (read
stored procedures).

--
Mvh,
Endre.



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail
[EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-13 Thread Arnulf Kristiansen

Endre Stølsvik wrote:

 On Tue, 11 Sep 2001, Arnulf Kristiansen wrote:


 | I have just started to look into the stored procedure issue. We will come up with a
 | definite plan within a short period of time.

 But does this mean that you won't welcome any other initiative or ideas
 from other programmers?


Absolutely not. All ideas and initiatives are welcome. I will however try to 
coordinate efforts
as best i can.


 |
 | It is true that there are solutions that would make transitions from another DBMS 
to MySQL
 | easier however, I am leaning towards the ANSI standard rather than PL/SQL or 
Transact-SQL.
 | If we still need to provide other languages or subsets of languages for 
compatibility and
 | easy transition, we might provide this later.

 Again, if two persons (groups) were working on this at the same time, then
 you could take ideas from both, ditch one of the implementations and use
 the other one's ideas in the remaining. Much faster development, and will
 problaby be better.


I don't disagree. Which ever way we go I think we will end up with quite a few 
additions to make

it easier on people with one preference or another and to facilitate transitions to 
MySQL. A lot

of fundamental stuff is going to be common to the different variants and I like to 
concentrate
on something rather small for starters, keeping the larger objective in mind.


 | Widening the existing SQL functionality is most likely going to be the
 | first step.

 Why is this a first step? As I see it, SQL (as in the query language) is a
 rather different thing than an scripting language or similar (read
 stored procedures).

This can be done relatively fast, but I agree it will is not the same thing.

/Arnulf






-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-13 Thread Arnulf Kristiansen

James Clifford wrote:

 newbie DB developer question
 Are stored procedures scripts or compiled code ?
 James


It can be either. Compiled code generally offers greater performance while something 
that
has to be accepted by an interpreter will be more robust, provided the interpreter is
solid. When it comes to compiled code you can either have a built in compiler or you 
can
compile you code yourself and present the executable to the server one way or another 
(like
UDF's).

/Arnulf



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-11 Thread Arnulf Kristiansen

I have just started to look into the stored procedure issue. We will come up with a
definite plan within a short period of time.

It is true that there are solutions that would make transitions from another DBMS to 
MySQL
easier however, I am leaning towards the ANSI standard rather than PL/SQL or 
Transact-SQL.
If we still need to provide other languages or subsets of languages for compatibility 
and
easy transition, we might provide this later. Widening the existing SQL functionality 
is
most likely going to be the first step. This will go a long way to provide the 
capabilities
needed in most cases. In some cases it would be nice to be able to use a “real” 
programming
language external to the server. We will address this as well.


/Arnulf




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-11 Thread Jeremy Zawodny

On Mon, Sep 10, 2001 at 10:23:10AM +0200, Endre Stølsvik wrote:
 
 The proprietary issues might of course be a huge problem. Anyone
 knows anything about this?

Well, the PostreSQL folks managed to implement a stored procedure
language that looks, feels, and acts remarkably like Oracle's.  So
it's probably not that big a deal...

Jeremy
-- 
Jeremy D. Zawodny, [EMAIL PROTECTED]
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

MySQL 3.23.41-max: up 5 days, processed 109,565,020 queries (246/sec. avg)

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-11 Thread Claudio Cicali

At 09:40 AM 9/11/01 +0200, Arnulf Kristiansen wrote:
I have just started to look into the stored procedure issue. We will come 
up with a
definite plan within a short period of time.

It is true that there are solutions that would make transitions from 
another DBMS to MySQL
easier however, I am leaning towards the ANSI standard rather than PL/SQL 
or Transact-SQL.

Are the ANSI standard online somewhere ? I would be glad to read them too :)



--
Claudio Cicali aka FleXer
[EMAIL PROTECTED]
http://www.flexer.it
GPG Key Fingerprint = 2E12 64D5 E5F5 2883 0472 4CFF 3682 E786 555D 25CE


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-10 Thread Frank Fisher

Adams, Bill TQO wrote:

 The other thing about all of this is that MySQL is feature rich so most people
 might not have a use for stored procedures.  Unlike, say, Informix which has
 not build in MIN or MAX function.


Depending on the way you define things, MIN and MAX are essentially 
stored procedures that were programmed into MySQL.  Why not let us make 
our own?

Frank.


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-10 Thread Endre Stølsvik

On Fri, 7 Sep 2001, Robert Alexander wrote:

| Hi Claudio,
|
| I think having the functionality of stored procedures would be a
| wonderful addition to MySQL. Let me be the first to say a hearty
| 'Thank you!' for your very generous offer to devote your vacation time
| to this task.

I definately agree, and I'm reading all those other emails wondering
whether people are crazy?! This guy is saying that he wants to devote
considerable time in making stored procedures, and people start to argue
against him with sarcasm and everyhting.

|
| I like Oracle's PL/SQL. I've used it a fair amount, and it get's the
| job done. PL/SQL = Procedural SQL -- SQL plus procedural logic. This
| has the advantage of being a language that uses the SQL that we all
| already know and love, plus enough procedural things -- loops,
| conditionals, etc. -- to implement logic. It's more a programming
| language than just a query language. This is a good thing.

One LARGE point in PL is that, yes, it's Oracle's, and they have a large
industy momentum and are kind of the defacto industry standard. MySQL
could steal a lot of momentum from Oracle if you could port your
application to MySQL by just swapping the backend of your application. And
this is definately not negative for a Open Source project. (I'd like to
see MySQL be a _real_ alternative to the big-dudes. Let the OS community
dominate the whole serverside market totally!)

Oracle's PL/SQL would be a _huge_ benefit for MySQL, I believe.

Transactions, subqueries and stored procudures NOW!

|
| That being said, I don't think re-implementing PL/SQL is necessarily
| the way to go for MySQL. There may indeed be proprietary issues
| (though I'm not sure) and I think it'd be possible to take a more
| 'open source' approach.

The proprietary issues might of course be a huge problem. Anyone knows
anything about this?

|
| Let's remember what we want to accomplish with stored procs; that is,
| the ability to store server-side logic where we can implement such
| things as business rules, and ensure consistency in the way
| 'front-ends' of whatever flavour (and probably written by different
| programmers) perform transactions with the dataset.

Also, remember that _speed_ is a _big_ thing here.
  If your application needs to grep through a large amount of data and
compare lots of rows from different tables in an elaborate way, then you'd
have to transfer immense amounts of data through the TCP stack (and maybe
even though a couple of ethernet cards and a cable!) or anyways between
different tiers and data representations in your system (think e.g.
Java?). This is done _much_ more effeciently with a couple of stored
procedures.


-- 
Mvh,
Endre


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-10 Thread Dana Powers

 Depending on the way you define things, MIN and MAX are essentially
 stored procedures that were programmed into MySQL.  Why not let us make
 our own?

This is already possible with Aggregate UDF 's. Check the manual here:
http://www.mysql.com/doc/A/d/Adding_functions.html

dpk


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Let's approach stored procedures

2001-09-07 Thread Claudio Cicali


I think this is a little OT here, so after reading please
indicate me where to talk about this subject.

I'm a skilled programmer in C, C++ and others progr. lang.
I have also a solid background in SQL and some RDMS
(DB2, Oracle, SQLServer, and of course, Mysql).

I'm going to attend a long period of holidays (finally) so,
I thought: why don't try to implement stored procedures
in mysql ?

Now, on with the questions:

I think that MySQL programmers had yet thinked on some
way to implement sp, and I'd wish that someone say me:
- No, dude it's impossible/too hard
- No, dude, we are in the way to finish that by ourselves
- No, dude, we never insert big patches in our official
   distribution branch, that does not belong to us

Or, better, something more optimistic...

I don't want to loose my time, in something that you
know is impossible or too hard to get.

Another question:

At a first glance, I think Oracle PL/SQL is the best (afaik)
programming language for sp, but, in the case we implement
that language, should we go against some Oracle copytight
infringment ?

That's all, for now.

database, mysql









-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Adams, Bill TQO

Claudio Cicali wrote:

 I'm going to attend a long period of holidays (finally) so,
 I thought: why don't try to implement stored procedures
 in mysql ?


Someone did it with perl.
http://software.tangent.org/article.pl?sid=01/08/23/0817244mode=threadthreshold=

 At a first glance, I think Oracle PL/SQL is the best (afaik)
 programming language for sp, but, in the case we implement

sarcasm
You should implement it in Python so the Perl vs. Python flame wars can rage
from within MySQL too.
/sarcasm

--Bill



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Ed Carp

Claudio Cicali ([EMAIL PROTECTED]) writes:

 At a first glance, I think Oracle PL/SQL is the best (afaik)
 programming language for sp, but, in the case we implement
 that language, should we go against some Oracle copytight
 infringment ?

Why would you want to do such a thing? Isn't SQL good enough? I'm just trying to 
figure out your reasoning here, besides the same argument used by the XML crowd of 
it's the latest/greatest do-all-be-all-end-all, so everyone should be using it type 
of nonsense.
--
Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 - http://www.pobox.com/~erc

Squished Mosquito, Inc.
Internet Applications Development
Escapade Server-Side Scripting Language Development Team
http://www.squishedmosquito.com
Pensacola - Dallas - Dresden - London

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Claudio Cicali

At 10.44 07/09/2001 -0500, Ed Carp wrote:
Claudio Cicali ([EMAIL PROTECTED]) writes:

  At a first glance, I think Oracle PL/SQL is the best (afaik)
  programming language for sp, but, in the case we implement
  that language, should we go against some Oracle copytight
  infringment ?

Why would you want to do such a thing? Isn't SQL good enough? I'm just 
trying to figure out your reasoning here, besides the same argument used 
by the XML crowd of it's the latest/greatest do-all-be-all-end-all, so 
everyone should be using it type of nonsense.

Nice question, overall.

Answers (partial list):

- it's cool
- where I work, we have a HUGE database-driven web-application. A lot of
   our businness logic is implemented via stored procedures, that
   act as black boxes for the web-designers.
   Think of enterprise java beans.
   They are not nonsense or such. They are usefull.
   (I know, you can use ejb with JDBS and mysql..., but if you want to have
   some logic incapsualted, you should use some kind of component)
- sp extends the RDBMS itself in its functionality. Think about some stupid
   check_fiscal_code() or insert_new_customer().
   Web designers use the insert_new_customer, instead of using SQL
   directly.

I think that there are others examples, but this is my point.




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Cal Evans

My $.02,

Stick with the ANSI standard. (ANSI99?) Do not try to implement either
PL/SQL or T/SQL. Please do not implement PERL (or Python) , Java, PHP or any
other procedural or OO language in stored procedures.  Speaking form
experience, all this does is blur the lines of that the database should do
and what the middle tier should do.

Whatever you do, do not adversely impact the speed at which MySQL runs.

Happy to Alpha/Beta test any patches you may create,

IMHO,
Cal
*
* Cal Evans
* Senior Internet Dreamer
* http://www.calevans.com
*
- Original Message -
From: Claudio Cicali [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 10:30
Subject: Let's approach stored procedures



 I think this is a little OT here, so after reading please
 indicate me where to talk about this subject.

 I'm a skilled programmer in C, C++ and others progr. lang.
 I have also a solid background in SQL and some RDMS
 (DB2, Oracle, SQLServer, and of course, Mysql).

 I'm going to attend a long period of holidays (finally) so,
 I thought: why don't try to implement stored procedures
 in mysql ?

 Now, on with the questions:

 I think that MySQL programmers had yet thinked on some
 way to implement sp, and I'd wish that someone say me:
 - No, dude it's impossible/too hard
 - No, dude, we are in the way to finish that by ourselves
 - No, dude, we never insert big patches in our official
distribution branch, that does not belong to us

 Or, better, something more optimistic...

 I don't want to loose my time, in something that you
 know is impossible or too hard to get.

 Another question:

 At a first glance, I think Oracle PL/SQL is the best (afaik)
 programming language for sp, but, in the case we implement
 that language, should we go against some Oracle copytight
 infringment ?

 That's all, for now.

 database, mysql









 -
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list archive)

 To request this thread, e-mail [EMAIL PROTECTED]
 To unsubscribe, e-mail
[EMAIL PROTECTED]
 Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




RE: Let's approach stored procedures

2001-09-07 Thread Ed Carp

 - it's cool

Not a valid business reason.

 - where I work, we have a HUGE database-driven web-application. A lot of
our business logic is implemented via stored procedures, that
act as black boxes for the web-designers.
Think of enterprise java beans.
They are not nonsense or such. They are usefull.

Stored procedures aren't nonsense, but using or re-implementing a particular
vendor's implementation is.

(I know, you can use ejb with JDBS and mysql..., but if you
 want to have
some logic incapsualted, you should use some kind of component)
 - sp extends the RDBMS itself in its functionality. Think about
 some stupid
check_fiscal_code() or insert_new_customer().
Web designers use the insert_new_customer, instead of using SQL
directly.

These are all great reasons to implement stored procedures, not Oracle
PL/SQL. I think I'm missing your point here...
--
Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
http://www.pobox.com/~erc

Squished Mosquito, Inc.
Internet Applications Development
Escapade Server-Side Scripting Language Development Team
http://www.squishedmosquito.com
Pensacola - Dallas - Dresden - London


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Cal Evans

Ed,

Stored procedures allow you to pre-compile and re-use code easily. They also
make transactions easier. (At least from one point of view) It's not like
the XML argument. SPs are also part of the ANSI spec so to be compliant,
MySQL will have to have them. XML is not part of the ANSI-SQL spec.

IMHO,
Cal
*
* Cal Evans
* Senior Internet Dreamer
* http://www.calevans.com
*
- Original Message -
From: Ed Carp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 10:44
Subject: Re: Let's approach stored procedures


 Claudio Cicali ([EMAIL PROTECTED]) writes:

  At a first glance, I think Oracle PL/SQL is the best (afaik)
  programming language for sp, but, in the case we implement
  that language, should we go against some Oracle copytight
  infringment ?

 Why would you want to do such a thing? Isn't SQL good enough? I'm just
trying to figure out your reasoning here, besides the same argument used by
the XML crowd of it's the latest/greatest do-all-be-all-end-all, so
everyone should be using it type of nonsense.
 --
 Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
http://www.pobox.com/~erc

 Squished Mosquito, Inc.
 Internet Applications Development
 Escapade Server-Side Scripting Language Development Team
 http://www.squishedmosquito.com
 Pensacola - Dallas - Dresden - London

 -
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list archive)

 To request this thread, e-mail [EMAIL PROTECTED]
 To unsubscribe, e-mail
[EMAIL PROTECTED]
 Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Ed Carp

Cal Evans ([EMAIL PROTECTED]) writes:

 Stick with the ANSI standard. (ANSI99?) Do not try to implement either
 PL/SQL or T/SQL. Please do not implement PERL (or Python) , Java, PHP or any
 other procedural or OO language in stored procedures.  Speaking form
 experience, all this does is blur the lines of that the database should do
 and what the middle tier should do.

BRAVO!  At last, the voice of common sense is heard :)

--
Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 - http://www.pobox.com/~erc

Squished Mosquito, Inc.
Internet Applications Development
Escapade Server-Side Scripting Language Development Team
http://www.squishedmosquito.com
Pensacola - Dallas - Dresden - London

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




RE: Let's approach stored procedures

2001-09-07 Thread Claudio Cicali

At 11.03 07/09/2001 -0500, Ed Carp wrote:
  - it's cool

Not a valid business reason.

  - where I work, we have a HUGE database-driven web-application. A lot of
 our business logic is implemented via stored procedures, that
 act as black boxes for the web-designers.
 Think of enterprise java beans.
 They are not nonsense or such. They are usefull.

Stored procedures aren't nonsense, but using or re-implementing a particular
vendor's implementation is.

 (I know, you can use ejb with JDBS and mysql..., but if you
  want to have
 some logic incapsualted, you should use some kind of component)
  - sp extends the RDBMS itself in its functionality. Think about
  some stupid
 check_fiscal_code() or insert_new_customer().
 Web designers use the insert_new_customer, instead of using SQL
 directly.

These are all great reasons to implement stored procedures, not Oracle
PL/SQL. I think I'm missing your point here...

No, sorry, it's me :)
I haven't got your point. All, clear, now.

bye


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Cal Evans

Let me clarify.

I'm in great favor of stored procedures in MySQL.  It is my HO that all
interaction with the database should take place within stored procedures.
But the ANSI standard is sufficient for most interaction with the database.
My call to arms was to resist the urge that Oracle could not, implementing a
full-blown language within the context of SPs. (Oracle used Java, rumor has
it that MS will implement C#, Java's moronic cousin, in a future release)

Again, IMHO, take it for what it's worth.
Cal
*
* Cal Evans
* Senior Internet Dreamer
* http://www.calevans.com
*
- Original Message -
From: Ed Carp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 11:14
Subject: Re: Let's approach stored procedures


 Cal Evans ([EMAIL PROTECTED]) writes:

  Stick with the ANSI standard. (ANSI99?) Do not try to implement either
  PL/SQL or T/SQL. Please do not implement PERL (or Python) , Java, PHP or
any
  other procedural or OO language in stored procedures.  Speaking form
  experience, all this does is blur the lines of that the database should
do
  and what the middle tier should do.

 BRAVO!  At last, the voice of common sense is heard :)

 --
 Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
http://www.pobox.com/~erc

 Squished Mosquito, Inc.
 Internet Applications Development
 Escapade Server-Side Scripting Language Development Team
 http://www.squishedmosquito.com
 Pensacola - Dallas - Dresden - London



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread William R. Mussatto

On Fri, 7 Sep 2001, Cal Evans wrote:

 Date: Fri, 7 Sep 2001 11:05:27 -0500
 From: Cal Evans [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], [EMAIL PROTECTED], Ed Carp [EMAIL PROTECTED]
 Subject: Re: Let's approach stored procedures
 
 Ed,
 
 Stored procedures allow you to pre-compile and re-use code easily. They also
 make transactions easier. (At least from one point of view) It's not like
 the XML argument. SPs are also part of the ANSI spec so to be compliant,
 MySQL will have to have them. XML is not part of the ANSI-SQL spec.
 
 IMHO,
 Cal
 *
 * Cal Evans
 * Senior Internet Dreamer
 * http://www.calevans.com
 *
Since the current version of MySQL is open source you could write stored 
procedures in the same language used in (until recently) DB2, i.e., C.  I 
don't think that would be useful for those of us who are C challanged... 
I think the real question is, can it be done w/o impacting performance.  
Related question, what language or psuedo language would be used to code 
them.

 - Original Message -
 From: Ed Carp [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Friday, September 07, 2001 10:44
 Subject: Re: Let's approach stored procedures
 
 
  Claudio Cicali ([EMAIL PROTECTED]) writes:
 
   At a first glance, I think Oracle PL/SQL is the best (afaik)
   programming language for sp, but, in the case we implement
   that language, should we go against some Oracle copytight
   infringment ?
 
  Why would you want to do such a thing? Isn't SQL good enough? I'm just
 trying to figure out your reasoning here, besides the same argument used by
 the XML crowd of it's the latest/greatest do-all-be-all-end-all, so
 everyone should be using it type of nonsense.
  --
  Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
 http://www.pobox.com/~erc
 
  Squished Mosquito, Inc.
  Internet Applications Development
  Escapade Server-Side Scripting Language Development Team
  http://www.squishedmosquito.com
  Pensacola - Dallas - Dresden - London
 
  -
  Before posting, please check:
 http://www.mysql.com/manual.php   (the manual)
 http://lists.mysql.com/   (the list archive)
 
  To request this thread, e-mail [EMAIL PROTECTED]
  To unsubscribe, e-mail
 [EMAIL PROTECTED]
  Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
 
 
 
 
 -
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list archive)
 
 To request this thread, e-mail [EMAIL PROTECTED]
 To unsubscribe, e-mail [EMAIL PROTECTED]
 Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
 

Sincerely,

William Mussatto, Senior Systems Engineer
CyberStrategies, Inc
ph. 909-920-9154 ext. 27


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Adams, Bill TQO

Cal Evans wrote:

 Stored procedures allow you to pre-compile and re-use code easily. They also
 make transactions easier. (At least from one point of view) It's not like
 the XML argument. SPs are also part of the ANSI spec so to be compliant,
 MySQL will have to have them. XML is not part of the ANSI-SQL spec.

The other thing about all of this is that MySQL is feature rich so most people
might not have a use for stored procedures.  Unlike, say, Informix which has
not build in MIN or MAX function.

Again, if having stored procedures built in does not slow down queries that do
not use stored procedures, I do not see what the harm is.

--Bill


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Cal Evans

SQL. Stored procedures are loosely analogous to shell scripts.  No
additional language constructs, outside of what is defined in the ANSI-SQL
standard are necessary for them.

IMHO, C would be a bad thing.
My $.02 worth, (which is worth less, each time I post)
Cal
*
* Cal Evans
* Senior Internet Dreamer
* http://www.calevans.com
*
- Original Message -
From: William R. Mussatto [EMAIL PROTECTED]
To: Cal Evans [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ed Carp [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 11:27
Subject: Re: Let's approach stored procedures


 On Fri, 7 Sep 2001, Cal Evans wrote:

  Date: Fri, 7 Sep 2001 11:05:27 -0500
  From: Cal Evans [EMAIL PROTECTED]
  To: [EMAIL PROTECTED], [EMAIL PROTECTED], Ed Carp [EMAIL PROTECTED]
  Subject: Re: Let's approach stored procedures
 
  Ed,
 
  Stored procedures allow you to pre-compile and re-use code easily. They
also
  make transactions easier. (At least from one point of view) It's not
like
  the XML argument. SPs are also part of the ANSI spec so to be compliant,
  MySQL will have to have them. XML is not part of the ANSI-SQL spec.
 
  IMHO,
  Cal
  *
  * Cal Evans
  * Senior Internet Dreamer
  * http://www.calevans.com
  *
 Since the current version of MySQL is open source you could write stored
 procedures in the same language used in (until recently) DB2, i.e., C.  I
 don't think that would be useful for those of us who are C challanged...
 I think the real question is, can it be done w/o impacting performance.
 Related question, what language or psuedo language would be used to code
 them.

  - Original Message -
  From: Ed Carp [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Sent: Friday, September 07, 2001 10:44
  Subject: Re: Let's approach stored procedures
 
 
   Claudio Cicali ([EMAIL PROTECTED]) writes:
  
At a first glance, I think Oracle PL/SQL is the best (afaik)
programming language for sp, but, in the case we implement
that language, should we go against some Oracle copytight
infringment ?
  
   Why would you want to do such a thing? Isn't SQL good enough? I'm just
  trying to figure out your reasoning here, besides the same argument used
by
  the XML crowd of it's the latest/greatest do-all-be-all-end-all, so
  everyone should be using it type of nonsense.
   --
   Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
  http://www.pobox.com/~erc
  
   Squished Mosquito, Inc.
   Internet Applications Development
   Escapade Server-Side Scripting Language Development Team
   http://www.squishedmosquito.com
   Pensacola - Dallas - Dresden - London
  
   -
   Before posting, please check:
  http://www.mysql.com/manual.php   (the manual)
  http://lists.mysql.com/   (the list archive)
  
   To request this thread, e-mail [EMAIL PROTECTED]
   To unsubscribe, e-mail
  [EMAIL PROTECTED]
   Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
  
  
 
 
  -
  Before posting, please check:
 http://www.mysql.com/manual.php   (the manual)
 http://lists.mysql.com/   (the list archive)
 
  To request this thread, e-mail [EMAIL PROTECTED]
  To unsubscribe, e-mail
[EMAIL PROTECTED]
  Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
 

 Sincerely,

 William Mussatto, Senior Systems Engineer
 CyberStrategies, Inc
 ph. 909-920-9154 ext. 27




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




RE: Let's approach stored procedures

2001-09-07 Thread Ed Carp

 Since the current version of MySQL is open source you could write stored
 procedures in the same language used in (until recently) DB2, i.e., C.  I

Why reinvent the wheel? MySQL already has user-defined function capability
in C.

 Related question, what language or psuedo language would be used to code
 them.


SQL, obviously. Anything else would be insane.
--
Ed Carp, N7EKG  -  [EMAIL PROTECTED]  -  214/341-4420 -
http://www.pobox.com/~erc

Squished Mosquito, Inc.
Internet Applications Development
Escapade Server-Side Scripting Language Development Team
http://www.squishedmosquito.com
Pensacola - Dallas - Dresden - London


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Let's approach stored procedures

2001-09-07 Thread Dana Powers

Claudio Cicali ([EMAIL PROTECTED]) writes:
 - where I work, we have a HUGE database-driven web-application. A lot of
our businness logic is implemented via stored procedures, that
act as black boxes for the web-designers.
Think of enterprise java beans.
They are not nonsense or such. They are usefull.
(I know, you can use ejb with JDBS and mysql..., but if you want to
have
some logic incapsualted, you should use some kind of component)
 - sp extends the RDBMS itself in its functionality. Think about some
stupid
check_fiscal_code() or insert_new_customer().
Web designers use the insert_new_customer, instead of using SQL
directly.

I have found that the same thing can be achieved using a middle layer like
XML-RPC or SOAP. This also allows business logic to appear closer to native
functions in your web programming language than still having to use SQL. For
example, if you use mod_perl, you can just call 'insert_new_customer()' from
perl and this gets transmorgified across XML-RPC to a transaction in the
database with very little extra code.

Ive been thinking/working on this problem for a while and it seems that
there are 2 major issues:

1. Ability to create arbitrary functions in some language X.
2. Ability for arbitrary function to call back into the database.

Problem 1 is pretty straightforward. I've even put a patch for an older
version of mysql up at http://www.tanisconsulting.com/mysql-perl.html that
creates a language 'plugin' architecture and implements perl for starters.
( python would be easy, as would javascript or lisp etc.. I just happen to
be a perl hacker )

Problem 2 is not, or at least I havent come up with a good, non-intrusive
way to accomplish it yet.

dpk


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




RE: Let's approach stored procedures

2001-09-07 Thread Robert Alexander

Hi Claudio,

I think having the functionality of stored procedures would be a wonderful addition to 
MySQL. Let me be the first to say a hearty 'Thank you!' for your very generous offer 
to devote your vacation time to this task.

I like Oracle's PL/SQL. I've used it a fair amount, and it get's the job done. PL/SQL 
= Procedural SQL -- SQL plus procedural logic. This has the advantage of being a 
language that uses the SQL that we all already know and love, plus enough procedural 
things -- loops, conditionals, etc. -- to implement logic. It's more a programming 
language than just a query language. This is a good thing.

That being said, I don't think re-implementing PL/SQL is necessarily the way to go for 
MySQL. There may indeed be proprietary issues (though I'm not sure) and I think it'd 
be possible to take a more 'open source' approach.

Let's remember what we want to accomplish with stored procs; that is, the ability to 
store server-side logic where we can implement such things as business rules, and 
ensure consistency in the way 'front-ends' of whatever flavour (and probably written 
by different programmers) perform transactions with the dataset.

In my opinion, it'd be great if the choice of the server-side procedural language 
could be left up to the developer/DBA. Perhaps a method whereby the stored proc would 
then call a script in [language-of-choice] and then accept the returned results.

I realize that that method is not as tightly 'married' to MySQL as an internal 
PL/SQL-like language would be and, depending on the scripting language, may have a bit 
of a performance hit, but it does allow more freedom for the DBA in the tools to 
choose from.

Just some thoughts. They're open-source, of course, so do with them what you will. :

Best,
/Rob

Ob. MySQL: database, sql, query, table

~
Robert Alexander~~   Programmer/Analyst/DBA/Admin
WWW Database Applications~~http://www.ra1.net
Web Software and Hosting   ~~  http://www.workmate.ca

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php