Van egy veletlen generalt szamsorom, hogy tudom megoldani hogy ami az adatbazisban szerepel?

Na most ha generálás pillanatában nem egyezhet meg, akkor ebből következik, hogy azzal, amivel "nem egyezhet meg" össze kell hasonlítani, tehát generált számokat tömbbe tenni, "benne-van-e" függvény lefut, ha false akkor beteszed, ha true akkor újabb generálás addig, míg benne-van-e false és beteszed ismét.

Valamilyen módon el kell tárolnod az adott számot, mert egyébként nem tudhatod, nem lehet visszakövetni: megegyezik -e a később generált szám valamely korábbival.

Hány számról lenne szó?

Nem teljesen világosan fogalmaztad.Tegyük fel, hogy így festene átfogalmazva:

A kérdés szöveges mező: Hogy lehet megoldani az alábbi módon a random generálást?

konkrétumokkal kiegészítve szöveges mező:

Php és mysql felhasználásával szeretném megoldani, hogy hogy generálás pillanatában már nem egyezhet meg a két szám amit generálok. Tehát nincs lehetőségem összehasonlítani hogy volt e már,ha igen akkor újra generálni.

-------

@08:22

Ez a nyilvánvaló megoldás. Az általam értelmezett kérdés szerint és a te gondolatmeneted mentén ez úgy festene, hogy beolvassa az adatbázisból a számokat egy php tömbbe és ott elvégzi amit leírtál. Úgy végzi el,hogy amit amit random választott azt egy másik tömbbe rakja. Hogy választ? Az adatbázisból gyártott php tömbnek random indexe szerinti értéket veszi.

"Hány számról lenne szó?" Az se mindegy persze. Csak egy dolgot kiemelve ezzel kapcsolatban. Ha sok számod van és kezded e szerint kiválasztani őket akkor egyre lassul be az egész mert egyre gyakrabban futsz bele, hogy az már volt és ráadásul az idők összegződnek is.

Ha ugyanennél a koncepciónál maradunk én biztos, hogy nem így csinálnám. Amatőr megoldás. Először is adatbázis szinten biztosítanám, hogy egyedi számok legyenek a táblába ezért ezt az oszlopot UNIQUE-ra állítanám vagy akár PRIMARY KEY is lehet és ez az egyetlen oszlopa a táblámnak. Beolvasnám az egészet egy php tömbbe. A tömbömet 2 fele particionálnám, logikailag kezelném így. Az első fele a tömbnek azokat a számokat tartalmazza amik nem lettek kisorsolva a másik fele amik kilettek már. Egy változó jelölné nevezzük i-nek most (a kódba nem feltétlen így jelölném), hogy ennél kisebb vagy egyenlő indexek nem lettek a többi kilett. Az i értéke kezdetben a tömb métere -1. Egy r egész randomot generálnék 0-tól i-ig tartományon belül. Az i-ik és r-ik indexen lévő elemet megcserélném utána i-t 1-el csökkenteném. Ezt addig lehet ismételgetni maximum amíg i 0-ig elmegy. Az i-nél nagyobb indexű tömbelemek lesznek azok amelyeket generáltunk úgy hogy nem egyezik meg, ellenőrizni se kell hogy van e egyezés, hisz eleve lehetetlenség, így nincs az a fajta belassulás sem. Külön tömbbe is pakolhatjuk amiket már kisorsoltunk, csak ebbe az volt még az extra hogy plusz memóriaigénye sincs.

Az se biztos hogy így gondolta a kérdező. Az megint más, ha minden egyes futásra csak 1 szám kell ami nem volt vagy n darab szám ami nem volt még. Ugyan e szerint a logikával el lehet játszani sql-be is a dolgot. Csak ha többen is lekérik akkor zárak is kellenek, hogy ne legyen inkonzisztencia.

@08:48

Nem egészen. Kezdem ott, hogy szó se volt hogy egész számok vannak. Ha csak 0-1 közöttiek, akkor a különbség 1 a lehetséges maximum és minimum között ... Továbbá ha például a teljes integer tartományból választ, akkor azt győzd letárolni. Állatira pazarló lenne, de nem is muszáj ekkora, ha csak 1 és 1 millió között választ 5 számot akkor se mondható jó memóriagazdálkodásnak. Lehet hogy 10 lépésközzel vannak a számok, már kapásból 10x-es pazarlás ha így csinálnánk ahogy mondtad stb. Én fordítva közelíteném meg, ha e szerint kellene. Nem azt tárolnám le és törölném ami lehet, hanem azt tárolnám ami már volt. Kihasználva a php tömb tulajdonságait, hogy lehet hogy 10-ik indexű eleme létezik de 8-ik attól tud nem létezni. A részleteire meg rá lehet jönni, had legyen egy kis gondolkodás is, ne csak mindent a szájába rág típusú hozzászólás. Csak ha erre van szükség alapból nem is kell sql, kivéve ha ... . A ha után temérdek dolgot be lehet helyettesíteni.

"generalt sorszam 100%,hogy ne legyen egy userhez kotheto"

Ne lehessen visszakövetni (pontosabban ne legyen beépítve rendszerbe a visszakövetés)?

Sorszámot is írsz a sorszám az 1,2,3,4,5,6 stb kiszámítható hogy mi lesz a következő eleme. Más lépésközzel is növekedhet. AUTO INCREMENT sql szinten.

Jól gondolom, hogy 8-12 karakter(0-9) hosszú egyedi azonosítót akarsz generálni minden új belépőnek/regisztrálónak?