MySQL, szekvenciák, APEH

Turdus még februárban panaszkodott a PostgreSQL "bugjáról", de ahogy látom, azóta se tiszta mindenkinek: az SQL -ben használt szekvencia nem egyenlő a matematikai számtani sorozat fogalmával. És nincs ez másképp a MySQL-nél sem. 

mysql> create table test (id int auto_increment, primary key (id));
Query OK, 0 rows affected (0.01 sec)

mysql> select * from test;
Empty set (0.00 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test () values ();
Query OK, 1 row affected (0.00 sec)

mysql> select * from test;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)

mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test () values ();
Query OK, 1 row affected (0.00 sec)

mysql> select * from test;
+----+
| id |
+----+
|  2 |
+----+
1 row in set (0.00 sec)

mysql>

Tanulság: RTFM, és az APEH-nek nem sequnece-kel kell számlaszámot generálni.

MySQL, de az már inkább annak a példája, hogy hogyan ne írjunk CMS-t. Lehet, hogy egyszer újraírom normálisan a mostani céges keretrendszerrel, mert ég és föld lenne a különbség, csak munka és suli mellett viszonylag kevés időm van, amit ilyenekre szeretnék fordítani. Gyk. évek óta nem volt időm érdemben hozzányúlni, max pár apróbb hibajavítás, de volna még mit javítani rajta.

----------------
Lvl86 Troll

( uid_17626 | 2009. 09. 13., v – 14:33 )

Én az auto_increment-et a belső_id-hez használom, a számlaszám sima +1, ami nem véletlen, mert egy táblában van minden számla fejléce.

...
- Átutalásos számla
- Készpénzes számla
- EU Export utalás
- EU Export kp
...

Mindegyik más betűvel kezdődik, így a könyvelés is elélvez, mert egyből látszik a számlán mit és hová kell tenni.

CREATE TABLE public.szamlaseq (szamlaid INT NOT NULL DEFAULT 0);

Lekérdezés: 


BEGIN;

UPDATE szamlaseq SET szamlaid = szamlaid + 1 RETURNING szamlaid;

-- Számla beszúrása ide.

ROLLBACK/COMMIT;

Persze, ehhez az is kell, hogy a tranzakció READ COMMITTED módban fusson (PostgreSQL-ben, MySQL-ben ez a default). Ilyenkor párhuzamos tranzakciók esetén a második tranzakció bevárja az előbb indított tranzakció végét. Ha az első tranzakció sikeresen lefut, akkor a növelt szamlaid lesz a szamlaseq táblában, ha rollbackelve lett, akkor az eredeti.

----------------
Lvl86 Troll

ohm, ezt gondold ujra, mert igy baromsag. miaz, hogy bevarja a tranzakcio a masikat?? :) dehogy varja be.

a READ COMMITTED annyit tesz, hogy ha lekerdezel a tablabol, akkor csak commitolt tranzakciok eredmenyeit latod rajta, azokat, amik epp csak ugy leteznek (azaz nem commitoltak, se nem rollbackeltek) nem.

a bevarashoz semmi koze.

Várjál, tényleg átgondolom még egyszer, mert ez tényleg a másikra hajaz.

Ettől függetlenül miért van az, hogyha indítok két sessiont, mindkettőben indítok egy-egy tranzakciót, meg egy updatet, a később indított update addig nem fut le, míg az előzőt nem commitolom/rollbackelem?

Mind postgresql, mind mysql így működik default.

----------------
Lvl86 Troll

Falcon enginerol irnak, de InnoDB ugyanez:

The Falcon engine defaults to the repeatable read isolation mode level with no phantoms being possible. When a transaction attempts to modify or delete a row that another in-process transaction has already obtained, the previous transaction will wait until the other transaction either commits or rolls back. If the first transaction commits, then the other transaction receives an error and must try again. However, if the first transaction rolls back, then the other transaction will succeed. It’s important to note that all transactions will always read and operate on consistent data, which mirrors how many proprietary databases like Oracle operate.

itt.

amugy attol fugg, hogy mit updatelsz. row level lockingnal nincs ilyen problema, szerintem, csak ha ugyanazokat az adatokat erintene a ket update. ez pedig pont azert van, h konzisztens maradjon, marmint, mikor belepsz a tranzakcioba, kozben ne valtozzon az, amin dolgoznal.

Az biztos hogy elélvez, mert a számlákat folyamatosan kell sorszámozni. ha a számla más betűvel kezdődik, akkor az egy másik "számlatömb", aminél szintén kell lennie axxx1 .. axxx9 ill. bxxx1 .. bxxx9 és így tovább. az hogy axxx1 bxxx2 axxx3 axxx4 bxxx5 nem elfogadható.

Kíváncsi lennék arra a szigorú bizonylatok nyilvántartásra:)) ha van egyáltalán:Đ

Legalábbis én így tanultam még vagy 20 éve.
Való igaz, nem igazán foglalkoztam vele azóta:)

Így igaz.
Nekem pl.: számla KS/YEAR/sorszám
szállító KL/YEAR/sorszám
ehhez meg ugye a sorszám tömbbe 2 bejegyzés tartozik.
Függetlenül attól melyik telephelyen készül a számla.
De ugyanúgy szigorú számadás alá kerül a bevételi/kiadási pénztárbizonylat is.

pch
--
http://www.buster.hu
--