ugrás a tartalomhoz

Adattáblában automatikusan növekvő mező elsődleges kulcs nélkül

ceops · 2007. Dec. 14. (P), 16.29
Helló!



Van egy adattáblám; van benne "id" mező, ami az elsödleges kulcs!
Viszont ha egy rekordot kitörlök, akkor 1-es után 3-as id-számú rekord következik! Hogyan lehet egy olyan mezőt csinálni, ami ugyanúgy automatikusan növekszik, viszont rekord törlésénél nem hagy ki egy számot sem?

Így kreálok id mezőt!
`id` BIGINT NOT NULL AUTO_INCREMENT


Előre is köszi!
Joles
‹ index.php-t futtatás helyett meg akarja nyitni fgetcsv-vel kiolvasott ékezetes karakterek ›
 ■
1

minek?

TeeCee · 2007. Dec. 14. (P), 16.34
Pár napja volt ez kérdés, vagy legalábbis hasonló. Az elsődleges kulcs feladata nem a folytonosság, hanem az egyediség!

Ha mindenáron folytonos számozást akarsz, akkor törlés után egy UPDATE-tel tudod elérni, hogy a törölt számutáni ID-k egyel kisebbek legyenek...
2

szerintem nem is kell

Szekeres Gergő · 2007. Dec. 14. (P), 17.06
azon kívül, hogy "hülyén" néz ki mi a problémád ezzel?:)
3

lehet, rosszul fogalmaztam? :)

ceops · 2007. Dec. 14. (P), 17.17
Először is köszi a hozzászólásokat!

Lehet, hogy nem fogalmaztam jól...
Nyah... szóval egy blogot készítek, hozzászólásokkal! Minden egyes hozzászólás elején ott van az id szám, ami jelzi, h "hányadik a sorban". Viszont ha egy hozzászólást törölni szeretnék, akkor a sor elején található id szám is törlödik és így a következő id számú hozzászólást mutatja.
Tehát olyan is lehet, h 1-es után a 3. hozzászólás lesz olvasható!
Hátt ezzel van a problémám!

Egyébként lehet UPDATE-et nyomni php-ből is? Tehát ha valaki küld egy hozzászólást, akkor frissítse a táblát?
4

továbbra is egyedi

Drawain · 2007. Dec. 14. (P), 17.32
Éppen ez a lényege a hozzászólás ID-jének, hogy egyedinek kell maradnia. Például ha van "válasz erre" gomb, akkor az valószínűleg azt az id-t menti el a hozzászólás mellé, amire válaszol a felhasználó - azonban ha variálod ezeket az id-ket, akkor a "válasz erre" mezőket is update-elni kell, és így tovább ha bonyolódik a helyzet. Ráadásul ha a hozzászólás id-jét jeleníted meg egy blog-post után, és egy táblában tárolod az összes hozzászólást, akkor nem 1-től fognak számozódni a későbbi hozzászólásokhoz tartozó id-k. Szerintem érdemes felvenni még egy mezőt, amiben a postban való helyét (id-t) tárolod, vagy az id-ket szimplán php-val számolni a kiíratásnál.
5

Értem...

ceops · 2007. Dec. 14. (P), 17.39
...és azt hogy kell? :)

Egyébként minden egyes blogbejegyzésnek külön adattáblát generálok, tehát mindig 1-től kezdi számolni!

Hogy kell UPDATE-elni?
6

Nem jó ötlet!

fchris82 · 2007. Dec. 14. (P), 18.38
Az adatbázisban egy "fajta" táblából egy legyen! Egyrészt igencsak elszaporodhatnak a táblák, másrészt teljesen felesleges is. Beszúrsz még egy oszlopot és meg van oldva.
Példa két táblával: entries, comments

CREATE TABLE entries (
  id SERIAL,
  created DATETIME,
  title VARCHAR(255),
  content TEXT,

  PRIMARY KEY (id),
  INDEX icreated(created)
) ENGINE=InnoDB;

