By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,190 Members | 1,469 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,190 IT Pros & Developers. It's quick & easy.

The quest for opensource database...

P: n/a
Perhaps you database guru able to suggest what would be a good choice for
opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now but
it lack of trigger, stored procedures, etc ... it sometimes slows the
project.

Is PostgreSQL any better/worse? Or is that any other choice beside the two?
Thanks.
Jul 17 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Ruby Tuesdays wrote:
Perhaps you database guru able to suggest what would be a good choice for
opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now but
it lack of trigger, stored procedures, etc ... it sometimes slows the
project.

Is PostgreSQL any better/worse? Or is that any other choice beside the
two? Thanks.


Postgresql is VERY robust and VERY rich with features.
You'll love it. I know I do. :-)

Triggers are implemented. As are serial (autonumber), PK, FK, and all other
types of constraints you can conjure up.

A very strong language for scripting stored procedures is implemented too.
(named: plpgsql)

exporting, backing up, everything is there.

Redhat even developed a very nice GUI for Postgresql 7.3, which they call
RHDB (RedHatDataBase) which is actually Postgresql 7.3 (i didn't find any
differences)
It is called Database Administrator for Postgres Redhat edition3.

I am still running their alpha, but it works like a charm, so why update?

I hope I sound enthousiastic enough, because I really like postgresql. :-)

Regards,
Erwin Moller
Jul 17 '05 #2

P: n/a

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Perhaps you database guru able to suggest what would be a good choice for
opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now but
it lack of trigger, stored procedures, etc ... it sometimes slows the
project.
You do not need stored procedures or database triggers to write successful
applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible to
keep track of what was being fired where.

Another reason I prefer to put all my business logic into PHP code instead
of triggers is that PHP code is a lot easier to debug. Have you come across
an interactive debugger for database procedures and triggers?

--
Tony Marston

http://www.tonymarston.net
Is PostgreSQL any better/worse? Or is that any other choice beside the two? Thanks.

Jul 17 '05 #3

P: n/a
Tony Marston wrote:

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Perhaps you database guru able to suggest what would be a good choice for
opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now
but it lack of trigger, stored procedures, etc ... it sometimes slows the
project.


You do not need stored procedures or database triggers to write successful
applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible
to keep track of what was being fired where.

Another reason I prefer to put all my business logic into PHP code instead
of triggers is that PHP code is a lot easier to debug. Have you come
across an interactive debugger for database procedures and triggers?


