Transactions og mySQL

i asp altså!

MySql understøtter ikke transaktioner. De påstår at det bl.a. er derfor de er hurtigere
end f.eks. MsSql - om det passer ved jeg ikke. Til knap så kritiske applikationer på
web-en skal du bare sørge for at lave opdateringerne i en passende rækkefølge, så
et eventuelt nedbrud ikke betyder noget. Det kan man tit.

Er det en kritisk applikation, f.eks. fordi du er ved at oprette en bank, så skal du
ikke bruge MySql.

erikjacobsen:  Se jeg var af samme opfattelse indtil jeg faldt over afsnittet "5.4.3 - Transactions" (http://www.mysql.com/documentation/mysql/bychapter/manual_Compatibility.html#Missing_Transactions) i manualen til MySQL.

Jeg kan ikke finde nogle kommentarer om hvornår det er blevet implementeret, så jeg går ud fra at de har været der i lang tid.

Ok, de har jo snakket om det. Men om det har været der i lang tid ved jeg nu ikke. Den/de mysql-er
jeg piller lidt ved har det tilsyneladende ikke. Nu har jeg ikke læst det grundigt, men er det ikke
lidt en variant over det klassiske?

erik jacobsen: Kan du forklare mig, sådan generelt, hvad du mener med "i en passende rækkefølge" ?

chruker: Det du angiver...er det ikke lige præcis det jeg skal bruge? Men, kan det gøres via asp?

erikjacobsen: Jeg har også lige testet mysql på Windows NT og Linux og ingen steder kunne jeg få transactions til at virker, men mon ikke det så er en del af udviklingsudgaven.

1416: Jeg vil tro det er det du skal bruge, men hvis transactions først lige er blevet introduceret i MySQL udviklingsversionen, så går der nok lidt tid før traditionelle udbydere af MySQL services understøtter det.

1416: Jo, lidt generelt. Hvis du har en række opdateringer, der i princippet skal udføres samlet,
så prøv at lave dem sådan, at der ikke er sket nogen katastofe, hvis de bliver afbrudt undervejs,
altså hvis de sidste opdateringer mangler. Det kan også være nødvendigt at programmere en efterfølgende
søgning anderledes, end man ellers ville have gjort.

F.eks. en opdatering af 2 tabeller:

  I begge felter indsættes et tidsstempel som en del af nøglen, således at alle poster
  kan findes flere gange.

  I stedet for 2 x UPDATE bruger du så 2 x INSERT efterfulgt af 2 x DELETE. I de 2 inserts vælger
  du en fælles værdi for tidsstemplet. Går det galt et sted i 2xI+2xD har vi et problem. Det løser vi ved
  at lave selecterne anderledes.

  Ved select skal du spørge på begge tabeller, og bruger en ORDER BY så den nyeste står først.
  Hvis begge giver en post, og tidsstemplerne er ens, kan vi stole på resultatet. Hvis tidsstemplerne er
  forskellige, skal vi prøve igen. Hvis de giver mere end et og der kun er en af dem med den nyste, men
  der er to med den gamle, er det den der skal bruges.

  Så skal der en gang imellem ryddes op i tabellen.

  Ellers putter man værdierne i en og samme tabel - om muligt - og ser stort på 3. normalform.

Tjah, besværligt....

De transactions i MySQL som jeg snakkede om er kommet i version 3.23.15 hvilket er en af udviklingsversionerne som man formentlig ikke ser i drift hos nogle ISP'er endnu.