Et DBMS er et system til at administrere, vedligeholde og kører et stort databasesystem, og alle de forskellige systemer er forskellige, dv.s. derer forskel på hvad de håndtere og hvor godt de gør det.
Især hvis vi taler om databaser hvor der er krav om transaktions congruens er den slags systemer nødvendige. F.eks. et system der håndtere betalingerer eller anden økonomi, der må en postering jo ikke slettes før man er sikker på at beløbet er overført og overførslen er gået godt, til gengæls skal der være sikkerhed for at et beløg er slettet fre den ene post når den er over ført til en anden.
Concurrency problemet opstår fordi vi ikke håndtere fysiske ting. Hvis vi talte om f.eks. mønter der skulle fra min pung over i din, kunne vi beskrive transaktionen således at min hånd tager mønterne op af min pung, giver mønterne til din hånd, der placere dem i din pung, Vi ved hvor mønterne er til hver en tid. Sker det samme elektronisk er der flere problemer. Beløbet skal ud af min konto, hvor er beløbet mens det er under transaktion. Risikere vi at slette beløbet fra min konto før det er indskrevet i din? osv osv osv. Sådan forstår jeg concurrency problemer
DBMS systemer (de bedste af dem) håndtere både concurrency og data integreteten (registrere alle aændringer således at alle transaktioner kan forklares og spores) og nonrepudiatat (ingen kan træde tilbage, d.v.s. alt registreres på personer således at ingen kan påstå at det ikke var dem der har udført en transaktion. Dette medføre bl.a. at der kun anvendes personlige konti, ingen gruppe konti osv osv)
Spørg hvis der er noget du ikke forstår eller vil have uddybet
MySQL med MyISAM tabeller understøtter ikke transaktioner og da de fleste jo nok vil kalde MySQL for en database, så er transaktioner nok ikke et super godt kriterie
her kommer Arnes helt personlige definition: en database er noget software til at gemme data på disk, hvor tilgang til data sker på et højt logisk niveau (som database navne, tabelnavne, feltnavne, værdier) og ikke på en lavt fysisk niveau (fil navne, byte adresser data strukturer)
SELECT * FROM t WHERE f=123
er nu engang nemmere end
læs f.idx ind i memory, betragt det som et array af struct med 2 felter som er 32 bit integer, antag at de er sorteret, lav en binnær søgning efter 123 i første felt, læs headeren af t.dat, se at den syvende 32 bit integer er 24 så vi ved at record size er 24, læs så 24 byte fra t.dat offset header size + det andet felt i den struct vi fandt før
Hvis man ligger en transaktions monitor oven på (XA compliant) databaser, så er det normalt fordi man har behov for 2 phase commit (fordi man har flere forskellige databaser eller resourcer)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
