postgres tervezési hiba

Adatbázis: SQL, XML DB

Sziasztok! 

Ez a hiba csak a postgres alatt merül fel egyáltalán. 

Egy hosszú hiszti helyett. Itt egy példa kód:

CREATE TABLE test_new (
    id serial primary key ,
    payload text
);

insert into test_new (payload ) values ('sf');
insert into test_new (payload ) values ('sf');
insert into test_new (id,payload ) values (3,'sf');
insert into test_new (id,payload ) values (4,'sf');
--SELECT setval('test_new_id_seq', max(id)) FROM test_new e ;--igen ez lenne a megoldás
insert into test_new (payload ) values ('sf');

Szükségem lenne arra, hogy betöltsek adatokat. Több embernek volt már ezzel baja, de egy jó rtfm-et nem találtam. Valami egyszerű triggert írt már rá valaki?

  • 601 megtekintés

( nydn | 2020. 06. 16., k – 15:23 )

Szerkesztve: 2020. 06. 16., k – 15:24

Én nem látom hol a hiba. És a leírásodból sem derül ki. Mi a bajod pontosan?

Azzal küzd, hogy csinál egy auto increment-es oszlopot, aminél a számot az adatbázis kezelő vezérelne, de utána mégis csak úgy gondolja, hogy

majd ő megmondja, hogy mi legyen a következő azonosító. Hát, ez így nem fog menni, lévén a Postgresql egy sequence-et fog létrehozni.

Tiszta, hogy mi a hiba oka. De nekem kellene valami olyan típus amit a serial helyett tudnék használni. Ami egyenértékű a mysql féle AUTO_INCREMENT-el.

Vagy bármi. A megoldás sem lehet bonyolult egy trigger kell ami mindig növeli az értéket. De ha már valaki megírta akkor ne kelljen nekem újra.

( _Franko_ v | 2020. 06. 16., k – 16:00 )

Nem tervezési hiba, egyszerűen ne keverd az automatikus és a manuális sorszámozást, ahol külön sequence táblából kapod a sorszámokat.

https://iotguru.cloud

( Dhat | 2020. 06. 16., k – 16:20 )

Ez a te barátod:

ALTER SEQUENCE test_new_id_seq RESTART WITH 5;

( gabrielakos v | 2020. 06. 16., k – 18:10 )

Szerkesztve: 2020. 06. 16., k – 18:12

insert -nél az id-hez seq.nextval -t írjál amikor nem tudod és a számot amikor tudod.

persze innentől neked kell arról gondoskodnod hogy a sequence-d átugorja amit manuálisan felhasználsz, különben nem lesz unique az id.

zászló, zászló, szív

( Nyosigomboc v | 2020. 06. 16., k – 18:17 )

Erre milyen felhasznalasnal van szukseg? Nincs olyan tartomany, amit nem akarsz neki kezzel adni, es amibol oszthat automatikusan a sequence-ed?

A strange game. The only winning move is not to play. How about a nice game of chess?

( kisg v | 2020. 06. 16., k – 19:15 )

Ez nem bug, feature. Igen, más feature mint a MySQL-ben. Erre - mármint hogy a MySQL != PostgeSQL, és ennek megfelelően kell tervezni a rendszert - az Uber is rájött, csak ők valószínűleg millió USD nagyságrendű összeget buktak rajta. :)

A kontextus ismerete nélkül nem tudunk érdemben segíteni. Ha tényleg csak DDL-lel tudsz belenyúlni, tehát az appot nem lehet módosítani, akkor egy INSERT triggerrel valószínűleg meg lehet oldani, ahogy azt már írták fentebb. De ehelyett a helyes megoldás egy adatbázis absztrakciós réteg bevezetése lenne az alkalmazás oldalán, ami a hasonló, SQL featureset / dialektus különbségekből adódó problémákat el tudja fedni az alkalmazás elől.

Erre - mármint hogy a MySQL != PostgeSQL, és ennek megfelelően kell tervezni a rendszert - az Uber is rájött, csak ők valószínűleg millió USD nagyságrendű összeget buktak rajta

Elolvasnám a sztorit, ha megvan neked a link. Ha nincs meg, akkor megkérdezem majd Google barátomat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezt így nem írták le sehol, csak 1-2 éve végighaknizták a sajtót / podcast / blogosphere-t, hogy ők most Postgresről visszaváltanak MySql-re.

És azokból az interjúkból derült ki az, hogy "valami" miatt átváltottak MySQL-ről Postgresre. Illetve konkrétabban úgy tűnt, hogy problémáik voltak a MySQL séma update-ekkel, konkrétan ha hibás volt egy update script, akkor az inkonzisztens állapotban hagyta a DB-t, emiatt aztán lehetett backupból visszaállni. Postgresnél ugye ilyen nincs, hiszen simán lehet DDL tranzakciót is rollbackelni.

Aztán rájöttek, hogy a Postgres WAL replikációjának teljesen más a teljesítménykarakterisztikája mint a MySQL logikai replikációjának (akkor még nem volt logikai replikáció Postgresben), és az ő séma tervezési módszerük (legyen mindenen index, mert hátha kell :) ) nem igazán kompatibilis vele. Úgyhogy elkeztek egy schemaless kiterjesztést csinálni MySQL felett... 

Persze lehet, hogy nem is így volt, és ez az egész csak a képzeletem szüleménye.

( asdPro | 2020. 06. 16., k – 20:52 )

Nekem nem dob hibát, valamit rosszul csinálok?

postgres=# select version();
                                                     version
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 row)
 

A 4 után simán beszúrja az 5-öt. Ha utána manuálisan szúrok be 15-öt, utána beszúrja automatikusan a 16-ot. Utána manuálisan megy a 6 is. Postgre 11.8-al is megy.