ugrás a tartalomhoz

000001 stílusú sorszám növelése

aspirany · 2008. Júl. 25. (P), 22.45
A kérdés a következő

ilyen sorszámot kell csinálnom és növekedjen

000001

adatbázisba így tároljam, vagy legyen inkább autoincrement és php-ban a nullákkal játszok
‹ Tárolt eljárás ha nem kap paramétert Adatbázis export-import után ékezet probléma ›
 ■
1

Auto increment

janoszen · 2008. Júl. 25. (P), 22.50
Az auto increment elsődlegesen nem növekvő, hanem egyedi számozásra való. Ergó, lehet olyan szerverbeállítás, ahol nem egyet, hanem kettőt lép.
2

sorry

aspirany · 2008. Júl. 26. (Szo), 00.22
tehát elsődlegesen úgy gondoltam hogy varchar 0000001 vagy autoinkrement és fprint(%07d

a lényeg hogy visszakeresésnél ezt a számot üti be 0000001

bár a nullákat ki lehet trimmelni
3

Nem zárja ki egymást.

solkprog · 2008. Júl. 26. (Szo), 21.41
Lehet auto_increment 0000001 formában is:

create table tablanev (
id smallint(7) zerofill primary key auto_increment
)
üdv,
Balázs
4

szuper

aspirany · 2008. Júl. 26. (Szo), 21.55
ezt nem tudtam; mindig integert adtam meg;

a sorszámok iy ugy nőnek hogy "tizes válltás" után a nulla 1-re vállt
5

nem lesz hézagmentes

Hodicska Gergely · 2008. Júl. 26. (Szo), 22.18
Valószínűleg a kérdezőnek fontos lenne, hogy ez a szám hézagmentesen növekedjen. Ezt az autoincrement nem fogja tudni biztosítani. Kb. azt lehet csinálni, hogy lekérdezi a max+1-et, megpróbálja beszúrni, és ha nem sikerül, akkor újra próbálkozik. Illetve lehet pesszimista lockolást is használni (ez a körülményektől függ).

Ettől függetlenül szerintem a DB-ben nem kell benne legyen a nulla, az egy dolog, hogy a user így akarja beütni, de ettől még nem kell így is tárolni.


Üdv,
Felhő
6

akkor megnyugodtam

aspirany · 2008. Júl. 26. (Szo), 22.54
én sem így csináltam;

sima autoincrement a nullákat sprintf("%07d",$sorszam);

a sorszámoknak egymás után kell nőni,ne legyen hézag. tranzakció kezelésnél egy esetleges rollback miatt nem lessz hézag?
7

próbáld ki ;)

Hodicska Gergely · 2008. Júl. 27. (V), 11.24
Üdv,
Felhő
8

hűlyeséget kérdeztem elnézést

aspirany · 2008. Aug. 3. (V), 17.54
ha jól van megirva akkor nincs hézag a sorszámok között
9

biztos vagy benne?

Hodicska Gergely · 2008. Aug. 3. (V), 20.32
Szerintem erre a feladatra auto_increment nem alkalmas. Most nem próbáltam ki, de pont az általad említett rollback miatt. Majdnem biztos vagy benne hogy egy tranzakcióban már egyszer kiosztott id-t nem fog egy rollback esetén újból kiosztani, mert ha jól rémlik, akkor táblánként van egy számláló.


Üdv,
Felhő
10

Igen

janoszen · 2008. Aug. 3. (V), 23.51
Igen, ha kidumpolod a táblát, ott fog figyelni a dumpban a megfelelő paraméter.
11

akkor mi legyen?

aspirany · 2008. Aug. 4. (H), 07.03
IGAZ, ROLLBACK UTÁN NEM HASZNÁLJA A MÁR KIOSZTOTT SORSZÁMOT

Akkor szerintettek mi legyen. vegyem ki az auto incrementet, és programból vagy triggerből vagy tárolt eljárásból növeljem a sorszámot?
12

max+1

