Új hozzászólás Aktív témák
-
csabyka666
addikt
válasz DNReNTi #2251 üzenetére
Magyarán a DROP, DELETE, TRUNCATE az nem csak nekem, hanem még a proknak sem engedélyezett?
MOD: ...éles adatbázisban természetesen.
[ Szerkesztve ]
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
válasz DNReNTi #2255 üzenetére
Igazából nem fontos, hogy nullázni tudjam, csak tesztelés fázisban vagyok az oldallal, aztán azt gondoltam, hogy én állítottam be valamit rosszul, és azért nem engedi törölni. Főleg azért gondoltam, hogy én szúrtam el, mert teljesen üres táblákon sem működik, de ezek szerint nem ott van a gond, hanem egyszerűen az adatbázis nem fogja sohasem engedni.
Marad a törlés, és újra létrehozás. Azzal nullázódnak az indexek, és végülis az a cél...
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
válasz DNReNTi #2259 üzenetére
Igen igen, nekem is ez van. Több-a-többhöz kapcsolat, és ugye van egy (azaz, hogy több is van) kapcsolótábla, amibe beleraktam az elsődleges kulcsokat, illetve a kapcsolat tulajdonságait.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
válasz DNReNTi #2261 üzenetére
Igen, a törlés működik így, egy bizonyos sorrendben, de az ürítés akkor sem. Most már azt mondom: érthető okokból.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
martonx
veterán
válasz DNReNTi #2540 üzenetére
beleokoskodhatok én is?
Amellett, hogy abszolút egytértek veled, ha már nevezéktanról beszélünk, akkor nem kellene rövidítéseket használni pl. _nm
Még most is gondolkozok rajta, hogy mit jelenthet az az nm? Ráadásul abból, hogy size_and_price bőven látszik, hogy miről is szól az a tábla.
Aztán szerintem az alulvonósdi elég idétlen az SQL nevezéktanokban (html-ben persze tökéletes az alulvonás, de ez most SQL). Miért nem lehet simán SizeAndPrice-nak hívni a táblát? Ez totál szubjektív, de szerintem sokkal szebb felesleges alulvonások nélkül.Én kérek elnézést!
-
-
rum-cajsz
őstag
válasz DNReNTi #2690 üzenetére
Igazából ez nem elméleti kérdés, hanem tervezési. Attól függ, hogy mire fogod használni később a táblát. Ha felosztod külön táblákra, akkor a lekérdezések gyorsabbak lehetnek, illetve az adatírások nem lassítják az olvasást.
Mellesleg ha egy nézetet készítesz a sok tábládra, akkor nem kell mindig a joinokkal vacakolni, elég a nézet nevét használnod. Ha primary keyen kapcsolódnak, akkor az index mentén a join nem számottevő.Nehéz erre tanácsot adni mert ismerni kellene a rendszereteket, és a felhasználási módokat, de ha nagyobb adatmennyiségről van szó (több százezer) akkor én a több táblás megoldást választanám. Ha csak pár ezer felhasználóról van szó, akkor édesmindegy, válaszd azt, ami közelebb áll a lelkedhez.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
-
Sk8erPeter
nagyúr
válasz DNReNTi #2690 üzenetére
Erre a kérdésre a tárolandó adatok ismeretének hiányában tényleg nem nagyon lehet pontosan válaszolni, DE esetedben már kapásból látszik egy ilyen, hogy pl. user_log, ez már eleve feltételezi, hogy itt több bejegyzés is fog szerepelni, mert elég érdekes napló az, amiben minden korábbi értéket folyton felülírsz. (Az időnkénti tisztítás más tészta, mert az is kell, de nem így. ) Ergo ez már kapásból különválasztást, normalizálást igényel.
Ha a user_settings sok mezőt feltételez, és akár már nem is 1-1 kapcsolat van köztük, akkor megint csak kötelező normalizálni (egyrészt ronda a teleokádott tábla, másrészt kerülni kell a szokásos anomáliákat).
A többi adat széjjelbontása is csomó mindentől függ, de tényleg tervezési kérdés, ha szebb különválasztva, akkor tedd azt, ha nem, akkor ne. Nem kell erőltetni, de a jointól sem kell félni, sőt.Sk8erPeter
-
martonx
veterán
válasz DNReNTi #2697 üzenetére
Igaziból 100K-nyi adat annyira kevés, hogy édesmindegy, hogy melyik verziót választjátok. Ez csak magán vélemény, de az sql adattárolás nem olyan mint egy programkód, azaz ami össze tartozik, és 1 - 1 kapcsolat van közöttük mint esetedben a user neve, jelszava és a user lakcíme, azt semmi értelme csak azért szétbontani, és a másik táblában is elkezdeni egy userID-t vezetgetni, indexelni, meg view-t írni föléjük, hogy mégis egynek látszódjanak stb... mert szeparáljuk minél több, minél kisebb részre az adatokat. Ez SQL adattárolás nem pedig OOP programozás.
És ez nem azt jelenti, hogy ne legyen legalább első normálformára hozva a DB struktúra, csak éppen minek csináljunk felesleges roundtripeket, ha ezek az adatok úgyis összetartoznak.
Persze, hogy ez mennyire eset függő, mert simán tudok magam ellen is érvelni, mikor valakinek több száz Gb-os táblái vannak, és minél jobban partícionálni akarja őket, akkor meg pont az lehet a jó, ha több felé van osztva az adattartalom, mert akkor a cluster több része nagyobb párhuzamossággal tud dolgozni a táblán (mondjuk pár száz millió rekordnál egy rosszul elsült update is ki tudja lockolni az egész táblát), de mondjuk egy szál nagy tábla particionálására is megvannak a módszerek.
Száz szónak is egy a vége, ilyen kevés adatnál teljesen mindegy melyik verziót választjátok, én személy szerint nem kezdeném bonyolítani az egyszerűt.
Én kérek elnézést!
-
Brett001
aktív tag
válasz DNReNTi #2701 üzenetére
Hali! Kösz a gyors választ.
1175-öt nem, jó lett köszi!
Ja,mellesleg gondoltam én a WHERE elhagyására (hisz nem kell feltételt szabnunk, hasonlóval próbálkoztam, (el is hagytam) csak unix_timestamp()-t írtam, hisz tudtam, hogy nem kell konkrét érték. Ez igy persze, hogy ne volt jó.
[ Szerkesztve ]
"Felkészültség és fegyelem a sorsunk urává tesz." Farell főtörzsőrmester
-
DNReNTi
őstag
válasz DNReNTi #2893 üzenetére
Na pasztmek.
Jókormán'but without you, my life is incomplete, my days are absolutely gray
-
Jim Tonic
nagyúr
válasz DNReNTi #3028 üzenetére
Lehet stored procedure is vagy trigger is a megoldás, szerintem, de nekem valóban az lenne a lényeg, hogy valaki, akinek ezzel sok tapasztalata van, segítsen egy példával.
Én nem nagyon csináltam ilyet, mivel programból is megoldható, de most van rá okom, hogy kiszervezzem.Alcohol & calculus don't mix. Never drink & derive.
-
-
kezdosql
tag
válasz DNReNTi #3263 üzenetére
Nem, egyikotoknek sincs fogalma se rola, mert ti csak abban gondolkodtok, hogy vannak adattablak, amiket csak ossze kell kapcsolni es kesz.
Az en feladatom az, hogy kitalalni, hogy mi a nyavalya van az adattablaban, es ezt valahogy leirni.
Peldaul kapok egy csv fajlt azzal, hogy "Telephely rezsi".
Az elso oszlop datum, masik ido. Utana van negy oszlop, az oszlop neve szamokbol all, utana jartam, azok a meroorak szamai, tehat tudom, hogy van ket aramot mero ora, egy gazora es egy vizora.
Az adatokbol latni, hogy az egyik arammerot szinte orankent leirtak, a masikat naponta negyszer, a gazorat is van, hogy ket orankent, van, hogy naponta hatszor, a vizorat hetente ketszer.
Ezekrol tudom, hogy 3 tizedesig kell szamokat tartalmaziuk es ures mezo is van.
Emellett van meg hat masik oszlop, amikrol meg nem tudom, hogy mit takarnak az adatok, a tobbseg ures, neha vannak szamok, neha karakterek.Ki kell talalnom, hogy mit jelentenek az oszlopok nevei es leirast kell irni rola, majd csinalni egy olyan nyilvantartas, amibol azonnal latom, hogy melyik fajlban melyik oszlopban milyen adatok vannak.
Raadasul ugy kell megcsinalnom, hogy lassam, hogy melyik fajl hol van, melyik oszlopadatanak meg nem tisztazott a szarmazasa es tartalma, es mik azok, amik rendben vannak.
Messze nincs semmilyen adatbazis sehol, meg csak az adatgyujtesnel tartunk es hihetetlenul nehezen megy.
Remelem, most mar kezditek erteni, mi a problemam.
[ Szerkesztve ]
-
Fecogame
veterán
válasz DNReNTi #3294 üzenetére
Nem értek az SQL-hez, hogyan kellene ezt megírni? Így kezdődik a 14000 soros lekérés:
USE database;
DELETE FROM wp_1_comments WHERE comment_approved = 'spam';
DELETE FROM wp_2_comments WHERE comment_approved = 'spam';
DELETE FROM wp_3_comments WHERE comment_approved = 'spam';Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak