List:General Discussion« Previous MessageNext Message »
From:b b Date:July 30 2003 7:16pm
Subject:Re: Transactions
View as plain text  

 In the past I have developed  MS-SQSQL ASP
applications and handed the ASP parts to a junior
programmer knowing well that he wouldn't be able to
wreck the database (given the triggers, Keys,
constraints, indexes and stored procedures that were
involved).

 Yes I agree with you that clients should be
programmed correctly too. However, I believe that in
the software development process, different components
should try to remain as independent as possible with
clear interfaces that link them together. In fact, I
think that a programmer developing a component (the
client for example) ideally  wouldn't need to know the
inner-workings of the components that other
programmers are developing. 

 So if a programmer developing the client has to worry
about referential integrity, data corruption and the
like which is the job of the db programmer, then I
think that the software engineering concept has been
violated. True enough, one programmer could be
developing all aspects of the applications. But, in my
opinion that doesn't mean he has to relax these
concepts.

 That is just my opinion. I may well be wrong. I also
agree that MySQL has come a long way and I am glad
with the features introduced in version 4.

 Cheers. 

PS: by the way I am by no means an expert so to take
the pressure of my shoulders, I will forecast asking
neive questions in the future. In fact currently I am
not able to grant privilages to users using the Grant
command for some reason!!!!


--- Patrick ShSherrillpapatrickococonetom> wrote:
> I'm reticent to consume any more of this lists
> bandwidth and trust this will
> end the thread, but here is my point.  There are
> many 'gotchas' to consider
> when developing an application that uses any dynamic
> file structure from
> simple flat asascii> files to engorged dbdbms. Add
multi-user and
> multi-tasking to the mix and
> you have a tiger by the tail. The bottom line is, it
> is the responsibility
> of
> the programmer to ensure that every tool they use is
> safely and
> correctly implemented.  Transactions or commit and
> rollback levels help, but
> they are only a small piece of the package.  It is
> dangerous to assume that
> because referential integrity has been maintained,
> that the data is as
> intended.  Any application that allows its data to
> be manipulated in other
> than a read-only status is responsible for its
> integrity.  Your example of
> the web browser is a good one.  Using the hthttp>
protocol and hthtmlo hook-up
> heterogeneous systems has become common and is
> relatively simple.  It is, as
> you point out, stateless. The browser does not know
> or care about the
> success or failure of an operation.  It is the
> responsibility of the person
> writing the hthtmlnd any other subsequent code to
> communicate the
> appropriate result to the client. You certainly
> would not want to lock a
> region or even a row from a
> stateless client.  If two people access the same
> record/row at the same time
> and change non-key information but commit the
> changes sequentially 2 seconds
> apart the referential integrity could be correct,
> but the data is not as the
> first person intended. In this scenario, the
> programmer needs to provide a
> mechanism to advise the first
> client that his changes were overwritten, thereby
> turning a stateless event
> into a ststatefulne and maintaining control of the
> application.
> 
> A robust file handler or dbdbmss a wonderful tool
> but it is only a tool and
> does not relieve a programmer of their
> responsibility. That's my point.
> 
> Pat...
> 
> BTW MyMySQLs one of the best SQSQLervers out there,
> and our SQSQLerver of
> choice.
> 
> 
> ----- Original Message ----- 
> From: "b b" <hell_wild_hot2@stripped>
> To: "Dan Nelson" <dndnelsonlallantgroupom>
> Cc: "mymysqllist<mymysqlists.mymysqlom>
> Sent: Tuesday, July 29, 2003 11:11 PM
> Subject: Re: Transactions
> 
> 
> >
> >  Good point. However, I disagree with you on
> > fufundementaloints. Subsystems within an
> application
> > should remain inindepedantor a easier
mamaintanance> and
> > better software development process.
> >
> >  Here we have a multi tiered system whereby the
> > database can't guarantee it's integrity without
> good
> > clients. Thats not very sustainable and defeats
> the
> > purpose of having functionality distributed among
> > different components.
> >
> >  Deleting, updating and insertions should be done
> > correctly on the database level. In the example i
> > gave, there is no guarantee that the client will
> try
> > to do the insertion again. What if we have more
> than
> > one client? lets say a web browser. Should we rely
> on
> > the user hitting reload? Now we are relying on the
> > good practice of the user to keep the db integral
> ....
> >
> >  Fortunately Scott Helms reminded us that mymysql
> does
> > include the ininnodbhich are transactional tables.
> I
> > will give that a shot.
> >
> >  Thanks for the comment.
> >
> >
> > --- Dan Nelson <dndnelsonlallantgroupom> wrote:
> > > In the last episode (Jul 29), b b said:
> > > > Most web hosting companies run the mymysql>
standard.
> > > Which means one
> > > > can't run transactions. If that is the case,
> then
> > > how do you handle
> > > > many to many relationships with trtruely>
normalized
> > > manner without
> > > > risking data corruption
> > > >
> > > > For example: You have an ororgctctryables and
> a
> > > middle table ororgCtry
> > > > The middle table has the two foforiegneys one
> from
> > > ororgnd one from
> > > > ctctryThis way an ororgould be operating in
> many
> > > countries and a
> > > > country could have many organizations.
> > > >
> > > > Now to insert an organization "AAA" that
> operates
> > > in USA, Canada, and
> > > > Argentina one would need typically to do four
> sqsql> > > statements:
> > > >   insert into ororgame, .....
> > > >   get the newly inserted ororgD
> > > >   insert into ororgCtryD for ororgID for USA)
> ...
> > > >     insert into ororgCtryD for ororgID for
> Canada)
> > > ...
> > > >   insert into ororgCtryD for ororgID for
> > > Argentina)
> > > > ...
> > > >
> > > >  To do the above securely one has to put it in
> a
> > > transaction. If
> > >
> > > You really mean "To do the above atomically"
> here.
> > > You can still do it
> > > securely, but you have to make the client
> > > apapppplicationmarter.  If
> > > the server crashes after the 2nd insert, you end
> up
> > > with 1 record in
> > > ororgNamend 1 in ororgCtry So when the end-user
> > > retries the request,
> > > the client has to realize that AAA already
> exists
> > > and simply insert the
> > > remaining two records.
> > >
> > > When you decide to delete the "AAA" user, make
> sure
> > > you delete
> > > dependent records first.  So remove the
ororgCtry> > > records before removing
> > > the parent record in ororg Otherwise, if the
> server
> > > crashes, you end up
> > > with dangling records that you have to clean up
> in a
> > > mamaintenencecript
> > > (not difficult, but not necessary if you delete
> in
> > > the right order).
> > >
> > > Transactions are most important in places where
> you
> > > have to update
> > > multiple records or tables, and /cannot/ allow a
> > > partial update
> > > (double-entry bookkeeping, etc).  Foreign keys
> (and
> > > susubqueriesare
> > > handy to have, but you can always duplicate
> their
> > > functionality with
> > > extra code in the client.
> > >
> > > -- 
> > > Dan Nelson
> > > dndnelsonlallantgroupom
> >
> >
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Thread
Transactionsb b29 Jul
  • Re: TransactionsDan Nelson29 Jul
    • Re: Transactionsb b30 Jul
      • Re: TransactionsPatrick Sherrill30 Jul
        • Re: Transactionsb b30 Jul
        • Re: TransactionsKaarel31 Jul
          • Re: TransactionsStephan Lukits1 Aug
  • Re: TransactionsPatrick30 Jul
  • Re: TransactionsPaul DuBois30 Jul
RE: TransactionsGilbert Wu30 Jul