Hodicska Gergely · 2008. Aug. 5. (K), 00.32
Kérdezd le a max+1-et, és írd azt vissza, és a mezőn legyen unique index. Ha ütközés van, akkor újból megpróbálod. Ez egy kicsit naiv megközelítés, de kicsi az esélye az ütközsének, akkor teljesen jó lesz. Nem tudom, hogy ezt per pillant triggerből meg lehet-e oldani (amikor annó néztem, akkor elég primitív volt a hibakezelés a MySQL-ben). Programból könnyen meg tudod oldani.


Üdv,
Felhő
15

trigger nincs több

aspirany · 2008. Aug. 5. (K), 16.50
OFF

találkoztatok-e már olyan hibával mysql hogy engedi a triggert hozzáadni.De mikor megnézném pl(EMS mysql) azt mondja hogy törölve lett ill nem találja a triggert
13

Bővebben

vbence · 2008. Aug. 5. (K), 11.26
Többet kéne tudni a környetetről. Ha tranzakciókat is használsz, elég bonyolultnak tűnik ahhoz, hogy a "lyukak" megengedhetők legyenek.

Szerintem a nagy kérdés az, hogy ezt a kulcsot használod-e kapcsolatok építésére más táblákkal, mert ha igen, akkor mindenképpen a lyukas megoldás a biztonságosabb:
Tételezzük fel, hogy van egy rekordod ebben a sorszámozott táblában, ehhez kapcsolódik egy rekord egy másikban. Valamilyen hiba folytán törlődik a sorszámozott rekordod. Ha max+1 -et hazsnálsz, akkor a mostani rekord helyére kerül az új, és a régi rekord kapcsolatai így már az újra fognak mutatni (mivel újra kiosztottad az ID-t). Auto incrementnél nyilvánvaló lesz a hiba, hiszen a kapcsolatok egy nem létező rekordra mutatnak. (Nem tudom mennyire volt érthető)...
14

Foreign Key

zila · 2008. Aug. 5. (K), 11.58
Az ilyen törlések/átkulcsolódások védhetőek idegen kulcsokkal, bár nem ismerem a mysql ezirányú képességeit... Én inkább egy sima autoincrement id-t használnék kulcsolásra, a folyamatos sorszámozásra meg egy másik mezőt. Az sem világos, hogy mire/hova kell ez a szigorú sorszámozás...
16

Én tesztelgetek

aspirany · 2008. Aug. 5. (K), 17.00
A tábla :

CREATE TABLE `szerzodes` (
  `szerzodesID` int(11) NOT NULL auto_increment,
  `kod_elso` int(2) NOT NULL,
  `projektID` int(11) NOT NULL,
  `szerzodoID` int(11) NOT NULL,
  `partnerID` int(11) NOT NULL,
  `sorszam` varchar(20) default NULL,
  `statusz` varchar(20) NOT NULL default 'üres',
  `osszdij` int(7) NOT NULL default '0',
  `letrehozo` varchar(20) default NULL,
  `ugynokID` int(11) NOT NULL,
  `letrehozas` timestamp NOT NULL default CURRENT_TIMESTAMP,
  `modosito` varchar(20) default NULL,
  `modositas` datetime default NULL,
  PRIMARY KEY  (`szerzodesID`,`partnerID`),
  KEY `szerzodesID` (`szerzodesID`),
  KEY `ugyfelID` (`szerzodoID`),
  KEY `partnerID` (`partnerID`),
  KEY `ugynokID` (`ugynokID`),
  CONSTRAINT `szerzodes_fk` FOREIGN KEY (`partnerID`) REFERENCES `partner` (`partnerID`) ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

a szomorú helyzet az hogy a szerzodesID használom az utolsó számjegyekhez sprintf('%07d',szerzodesID) = 0000001

remélem jól írtam. a sorszám oszlop tartalma = 80010010000001.
hogy világos legyen, a sorszám = kod_elso+partnerID+projektID+szerzodesID
17

használ tranzakciót

aspirany · 2008. Aug. 6. (Sze), 09.44
igen használok tranzakciót.

elég kicsi a sorszám intervallum, 7 számjeg