CREATE TABLE comments (
  id SERIAL,
  entry_id BIGINT UNSIGNED NOT NULL,
  user_id BIGINT UNSIGNED NOT NULL,
  antecedent_id BIGINT USNIGEND,
  created DATETIME,
  content TEXT,

  PRIMARY KEY (id),
  INDEX icreated (created),
  INDEX iantecedent_id (antecedent_id),
  FOREIGN KEY (entry_id) REFERENCES entries(id) ON UPDATE CASCADE ON DELETE CASCADE,
  FOREIGN KEY (user_id) REFERENCES users(id) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=InnoDB;
Persze most sokmindenen lehetne még változtatni, de nagyjából a fenti módszer szerint kellene csinálni. Ezekután egyetlen SELECT-tel kiolvasható, hogy egy bejegyzéshez (legyen 23 az azonosítója) milyen hozzászólások vannak:

SELECT
  c.*,
  u.name
FROM
  comments AS c,
  users    AS u
WHERE
  c.entry_id = 23 AND
  c.user_id  = u.id
ORDER BY created;
Ezekután majd a php-ban számozgatod, hogy hanyadik hozzászólásról is van szó.
7

nem sikerül :'(

ceops · 2007. Dec. 14. (P), 20.30
Tudom, hogy most már a fenébe küldtök, de a fenti módszer sem hatásos...
Az én táblám valamivel egyszerűbb! Próbáltam beszúrni a sorokat, de csak hibaüzeneteket írt ki a MySQL :(

Szal' nekem csak 1 táblám van, ami a comment-eket tartalmazza:

CREATE TABLE `user071214` (
  `id` BIGINT NOT NULL AUTO_INCREMENT, 
  `name` VARCHAR(100) NOT NULL, 
  `mail` VARCHAR(100) NOT NULL, 
  `url` VARCHAR(100) NOT NULL, 
  `comment` TEXT NOT NULL, 
  `date` VARCHAR(100) NOT NULL,
  PRIMARY KEY (`id`)
);
Ezek után mi a teendő?


Előre is köszi...!
8

...ezek után?...

TeeCee · 2007. Dec. 16. (V), 19.53
... megírod a MySQL hibaüzenetet!
A parafenomén-klub péntekenként van :P
9

no?

PredMan · 2007. Dec. 18. (K), 11.43
megoldódott már a probléma? :D
10

ajjaj

griphons · 2007. Dec. 18. (K), 17.25
Én nem nagyon látom át mi a problémád, illetve, hogy mit nem értesz az előzőekben.

A lényeg:
1. egy táblában tárold az összes blogot, ne kreálj mindnek külön táblát, mert káosz lesz. mysql lekérdezéssel úgyis egyszerűen kiválogathatod a célpontokat
2. ne az id-t írasd ki a bejegyzés elején, az nem arra való, hanem inkább számoltasd a php-val a kiíratott bejegyzést, és azt írd elé

Ez ennyire egyszerű.
11

postot törölni?

Szekeres Gergő · 2007. Dec. 19. (Sze), 09.50
lehet én vagyok maradi, de minek kellene egy postot törölni egy blogból? :/

inkább archiváld egy flaggel!
12

pl: viagra?...

TeeCee · 2007. Dec. 19. (Sze), 14.48
... mi van, ha egy script mégis megeszi a CAPTCHA-t és kitölti viagra-reklámmal, meg 10dollásor WindowsDVD-kkel a hozzászólásokat?
Esetleg dupla-postolás?
13

ez tüneti kezelés..

Szekeres Gergő · 2007. Dec. 19. (Sze), 15.11
sessionos megoldással nagyon jól lehet mindkettő ellen védekezni. azt kell használni, nem pedig egész nap törölgetni a viagrareklámokat. Szerintem.
14

Az biztos, ...

TeeCee · 2007. Dec. 19. (Sze), 15.34
de gondolj bele, hogy akinél ez a kérdés így felmerül, az milyen CAPTCHA-val rendelkezik, és milyen módon próbálja a portolás-újratöltést kivédeni ;-)
(ez most nem kritika, hanem pusztán megjegyzés a tanulási szakasz elejére vonatkozóan!)

session-nal hogyan védekezel a spammerek ellen?

Biztos énis béna vagyok, de én szoktam törlést biztosítani az adminnak, kivéve, ha kifejezetten nem kérik, vagy más megoldás miatt nem kell/tilos. Szerintem.
15

Védekezés

Max Logan · 2007. Dec. 19. (Sze), 15.43
Session-nal hogyan védekezel a spammerek ellen?
Én úgy csinálom, hogy x mp-nek el kell tellnie két bejegyzés között (jellemzően vendégkönyvnél használom). Egy emberi spammer nagy eséllyel nem fog 1 perceket várogatni két spam komment között.

A botok pedig kapnak olyan nevű input mezőt, amit nem ismernek fel. Ilyen esetben nem írnak oda mail címet ahova kellene és ha a beküldés előfeltétele egy helyes formájú mail cím, akkor már meg is van oldva a dolog (és nem kell semmilyen spam filter, nem kell karbantartani a filter adatbázisát).
16

elég ronda megoldás sztem

griphons · 2007. Dec. 20. (Cs), 09.11
egy egyszerű fórumba postoláskor képi információ-felismerés inputot? gonosz dolog
azt meg egyenesen utálom, amikor két post között perceket várnom kell. :( Főleg amikor pörög a fórum, és én enm tudok reagálni. ehh ez is gonosz dolog, sőt embertelen :P (mondjuk egy vendégkönyvnél elmegy)

A legemberibb megoldás az e-mail-es reg valóban.
17

fórum?

gex · 2007. Dec. 20. (Cs), 13.08
olvass vissza, senki nem beszélt fórumról. egy bloggal kapcsolatban merültek fel kérdések, ahol bejegyzések vannak és hozzászólások. ezek jellemzően nem szoktak "pörögni".
18

Vendégkönyv

Max Logan · 2007. Dec. 20. (Cs), 14.06
Mint írtam az x mp-es várakozást vendégkönyvnél használom. Egy vendégkönyv esetében pedig ne akarjon senki egymás után több bejegyzést írni, mert nem arra való. Tehát ez az emberi spam kiküszöbölésére elég jó megoldás (bár az emberi hülyeség végtelen, szóval adott esetben egy elszánt, feldühödött spammer képes ott ülni és percenként post-olni).

Ami a botokat illeti jól kell megválasztani az input mezők nevét + kell vmi feltétel (lásd helyes formátumú mail cím vizsgálat), ami miatt a botok elbuknak.

CAPTCHA-t nem szeressük, csak a legvégső esetben szabad használni - sztem - és ez alatt értem a szöveges megoldásokat is (mennyi x + y, stb.).
19

emailes reg sztem alap

Szekeres Gergő · 2007. Dec. 20. (Cs), 16.17
de nem feltétlen megoldás. ugyanakkor én is annak a híve vagyok, hogy a biztonság miatt ne áldozzunk túl sokat a kényelem miatt, legalábbis ne olyan szinten, hogy az kényelmetlen legyen. ezért használom az időkorlátot én is, mert ez nem jár egy normális user számára semmilyen megkötéssel, észre sem veszi.