Kezdőoldal » Számítástechnika » Programozás » Nem hülyeség az, hogy egy...

Nem hülyeség az, hogy egy adatbázis táblába mindig rak valaki egy auto incrementes id-t?

Figyelt kérdés

Csomó helyen láttam, hogy ha kell, ha nem kell auto incrementes id az azonosítója egy táblának, mármint az elsődleges kulcsa.

Elvileg bármilyen egyedi, nem megismétlődő érték lehet nem?



2018. jan. 23. 10:38
1 2
 1/17 anonim ***** válasza:
11%
Elvileg igen. Csak épp a tábla létrehozásakor erről a rendszernek fogalma sincs, vagyis csinál egyet automatikusan, amit aztán a lusta programozó jól otthagy.
2018. jan. 23. 10:59
Hasznos számodra ez a válasz?
 2/17 anonim ***** válasza:
100%
Ha az azonosításon kívül nincs más célod az id-val, akkor mégis miért lenne jó, hogy kézzel generálj egy egyedi értéket?
2018. jan. 23. 11:00
Hasznos számodra ez a válasz?
 3/17 anonim ***** válasza:
60%
Minden normális helyen autoincrement-es id-t használnak. Így lehet a legegyszerűbben garantálni az egyediséget.
2018. jan. 23. 11:21
Hasznos számodra ez a válasz?
 4/17 anonim ***** válasza:
70%
Egyszerű, átlátható, jól indexelhető. Nem látom, miért lenne hülyeség.
2018. jan. 23. 11:24
Hasznos számodra ez a válasz?
 5/17 anonim ***** válasza:
100%
Miért lenne hülyeség? Milyen más módszert ismersz még arra, hogy garantáltan egyedi ID-t kapj időrabló számítások és lekérdezések nélkül?
2018. jan. 23. 11:55
Hasznos számodra ez a válasz?
 6/17 anonim ***** válasza:
58%

Kicsit sem hülyeség .... Egy programozási nyelvel (pl.: php) szeretnél mindig egy egyedi random számot generálni vagy mi?


Az mitől lenne egyszerűbb?

Mitől lenne jól átláthatóbb?

Mitől lenne jobb egy olyan megoldás?

2018. jan. 23. 12:21
Hasznos számodra ez a válasz?
 7/17 A kérdező kommentje:

Mondjuk van egy fagylaltboltod, és a fagylaltokat szeretnéd azonosítani az elnevezésük alapján. Mindegy fagyi egyedi névvel rendelkezik.

Kéne ide egy auto incrementes id, vagy új fagyitípus felvitelekor inkább ellenőrizni kéne, hogy az adott típus megtalálható-e az adatbázisban?

(Amit egyébként is kell, mert két ugyanolyan nevű minek?)

Na erre lettem volna kíváncsi.

2018. jan. 23. 14:28
 8/17 anonim ***** válasza:
58%

Some people prefer to use an integer column as the primary key, to serve as a surrogate key that never needs to change, even if other columns are subject to change. Although there's nothing preventing a natural primary key from being changeable too, you'd have to use cascading foreign key constraints to ensure that the foreign keys in related tables are updated in sync with any such change.



The primary key being a 32-bit integer instead of a varchar can save space. The choice between a int or a varchar foreign key column in every other table that references your user table can be a good reason.



Inserting to the primary key index is a little bit more efficient if you add new rows to the end of the index, compared to of wedging them into the middle of the index. Indexes in MySQL tables are usually B+Tree data structures, and you can study these to understand how they perform.



Some application frameworks prefer the convention that every table in your database has a primary key column called id, instead of using natural keys or compound keys. Following such conventions can make certain programming tasks simpler.

2018. jan. 23. 15:29
Hasznos számodra ez a válasz?
 9/17 anonim ***** válasza:
73%
#7: és ha az árakat vagy a recepteket egy külön táblába tárolod, akkor oda is letárolod a fagylaltok nevét még egyszer, mint idegen kulcs? Minek? Sokkal egyszerűbb int vagy long ID-re hivatkozni. Kevesebb helyet foglal, gyorsabb keresni, stb.
2018. jan. 23. 16:16
Hasznos számodra ez a válasz?
 10/17 anonim ***** válasza:
79%
#7, az "incrementes id" fogalmi modellben nem jó, fizikai modellben jó. Keverni látszol a kettőt.
2018. jan. 23. 16:46
Hasznos számodra ez a válasz?
1 2

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!