Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc

[mihnea sim]

Am urmatorul tabel:
id (tiny int(3) unsigned primary key, index, not null, unique, autoincrement)
text (varchar)

In acest tabel introduc des date si tot atat de des sterg datele mai vechi din el. Adaugarea o fac automat, in sensul ca il las pe el sa imi puna id-ul fiecarei inregistrari - ceva de genul "insert into t(text) values('un text')" si el imi pune id-ul automat.

Problema este: Cand ajunge la 255, valoare maxima a id-ului, se opreste (asta e si logic), dar ma deranjeaza ca nu 'trece' sa completeze id-urile sterse odata. Adica daca odata mi-a pus la o inregistrarea id-ul 10, si apoi a fost stearsa, acest id ramane necompletat. Nu vreau sa imi faca asta, ci vreau ca atunci cand ajunge la capat (255) sa se intoarca si sa faca intregistrari si cu id-urile pe care odata le-a sters. Presupun ca e o chestie de declarare a tipului de tabel sql. Am incercat multe variante, dar nu mi-a iesit nimic. De fiecare data se blocheaza la 255. Stiu ca as putea sa il 'pacalesc' si printr-un script php, care sa ii gaseasca un id liber si sa il foloseasca, dar totusi ar fi mai comoda o rezolvare a bazei de date. Multumesc pentru atentie!

[Cata.]

Si eu sunt interesat de acest lucru. Eu as vrea daca s-ar putea dupa ce sterg id-ul 10 din 12 sa nu ramana 1,2,3,4,5,6,7,8,9,11,12 vreau sa ramana 1----8,9,10,11 singur sa mai scada un id sau cat am sters . Dar ma multumesc daca ar merge si cu ce a zis mihnea

[beeuser]

Nu inteleg de ce vreti sa beliti tabela?
Nu se merita, oricum se incrementeaza. ce vreti voi necesita query-uri in plus.
Mai bine in loc de tinyint puneti smallint sau int.
....
Oricum id-urile se folosesc pt. identificare, de fapt pe client continutul il intereseaza.
Ce are daca dai page.php?id=10 sau page.php?id=11?
Cu ce-l afecteaza pe client? ....
Confused....

[beeuser]

Inca o completare,
Daca ai chei straine in alte tabele, si pe acelea tre sa le schimbi. Nu are sens. Anyway.
Gandeste-te ca ai 1000 de inregistari de exemplu. Si stergi inregistrarea cu ID=2. Ce faci cu restu?...

[mihnea sim]

da, aia e situatia cand chiar ai nevoie sa iti lase loc liber unde s-a sters. Dar problema e ca "se umple" si nu mai are unde. daca o fac int sau big int, ocupa si spatiu si in plus, o sa se umple si aia. Vreau sa pastrez in tabel lunar IP-urile userilor care viziteaza pagina (tb sa zic de la inceput, ca sa fiu mai explicit). La inceput de luna sterg tot ce a fost luna trecuta.

[beeuser]

Uite tipurile de date numerice

TINYINT( ) -128 to 127 normal
0 to 255 UNSIGNED.
SMALLINT( ) -32768 to 32767 normal
0 to 65535 UNSIGNED.
MEDIUMINT( ) -8388608 to 8388607 normal
0 to 16777215 UNSIGNED.
INT( ) -2147483648 to 2147483647 normal
0 to 4294967295 UNSIGNED.
BIGINT( ) -9223372036854775808 to 9223372036854775807 normal
0 to 18446744073709551615 UNSIGNED.
FLOAT A small number with a floating decimal point.
DOUBLE( , ) A large number with a floating decimal point.
DECIMAL( , ) A DOUBLE stored as a string , allowing for a fixed decimal point.

vrei sa zici ca ti se umple BIGINT-ul unsigned? :)

doar n-oi avea tu atatia vizitatori.
Daca vrei sa stergi la inceput de luna, stergi tot si poti sa resetezi auto_incrementul.

ALTER TABLE tbl_name AUTO_INCREMENT = 0
got it?

[mihnea sim]

Asta e !! Mersi mult. Nu imi convine ca bigint-ul ocupa spatiu si .. in total, pot sa fac atatia useri in vreo .. 2000 ani (1000 * 2000 *30) :D Inca odata multumesc pentru timpul acordat

[ExcalIbvr]

:arrow: A nu se confunda int(3) cu TinyINT() unsigned.

[Radical]

beeuser a scris: BIGINT( ) -9223372036854775808 to 9223372036854775807 normal
0 to 18446744073709551615 UNSIGNED.

vrei sa zici ca ti se umple BIGINT-ul unsigned? :)

Beeuser a pus punctul pe i... Si daca tot i se umple BIGINT UNSIGNED atunci sa rugam pe cei de la MySQL si pe cei de la PHP... daca (2^64)-1 nu mai ajunge... sa puna mana sa faca un HUGE-INT adica (2^128)-1... si daca tot fac pe ala sa faca si un HUMONGOUS-INT adica (2^256)-1...

Maaaaaaaaaama cat spatiu pe disk ii papa... Un TINYINT ia 1 byte pe cand un SMALLINT ia 2 bytes... deci la maximum de 255 de vizitatori in loc sa ii ocupe 255 bytes o sa ii ocupe 510... adica o juma de Kilo !

Hai cu totii sa ne ocupam de aceasta optimizare... ... ... ... ... ... ... ... ... ... ... ... ...

[arond]

Radical a scris: Hai cu totii sa ne ocupam de aceasta optimizare... ... ... ... ... ... ... ... ... ... ... ... ...

Radical :lol:

[mihnea sim]

La aia ma gandisem si eu arond ...
Oricum, treaba e ca nu e chiar asa simplu. Pai de ce credeti ca "s-au inventat" tipuri diferite de date pentru integer .. ca sa optimizezi pt ceea ce iti trebuie. Asa de ce nu am folosi peste tot bigint ? S-au de ce sa mai normalizam tabelele?

[Radical]

mihnea sim a scris: S-au de ce sa mai normalizam tabelele? De acord man, dar sa nu ajungem la paranoia !

Salvarea a o jumatate de kilo... nu e o problema de luat in calcul...

Dupa o normalizare rea... verifici daca merita... daca nu faci si operatia inversa... sa-i zicem "DEnormalizare" !

[PHPRomania Bot]