Very good advise, Tony.
I second that opinion 100%.
Been there too. :-(

Stick to constrainst like foreign keys (which do fire a trigger I think when
the relevant colums are updated/inserted) and avoid writing your own.
And stick to constraints like CHECK to make sure the data inserted makes
sense to you instead of triggers.
Stored procedures do often shorten the developmenttime, but are hard to
debug.
It is often easy to do 'some quick and dirty' solution using stored
procedures, but when something changes in the application (which happens
all the time) you have to debug those SP's too.

Regards,
Erwin Moller
Jul 17 '05 #4

P: n/a
"Tony Marston" <to**@NOSPAM.demon.co.uk> writes:
You do not need stored procedures or database triggers to write successful
applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible to
keep track of what was being fired where.

Right! Gratuitous use of triggers, SPs and the like results in
indirection that can make a system impossible to understand. Use with
care.

But is this a vote in favor of a less advanced system that prevents
the temtation? I don't think so.

YMMV
--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant
305 321-1144 (mobile http://www.JerrySievers.com/

--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant
305 321-1144 (mobile http://www.JerrySievers.com/
Jul 17 '05 #5

P: n/a
May be we can get away with the strored procedures. Why would one do
manipulation of the data inside a database engine, right? The function of
database is to store and retrieve information, that's it. Beyond that you
really stretch it and this where scripting language such as Ruby comes in.

But for trigger, to write a commercial grade transaction processing
application, you definitely need trigger. Trigger will aid
programmers/designer to ensure certain consistency checking happen
before/after certain opearation. How would you do that outside the database
engine withouth kludging it?

Just my 2cents back from my college days.
For simple and less-dynamic-update application, you might not need tri
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:c6******************@news.demon.co.uk...

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Perhaps you database guru able to suggest what would be a good choice for opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now but it lack of trigger, stored procedures, etc ... it sometimes slows the
project.
You do not need stored procedures or database triggers to write successful
applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible

to keep track of what was being fired where.

Another reason I prefer to put all my business logic into PHP code instead
of triggers is that PHP code is a lot easier to debug. Have you come across an interactive debugger for database procedures and triggers?

--
Tony Marston

http://www.tonymarston.net
Is PostgreSQL any better/worse? Or is that any other choice beside the

two?
Thanks.


Jul 17 '05 #6

P: n/a

"Useko Netsumi" <us*****************@earthlink.net> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
May be we can get away with the strored procedures. Why would one do
manipulation of the data inside a database engine, right? The function of
database is to store and retrieve information, that's it. Beyond that you
really stretch it and this where scripting language such as Ruby comes in.

But for trigger, to write a commercial grade transaction processing
application, you definitely need trigger. Trigger will aid
programmers/designer to ensure certain consistency checking happen
before/after certain opearation. How would you do that outside the database engine withouth kludging it?
I personally create a separate class for each database table and define the
constraints within that class. I then have standard code which is used to
deal with these constraints at the appropriate time (see
http://www.tonymarston.co.uk/php-mys...eobjects2.html for some
examples). In this way I achieve the following objectives:
(1) The constraint details and business logic for a database table are
contained in the same class, therefore everything is in one place instead of
being scattered about hither and yon.
(2) I am in complete control when it comes to implementing the constraints,
so I have the power to change them at runtime should the need arise.
(3) If I have a problem I can always step through with my debugger.

--
Tony Marston

http://www.tonymarston.net
Just my 2cents back from my college days.
For simple and less-dynamic-update application, you might not need tri
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:c6******************@news.demon.co.uk...

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Perhaps you database guru able to suggest what would be a good choice for opensource database platform to use to develop projects.

At the moment the project is small/medium, but it will grow in size both data, users, and number of transactions. I'm using MySQL for right now but it lack of trigger, stored procedures, etc ... it sometimes slows the
project.


You do not need stored procedures or database triggers to write successful applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one trigger/procedure updated several tables, which fired more triggers which contained more updates which fired more triggers ..... It was impossible

to
keep track of what was being fired where.

Another reason I prefer to put all my business logic into PHP code instead of triggers is that PHP code is a lot easier to debug. Have you come

across
an interactive debugger for database procedures and triggers?

--
Tony Marston

http://www.tonymarston.net
Is PostgreSQL any better/worse? Or is that any other choice beside the

two?
Thanks.



Jul 17 '05 #7

P: n/a
But isn't that supposedly the function of the database trigger - that is to
ensure that all contraint are accounted for without kludging it?

But I do get your point though. I'm sure with expertise such as yours, you
can replace those stored procedures/trigger function in PHP or any scripting
language but isn't that stretching it a bit too far?

With stored procedures/trigger, script programmer can concentrate more in
the flow/design of the application where the database programmer can
concentrate on the data storage(and simple data manipulation using strored
procedures) and data constraints(trigger).

Just my 2cents.
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:c6*******************@news.demon.co.uk...

"Useko Netsumi" <us*****************@earthlink.net> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
May be we can get away with the strored procedures. Why would one do
manipulation of the data inside a database engine, right? The function of
database is to store and retrieve information, that's it. Beyond that you really stretch it and this where scripting language such as Ruby comes in.
But for trigger, to write a commercial grade transaction processing
application, you definitely need trigger. Trigger will aid
programmers/designer to ensure certain consistency checking happen
before/after certain opearation. How would you do that outside the database
engine withouth kludging it?


I personally create a separate class for each database table and define

the constraints within that class. I then have standard code which is used to
deal with these constraints at the appropriate time (see
http://www.tonymarston.co.uk/php-mys...eobjects2.html for some
examples). In this way I achieve the following objectives:
(1) The constraint details and business logic for a database table are
contained in the same class, therefore everything is in one place instead of being scattered about hither and yon.
(2) I am in complete control when it comes to implementing the constraints, so I have the power to change them at runtime should the need arise.
(3) If I have a problem I can always step through with my debugger.

--
Tony Marston

http://www.tonymarston.net
Just my 2cents back from my college days.
For simple and less-dynamic-update application, you might not need tri
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:c6******************@news.demon.co.uk...

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
> Perhaps you database guru able to suggest what would be a good choice
for
> opensource database platform to use to develop projects.
>
> At the moment the project is small/medium, but it will grow in size both > data, users, and number of transactions. I'm using MySQL for right
now but
> it lack of trigger, stored procedures, etc ... it sometimes slows
the > project.

You do not need stored procedures or database triggers to write

successful applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one trigger/procedure updated several tables, which fired more triggers which contained more updates which fired more triggers ..... It was impossible to
keep track of what was being fired where.

Another reason I prefer to put all my business logic into PHP code instead of triggers is that PHP code is a lot easier to debug. Have you come

across
an interactive debugger for database procedures and triggers?

--
Tony Marston

http://www.tonymarston.net

> Is PostgreSQL any better/worse? Or is that any other choice beside

the two?
> Thanks.
>
>



Jul 17 '05 #8

P: n/a

"Useko Netsumi" <us*****************@earthlink.net> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
But isn't that supposedly the function of the database trigger - that is to ensure that all contraint are accounted for without kludging it?

But I do get your point though. I'm sure with expertise such as yours, you
can replace those stored procedures/trigger function in PHP or any scripting language but isn't that stretching it a bit too far?
It is not stretching anything at all. In my early days of programming, which
was before relational databases were fashionable, none of the database
management systems had triggers or procedures, so I learned to write entire
applications without them.
With stored procedures/trigger, script programmer can concentrate more in
the flow/design of the application where the database programmer can
concentrate on the data storage(and simple data manipulation using strored
procedures) and data constraints(trigger).


I don't work on projects where the database, business logic and screen
layout are dealt with by separate people as this is a recipe for disaster.
There is nothing in a stored procedure or database trigger that I cannot
achieve more easily with PHP code, it is easier to control and it is far
easier to debug.

--
Tony Marston

http://www.tonymarston.net

Jul 17 '05 #9

P: n/a
to**@NOSPAM.demon.co.uk says...

"Ruby Tuesdays" <No**********************@yahoo.com> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Perhaps you database guru able to suggest what would be a good choice for
opensource database platform to use to develop projects.
Sorry, can't confidently recommend. Am spoilt, have Oracle.
At the moment the project is small/medium, but it will grow in size both
data, users, and number of transactions. I'm using MySQL for right now but
it lack of trigger, stored procedures, etc ... it sometimes slows the
project.
You do not need stored procedures or database triggers to write successful
applications.


But they can be very beneficial.
I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible to
keep track of what was being fired where.
Bad design/code is bad design/code no matter at what "layer" it is
written. Doesn't mean you should throw the baby out with the bath
water.
Another reason I prefer to put all my business logic into PHP code instead
of triggers is that PHP code is a lot easier to debug.
I use stored procedures and triggers for things like serialized
transactions, audit logs and complex calculations. In general (in Oracle
at least) nearly everything that can be done inside the "database
level" is more efficient, sometimes massively so, than the same thing
written at the PHP "application level".

I've fought similar anti-database-level-coding arguments against the use
of database referential integrity constraints.
Have you come across
an interactive debugger for database procedures and triggers?


For Oracle many exist, if you have the necessary $$$.

Geoff M
Jul 17 '05 #10

P: n/a
Tony Marston wrote:
You do not need stored procedures or database triggers to write successful
applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one
trigger/procedure updated several tables, which fired more triggers which
contained more updates which fired more triggers ..... It was impossible to
keep track of what was being fired where.
Design of complex systems is, necessarily, complex. One approach is to
consolidate all of the logic at one layer -- but that can result in
significant performance differences for an app that uses stored
procedures / triggers / functions to avoid communications overhead of
the client-server interactions and to take advantage of the built-in
optimizations the SQL engine can use for stored procedures / functions.
Another reason I prefer to put all my business logic into PHP code instead
of triggers is that PHP code is a lot easier to debug. Have you come across
an interactive debugger for database procedures and triggers?


Not quite on topic, because it's not an open source database, but DB2
does includes an interactive debugger for stored procedures in the DB2
Development Center
(http://publib.boulder.ibm.com/infoce...d/t0007399.htm)

In some cases I would argue that issuing a couple of CALL and SELECT
statements is a lot easier than trying to figure out whether you've
introduced a problem in your PHP code or in your SQL statements within
the PHP code.

Dan
Jul 17 '05 #11

P: n/a
Dan, I think that is what I want to convey to Tony that sure any expert on
any programming language can write anything with that programming language,
but is it the wise thing to do though when other has done it and thought
about that particular function for quite sometimes.

Tony, I'm sure that you can do almost everything with PHP, but do you think
it is wise? Just a question from an experience user. Thanks

"Dan Scott" <da*******@ca.ibm.com> wrote in message
news:c6**********@hanover.torolab.ibm.com...
Tony Marston wrote:
You do not need stored procedures or database triggers to write successful applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one trigger/procedure updated several tables, which fired more triggers which contained more updates which fired more triggers ..... It was impossible to keep track of what was being fired where.
Design of complex systems is, necessarily, complex. One approach is to
consolidate all of the logic at one layer -- but that can result in
significant performance differences for an app that uses stored
procedures / triggers / functions to avoid communications overhead of
the client-server interactions and to take advantage of the built-in
optimizations the SQL engine can use for stored procedures / functions.
Another reason I prefer to put all my business logic into PHP code instead of triggers is that PHP code is a lot easier to debug. Have you come across an interactive debugger for database procedures and triggers?


Not quite on topic, because it's not an open source database, but DB2
does includes an interactive debugger for stored procedures in the DB2
Development Center

(http://publib.boulder.ibm.com/infoce...m.db2.udb.doc/
ad/t0007399.htm)
In some cases I would argue that issuing a couple of CALL and SELECT
statements is a lot easier than trying to figure out whether you've
introduced a problem in your PHP code or in your SQL statements within
the PHP code.

Dan

Jul 17 '05 #12

P: n/a

"Useko Netsumi" <us*****************@earthlink.net> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Dan, I think that is what I want to convey to Tony that sure any expert on
any programming language can write anything with that programming language, but is it the wise thing to do though when other has done it and thought
about that particular function for quite sometimes.

Tony, I'm sure that you can do almost everything with PHP, but do you think it is wise? Just a question from an experience user. Thanks
Yes, it is wise, IMHO, for the reasons I have already stated:
(a) I like to keep all my code in PHP modules rather than spread them over
database triggers and stored procedures. This is what "encapsulation" is all
about.
(b) I can often write code faster in PHP than SQL, so I have no incentive to
write SQL other than what is contained within my PHP code.
(c) There are things you can do in PHP that you cannot do in SQL.
(d) Debugging triggers or procedures is not easy, so if you have a problem
it can be very difficult to track down which unit it is in. If all the code
is within PHP then it is a simple matter of stepping through with your
interactive debugger.
(e) Code inside triggers or procedures MAY execute faster than PHP code, but
where the most expensive item nowadays is the cost of the developer then
this is the area where the greatest savings can be made.

Just my tuppence worth.

--
Tony Marston

http://www.tonymarston.net
"Dan Scott" <da*******@ca.ibm.com> wrote in message
news:c6**********@hanover.torolab.ibm.com...
Tony Marston wrote:
You do not need stored procedures or database triggers to write successful applications. I once had to maintain a system that was built around
procedures and triggers, and it was a nightmare. The problem was that one trigger/procedure updated several tables, which fired more triggers which contained more updates which fired more triggers ..... It was
impossible
to keep track of what was being fired where.
Design of complex systems is, necessarily, complex. One approach is to
consolidate all of the logic at one layer -- but that can result in
significant performance differences for an app that uses stored
procedures / triggers / functions to avoid communications overhead of
the client-server interactions and to take advantage of the built-in
optimizations the SQL engine can use for stored procedures / functions.
Another reason I prefer to put all my business logic into PHP code instead of triggers is that PHP code is a lot easier to debug. Have you come across an interactive debugger for database procedures and triggers?


Not quite on topic, because it's not an open source database, but DB2
does includes an interactive debugger for stored procedures in the DB2
Development Center

(http://publib.boulder.ibm.com/infoce...m.db2.udb.doc/ ad/t0007399.htm)

In some cases I would argue that issuing a couple of CALL and SELECT
statements is a lot easier than trying to figure out whether you've
introduced a problem in your PHP code or in your SQL statements within
the PHP code.

Dan


Jul 17 '05 #13

P: n/a
"Useko Netsumi" <us*****************@earthlink.net> wrote in message news:<c6************@ID-205437.news.uni-berlin.de>...
May be we can get away with the strored procedures. Why would one do
manipulation of the data inside a database engine, right? The function of
database is to store and retrieve information, that's it. Beyond that you
really stretch it and this where scripting language such as Ruby comes in.

But for trigger, to write a commercial grade transaction processing
application, you definitely need trigger. Trigger will aid
programmers/designer to ensure certain consistency checking happen
before/after certain opearation. How would you do that outside the database
engine withouth kludging it?


Well, you could write an object-relational mapping layer that executes
triggers in the code before hitting the database. Then you could write
a mock database underneath that which allows you to actually unit-test
your triggers without having to slowdown to hit a live database. I
did:

http://lafcadio.rubyforge.org/

This is newer stuff and no dobut a lot less robust than, say, the
stuff you get in Oracle. But I use this feature routinely in
production work, and I really really really like being able to unit
test my triggers.

Francis
Jul 17 '05 #14

P: n/a
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:c6*******************@news.demon.co.uk...

"Useko Netsumi" <us*****************@earthlink.net> wrote in message
news:c6************@ID-205437.news.uni-berlin.de...
Dan, I think that is what I want to convey to Tony that sure any expert on any programming language can write anything with that programming language,
but is it the wise thing to do though when other has done it and thought
about that particular function for quite sometimes.

Tony, I'm sure that you can do almost everything with PHP, but do you

think
it is wise? Just a question from an experience user. Thanks


Yes, it is wise, IMHO, for the reasons I have already stated:
(a) I like to keep all my code in PHP modules rather than spread them over
database triggers and stored procedures. This is what "encapsulation" is

all about.
(b) I can often write code faster in PHP than SQL, so I have no incentive to write SQL other than what is contained within my PHP code.
(c) There are things you can do in PHP that you cannot do in SQL.
(d) Debugging triggers or procedures is not easy, so if you have a problem
it can be very difficult to track down which unit it is in. If all the code is within PHP then it is a simple matter of stepping through with your
interactive debugger.
(e) Code inside triggers or procedures MAY execute faster than PHP code, but where the most expensive item nowadays is the cost of the developer then
this is the area where the greatest savings can be made.

Just my tuppence worth.

--
Tony Marston

http://www.tonymarston.net
"Dan Scott" <da*******@ca.ibm.com> wrote in message
news:c6**********@hanover.torolab.ibm.com...
Tony Marston wrote:

> You do not need stored procedures or database triggers to write

successful
> applications. I once had to maintain a system that was built around
> procedures and triggers, and it was a nightmare. The problem was that
one
> trigger/procedure updated several tables, which fired more triggers

which
> contained more updates which fired more triggers ..... It was impossible
to
> keep track of what was being fired where.

Design of complex systems is, necessarily, complex. One approach is to
consolidate all of the logic at one layer -- but that can result in
significant performance differences for an app that uses stored
procedures / triggers / functions to avoid communications overhead of
the client-server interactions and to take advantage of the built-in
optimizations the SQL engine can use for stored procedures /

functions.
> Another reason I prefer to put all my business logic into PHP code

instead
> of triggers is that PHP code is a lot easier to debug. Have you come

across
> an interactive debugger for database procedures and triggers?

Not quite on topic, because it's not an open source database, but DB2
does includes an interactive debugger for stored procedures in the DB2
Development Center

(http://publib.boulder.ibm.com/infoce...m.db2.udb.doc/ ad/t0007399.htm)

In some cases I would argue that issuing a couple of CALL and SELECT
statements is a lot easier than trying to figure out whether you've
introduced a problem in your PHP code or in your SQL statements within
the PHP code.

Dan




Tony,

I find SPs are useful when invoking complex routine queries against the dbms
on machine 'B' from the PHP instance on machine 'A', when the alterantive is
to load gazillions of rows across the wire from 'B' to 'A' in order to
process them locally.

Triggers are more of a problem. I hate using triggers to perform relational
tasks, such as updating table 'C' in response to an update to table 'D'.
However, triggers can be useful when the update to table 'D' needs to
trigger an external event in the environment of the dbms, especially again
when the dbms machine is not the same as the machine running the script. An
example is a change management workflow system I wrote, where a change to
the status of a change request needs to cause an email to be sent to the
next person in the flow. I implemented this using a trigger on the CR table
and had the dbms server figure out who to email and then send the mail
directly, instead of handing the information back over the wire to a remote
client with an (unknown?) breed and version of mailer software and trusting
the client to send the mail.

In general, I agree with your sentiments, but like all tools, I think SPs
and triggers have their place - it just is not good design to use them to
save thinking about relational integrity and cascading effecs.

Just my $0.02
Doug
--
Remove the blots from my address to reply
Jul 17 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.