Új hozzászólás Aktív témák
-
#1467
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Hali!
Van egy tábla, amiben olybá tűnik, állandóan egy VARCHAR(32)-mező szerint kérdeznék le (amiben egy olyan string van, ami semmiképp nem tartalmaz whitespace-eket), ezenkívül egy INT-mező van, de ergo összesen 2 mezős a tábla, de pont a stringhez tartozó INT-értéket kérdezném majd le, így az INT-mező igazából másodlagos.
Úgy tudom, VARCHAR-mezőre primary key-t tenni nem túl üdvös megoldás például teljesítmény-tekintetben. Nektek mi a véleményetek erről, igazán gond-e primary key-ként használni egy VARCHAR-mezőt egy viszonylag kevés adatot tartalmazó táblában? Van tapasztalatotok/meglátásotok ezzel kapcsolatban? -
#1458
Sk8erPeter
nagyúr
bbTamas77
#1457
Sk8erPeter
nagyúr
válasz
bbTamas77
#1457
üzenetére
Magyar leírás lehet, hogy nincs, de a hivatalos dokumentáció sztem elég érthető:
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-aton
INET_ATON(expr)
Given the dotted-quad representation of an IPv4 network address as a string, returns an integer that represents the numeric value of the address in network byte order (big endian). INET_ATON() returns NULL if it does not understand its argument.
mysql> SELECT INET_ATON('10.0.5.9');
-> 167773449
For this example, the return value is calculated as 10×256^3 + 0×256^2 + 5×256 + 9.
[...]http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-ntoa
" INET_NTOA(expr)
Given a numeric IPv4 network address in network byte order, returns the dotted-quad representation of the address as a binary string. INET_NTOA() returns NULL if it does not understand its argument.
mysql> SELECT INET_NTOA(167773449);
-> '10.0.5.9'
[...]"Röviden: INET_ATON()-nak egy IPv4-címet adsz át paraméterül stringként, ez cserébe ennek a numerikus értékét adja vissza integerként, a számolás mikéntjét a helyiértékek szerint mutatja a képlet. Az INET_NTOA() pedig ugyanez visszafelé (IPv4-címnek megfelelő integer-értéket adsz át paraméterül, stringet kapsz válaszul).
-
#1456
Sk8erPeter
nagyúr
PiXeL90
#1455
Sk8erPeter
nagyúr
válasz
PiXeL90
#1455
üzenetére
Most ezt ennyi részletből elég nehéz lenne kitalálni... Azt sem tudjuk, bugról lehet-e szó (verziót sem írtál), nem mutattál egy nyomorék screenshotot sem, ezek szerint más adatbázis-böngészőben sem nézted meg (mint pl. a MySQL Workbench), plusz azt sem tudjuk, milyen query-t futtattál.
Szóval a válasz csak egy nagy kérdőjel.
-
#1439
Sk8erPeter
nagyúr
biker
#1434
Sk8erPeter
nagyúr
Ahogy előttem leírták, a kiindulási pont az volt, hogy megkérdőjelezted az indexek jelentőségét, meg a táblák szétválasztásának elvét (amit nem véletlenül szokás alkalmazni), nem pedig az, hogy "szétszedjünk darabokra". Nyilván a fejlesztésben vannak pontok, amikor az újrastrukturálás nehézkes, és az ember a határidő tartása érdekében csúnyább megoldásokra kényszerül, de ettől még az elv nem hibás. Ebben alakult ki a vita, ezekről próbáltunk győzködni, nem az volt a cél (de sztem ez egyértelmű), hogy csak azért is kritizáljunk.
"az akciós kérdésben nem értünk egyet, a többiben igen"
Eddig úgy tűnt, azt írtad le, hogy a termékek alapvető adataival egy táblában kezeled, mikor kezdődött, és zárult le egy bizonyos időszakban bevezetett akció, meg mi az akciós és korábbi ár, és hasonlók, és ezeket kell mindig felülírni módosításkor, de ha utólag ki akarnál egy kimutatást készíteni arról, hogy melyik időszakban milyen áron, milyen akció keretében, mekkora kereslet volt az adott termékre, akkor gondban lennél, mivel nincs history-szerűen nyilvántartva, korábban milyen árakon futott a termék (és mikor), csak felül van csapva a korábbi érték, aztán kész. De lehet, hogy ebben félreértés volt, és nem így kell elképzelni, abból indultunk ki, amilyen információkat leírtál. -
#1438
Sk8erPeter
nagyúr
fordfairlane
#1433
Sk8erPeter
nagyúr
válasz
fordfairlane
#1433
üzenetére
Nem is azt írtam, hogy minden esetben tankönyvszerűen kellene kezelni, inkább logikusan szeparálva a felelősségeket, meg kényelmesen kezelhetően, persze az hozzátartozik, hogy nem véletlenül tanítják így, mert ezek bevált alapelvek, de igazából Te is nagyjából ezt írtad (leírtad Te is az okokat, amik miatt ezek hosszabb távon jól használható adatszerkezetek).
-
#1432
Sk8erPeter
nagyúr
fordfairlane
#1431
Sk8erPeter
nagyúr
válasz
fordfairlane
#1431
üzenetére
Ja, de érted, ez tipikusan olyan, hogy valamelyik pontnál kénytelen lesz elkezdeni gányolni, mert nem kényelmesen, külön kezelhetők ezek az alapvetően nem szorosan egybetartozó adatok (bár tény, olyan szempontból "kényelmes", hogy nem kell joinolni, így talán a query rövidebb lesz, de kábé itt meg is áll az előnye), ezért sokkal jobban jár, ha különválasztja.
-
#1428
Sk8erPeter
nagyúr
biker
#1419
Sk8erPeter
nagyúr
"Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?"
Senki nem mondta, hogy ne lehetne kigyűjteni, de ezek szerint még mindig nem érted, hogy mi a probléma azzal az elvvel, amit alkalmazol, ami mondjuk elég szomorú. Tényleg ennyire nem vágod az alapvető normalizálási elveket?
A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod. Most ugyanazt mondtam el másként, mint amit már korábban is leírtam."Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van"
Kezd tényleg fárasztó lenni. Tudtommal elég régóta vagy fejlesztő, ehhez képest bevált alapelveken vitatkozol, mint aki az évek során jól begubózott, és a saját jól megszokott tervezési elvein kívül mást nem is hajlandó elfogadni, kritikát meg aztán végképp nem. Pedig ha előveszel akármilyen jobbféle adatbázis-kezelős könyvet, ami a kezdő szinttől indít, hidd el, hogy ezekkel az elvekkel elég hamar találkozol...
fordfairlane amúgy előttem már leírta nagyvonalakban az alapvető problémákat, de erre azt reagáltad neki, hogy "az alapoktol zavaros amit irsz
Egyaltalan Te erted?" - most azon kezdtél el kattogni, hogy de hiszen az akció termék nélkül nem is létezhet, de azon még mindig nem gondolkoztál el, hogy vajon miért állítjuk többen is már régóta, hogy alapvető, nem változó paraméterek egyszerűen nem tehetők egy táblába állandóan változó - és például megőrizendő - paraméterekkel (ismét leírtam, hátha átjön), mert az rengeteg kellemetlen problémát szül (átnevezési, törlési, beszúrási probléma, esetleges inkonzisztencia, és az összes többi dolog, amiről már vakerásztunk, vagy amiről még nem). Megdöbbentő ez a vita. Olyan, mintha nem lenne tiszta számodra, mire valók a kapcsolótáblák, az idegen kulcsok, egyáltalán mik azok a normálformák, miért használják manapság ezeket... Ha nem tudod, akkor inkább kérdezz vissza, miért is lenne jobb ezeket használni, de ne úgy pattintsd le magadról az egész témát, mintha még mi lennénk a korlátoltak, hogy nem fogjuk fel, hogy a Te szerkezeted milyen csodálatos (nem az). Kissé türelmetlenné teszed az embert ezzel a stílussal.=====
(#1417) Athlon64+ :
"Mi kérünk elnézést?
"
Jaja, nagyon úgy tűnik.
Ne haragudj, biker. -
#1416
Sk8erPeter
nagyúr
biker
#1415
Sk8erPeter
nagyúr
Kicsit túlságosan felkaptad a vizet, senkinek nem az volt a célja, hogy itt kifejezetten téged fikázzon, nem a személyedet érte kritika, hanem azt, amit állítottál, és a tervezési/fejlesztési elveket, amiket alkalmazol - szakmai témázás során ez nagyon nem mindegy. Kezdjük ott, hogy először Te állítottad azt egy korábbi javaslatra, hogy az indexelés nem gyorsít látványosan (bullshit), és pluszban remek példaként akartad bemutatni a 30+ oszlopos szerkezetet, erre kaptad a reakciót, hogy egyrészt baromság, hogy az indexelés ne gyorsíthatna látványosan (egyébként már csak azért sem értem az állításodat, mert a Te példádban is 10+ másodperceket javított csak az index már önmagában is, az nem elég látványos? Egészen másképp hangzik, ha azt állítod, hogy önmagában egy oszlopra tett index nem biztos, hogy elég, mert ez így igaz is.), másrészt a 30+ oszlopos táblánál már felmerül a gyanú, hogy tervezési hibáról van szó. Mindkét érv meg lett indokolva, alátámasztva, nem csak levegőben röpködő nagy szavak voltak. Többfelől is kaptál reakciót, mert igen megdöbbentő dolgot állítottál, ami pont szembemegy az alapvető adatbázis-normalizálási elvekkel; erre nem az a megfelelő reakció, hogy "sok lúd disznót győz" (mintha azt üzennéd, hogy nálad van az igazság, csak mi nem értjük) - több emberrel miért ne lehetne szakmai vitát folytatni?
De könyörgöm, egy dolgot magyarázz már meg, mert nagyon kitartasz mellette: komolyan úgy gondolod, hogy az a megfelelő adatbázis-tervezési elv, hogy a termék nevével, leírásával, ehhez hasonló alapvető (ritkán változó) paramétereivel egy táblába dobod be az akciós és aktuális árat, szállítót, hasonlókat? Szerinted az a baj, ha termék_id szerint össze vannak kapcsolva a különböző adatok, és ezáltal a termék_id többször is szerepelni fog? Ezt írod: "akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?". Ez alapján komolynak tűnik, akkor viszont alapvető tervezési elveket sértesz meg, pedig ahogy már írták, ezek szétbontása tényleg az első pár adatbázis-kezelési és -tervezési lecke között van, és akkor ezek szerint az nagyon kimaradt.
Ha meg félreérthető, amit írsz, akkor próbálj meg nem úgy írni, mintha csetelnél, mert nagyon zavaró.Egyébként ezzel kapcsolatos hsz.-eket nem kell OFF-ba tenni, mert szakmai, MySQL-t érintő vitáról van szó, épp, ami a topic címe.
-
#1411
Sk8erPeter
nagyúr
biker
#1410
Sk8erPeter
nagyúr
Csak gyorsan futottam át, amit írtál, de sztem a legrosszabb példákat írtad, például ha van egy adott termék, aminek az alapvető jellemzői nem változnak, de a szállítói adatok bőven változhatnak (például adott hónapban valamiért más a szállítója ugyanannak a terméknek), akkor azok miért kell, hogy ugyanott szerepeljenek, ahol a termék id, név, leírás? Vagy például az akció eleje és vége hogy lehetne már ugyanabban a táblában, sőt, ugyanabban a rekordban tárolható?
Az ára, akciós ára meg aztán végképp állandóan változik... Szerinted nem épp az a feleslegesen redundáns, hogy a leírás ennyiszer szerepel a táblában? Vagy nem is értem az elgondolást.
Az a kijelentés meg, hogy az indexelések nem gyorsíthatnak jelentősen a rengeteg adatot tartalmazó táblában való keresésen, már inkább a vicces kategória szerintem. -
#1393
Sk8erPeter
nagyúr
Jim-Y
#1390
-
#1381
Sk8erPeter
nagyúr
martonx
#1376
-
#1373
Sk8erPeter
nagyúr
martonx
#1361
Sk8erPeter
nagyúr
válasz
martonx
#1361
üzenetére
"noha nem kis munka egy tisztességes naptár táblát összerakni pár évre előre magadnak"
Most ezen agyaltam, mik lehetnek a buktatók?
Amúgy mintha itt az emberke pont ilyesmivel foglalkozna, hogy mikor vannak szünnapok, stb., bár a cikk minőségét nem néztem, csak gyorsan beletekergettem kíváncsiságból.
Ilyesmikre egyébként vannak kész célszoftverek, nem? -
#1372
Sk8erPeter
nagyúr
fordfairlane
#1368
Sk8erPeter
nagyúr
válasz
fordfairlane
#1368
üzenetére
Bocs, hogy ezt mondom, de engem meg speciel sokkal jobban zavar az, hogy majd' minden webfejlesztős topicban előadod a Prohardver ügyvédjét, meg a "jaj nem is hiszem el, hogy mik mennek manapság, nem is fogom követni a topicot"-sirámot, mintha a kérdezők a segítségedre szorulnának, amikor valaki nem pont finomkodva tesz valami erősebb megjegyzést, és ezt kell elég sokszor olvasni tőled. Hidd el, a segítséged nélkül is általában meg tudják védeni magukat, nem kell mindig a haladó(bba)kkal összeveszni azon, hogy miért nem porcelánbabák módjára bánunk egymással. Az ilyeneken való hosszas OFF-olások legtöbbször rosszabbak, mint maguk a beszólások.
(Pedig egy haladónak ugyanannyi joga van - nem feltétlenül jogosan! - beszólni valakinek, aki esetleg nem nézett utána rendesen, vagy furát kérdezett; de igaz, neked is természetesen van jogod beszólni a beszólásért csak nem biztos, hogy előrevisz.) Ezt nem sértésként mondtam, ne is vedd kérlek annak! 
-
#1357
Sk8erPeter
nagyúr
martonx
#1352
Sk8erPeter
nagyúr
válasz
martonx
#1352
üzenetére
Speciel én abszolút passzív félként néha beleolvastam az eszmecserébe, igaz, már egy ideje elvesztettem a fonalat, de nem éreztem "vergődésnek", plusz sztem a topic elbírja a beszélgetésüket.
Meg mondjuk jóval érdekesebb problémát járnak körül, mint hogy hogyan kell MySQL-ben levágni egy szóközt a szó elejéről, meg hasonló, mostanában előforduló rendkívül érdekfeszítő kérdések... 
Üdítőbb ezeknél egy érdemi kérdésről témázás, igaz, Apollo17hu lényegében másnak oldja meg a munkáját tök ingyen, mindenesetre a kitartásáért jár neki a virtuális sör. 
-
#1324
Sk8erPeter
nagyúr
biker
#1322
Sk8erPeter
nagyúr
Ahogy előttem már martonx említette:
http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_ltrim
mysql> SELECT LTRIM(' barbar');
-> 'barbar' -
#1241
Sk8erPeter
nagyúr
spammer
#1240
Sk8erPeter
nagyúr
-
#1182
Sk8erPeter
nagyúr
futár
#1177
Sk8erPeter
nagyúr
http://stackoverflow.com/questions/4312710/client-does-not-support-authentication-protocol-requested-by-server
http://wordpress.org/support/topic/how-to-fix-client-does-not-support-authentication-protocol-requested-by-server
http://stackoverflow.com/questions/1575807/cannot-connect-to-mysql-4-1-using-old-authentication -
#1173
Sk8erPeter
nagyúr
futár
#1172
Sk8erPeter
nagyúr
Ja, értem, de akkor miért nem ezzel kezdted, hogy emiatt érdekel?
Úgy más a dolog, de eddig ott tartottunk, hogy elcsesződött a vinyód, és pont ugyanúgy szeretnéd működtetni a progit, ahogy előtte működött, a vinyó meghibásodása előtt, de klónozásra lehetőséged lenne, de mégsem akarod valami érthetetlen oknál fogva klónozni.
Mindenesetre továbbra is az a probléma, hogy SEMMILYEN információt nem osztottál meg a programodról azonkívül, hogy MySQL-adatbázisra épít. -
#1171
Sk8erPeter
nagyúr
futár
#1170
Sk8erPeter
nagyúr
Nem értem, miért fáj a legtisztább, legcélravezetőbb megoldás? Nem a korábbi rendszeredet akarod egy az egyben átvinni egy új HDD-re, hogy gond nélkül tovább tudd használni pont úgy, ahogy korábban is volt?
Amúgy semmit nem tudunk még mindig arról az ominózus programról, a korábbi jogosultsági beállításaidról, kábé csak azt tudjuk, hogy bad sectoros lett a vinyód, és MySQL-adatbázist használsz, és kész.
Nyilván nem futó rendszer alól kellene egyébként másolni, hanem mint elég hosszasan kifejtettem, valami Live Linuxról vagy az ajánlott Macriumról, mindenesetre valami live oprendszerről.
Bár sanszos, hogy nálad továbbra is elsősorban a jogosultsági dolgok nem stimmelnek, ezt kellene korrigálnod, de mivel úgy tűnik, nem vágod, korábban hogy működött, maradjunk továbbra is a rendszer klónozásánál. -
#1168
Sk8erPeter
nagyúr
futár
#1167
Sk8erPeter
nagyúr
Még mindig nem írtad le normálisan, hogy miket csináltál. Újraraktad a Windows-t egy másik vinyóra? Próbáltál klónozni, vagy simán másolni, vagy mi történt? Ha bad sectoros a vinyó, gondolom (remélem) nem azt használod épp. A MySQL-adatbázis FIZIKAI helyéhez pedig a programodnak nem kellene, hogy köze legyen, mert nem úgy működik, hogy megkeresi az adott könyvtár fizikai elérési útvonalát, hanem portokon, kommunikációs protokollon keresztül, stb. Szóval az adott júzernek valszeg nem adtál megfelelő jogosultságot. De simán klónozhattad is volna a teljes vinyót, és akkor nem lenne ilyen para most. De nem megoldhatatlan, csak akkor most szenvedned kell azzal, hogy megpróbáld a bad sectoros vinyón lévő dolgokat ugyanúgy beállítani az új rendszer esetén (attól függően, hogy csináltad végül).
-
#1166
Sk8erPeter
nagyúr
futár
#1158
Sk8erPeter
nagyúr
Igazából a kérdésedből nem tudtam kihámozni, hol van az adatbázissal kapcsolatos kérdés, mert ha jól értem, az elsődleges probléma a klónozás. Azt pedig így is-úgy is meg kell tenni. Erre Fire/SOUL/CD cikkét ajánlom, amiben mondjuk azt fejti ki, hogyan lehet SSD-re költöztetni a rendszeredet HDD-ről, de az ott szereplő, ingyenes Macrium Reflect nevű programot ilyen célra is fel tudod használni, a lényeg, hogy mindkét vinyó egyszerre csatlakoztatva legyen (a forrás és a cél), és a Macriumot pendrive-ról vagy CD-ről bootolós módban indítsd el, ne Windows alól. De egyébként ezt simán egy live Linux-szal is megteheted, pendrive-ra például ezzel a progival tudsz a lehető legegyszerűbben telepíteni egy Live Linuxot: UNetbootin. Itt egyszerűen kiválasztod az adott disztribúciót, kijelölöd, melyik pendrive-ra telepítse, rányomsz az OK-ra, vársz, míg kész van, és megvagy, újraindítod a gépet, és már bootolhatod is a pendrive-ra telepített Linuxot (például egy Parted Magic tökéletesen jó lesz neked). De a Fire által ajánlott Macriumot is rohadt egyszerű telepíteni, részletesen ki van fejtve, UltraISO kell hozzá majd. Használni sem bonyolult.
Szerk.: OFF-ba rakom, mert nagyon nem kapcsolódik a MySQL-hez.
-
#1123
Sk8erPeter
nagyúr
vakondka
#1122
-
#1119
Sk8erPeter
nagyúr
vakondka
#1118
Sk8erPeter
nagyúr
-
#1106
Sk8erPeter
nagyúr
lakisoft
#1105
Sk8erPeter
nagyúr
válasz
lakisoft
#1105
üzenetére
[link]
>
http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html
>
"As of MySQL 5.0.3, CREATE PROCEDURE and CREATE FUNCTION require the CREATE ROUTINE privilege. They might also require the SUPER privilege, depending on the DEFINER value, as described later in this section. If binary logging is enabled, CREATE FUNCTION might require the SUPER privilege, as described in Section 18.6, “Binary Logging of Stored Programs”." -
#1096
Sk8erPeter
nagyúr
Babetta-X
#1094
Sk8erPeter
nagyúr
válasz
Babetta-X
#1094
üzenetére
Hát ilyesmit nem nagyon szoktak engedni magasabbra állítani, lehet, hogy kuncsorogni kellene a szolgáltatónál.
Egy phpinfo()-t nézz meg, konkrétan pl. ezeket:
post_max_size
upload_max_filesizeAnnak viszont örülök, hogy sikerült a WP-s mutatvány.
A felülírós parára: exportálásnál meg lehet adni phpMyAdminban, hogy "Function to use when dumping data:" INSERT-UPDATE-REPLACE, ezek közül az utsó kettő közül valamelyik lenne jó, és akkor importálásnál elvileg az történne, amit szeretnél. Csak ahhoz ugye megint exportálni kellene, vagy pedig manuálisan beletenni a megfelelő sorokat, de az macera (bár attól függ, hány query-ről van szó).
-
#1089
Sk8erPeter
nagyúr
Babetta-X
#1088
Sk8erPeter
nagyúr
válasz
Babetta-X
#1088
üzenetére
"Igazándiból a wordpress cms van most fent, ennek bizonyos tábláit szeretném lementeni majd újratelepítés után visszahelyezni"
És akkor mi értelme van az újratelepítésnek, ha aztán ugyanazokat a táblákat fogod használni?
Sőt, ha ugyanazokat a táblákat használod ismét, akkor nem is lesz újratelepítve.
Nem költöztetni szeretnéd valahova máshova? Vagy mi a cél?Szerk.:
korábban írtak:
"A lényeg, hogy a wordpress CMS által feltett adatbázist kéne lementenem, mivel két rossz pluginnak hála összekeveredett és egyáltalán be sem jön az oldal, így webes felületről nem tudom adatbázis mentést készíteni."
Attól nem fog megoldódni ez a gond, hogy ugyanazt az adatbázist visszarakod... Azzal meg végképp nem, ha a korábbi pluginokat letörlöd, és mégis a korábbi adatbázist használod.
Ezt azért gondold át még egyszer, mielőtt tönkrevágod az oldaladat, inkább a plugin hibáját kéne javítani.
A Drupalnál úgy van egyébként, hogy ha modulban el is van cseszve valami, a hibanaplót elvileg eléred attól még. WordPress-nél nem éred el?Vagy csak az a cél, hogy localhostra lementsd, aztán ott próbáld meg debuggolni a hibát?
-
#1087
Sk8erPeter
nagyúr
Babetta-X
#1085
Sk8erPeter
nagyúr
válasz
Babetta-X
#1085
üzenetére
Ahogy írták, telepíts valamelyik alkönyvtárba egy phpMyAdmint, de van lightweightebb is, amit itt már ajánlottak, és nagyon gyors (próbáltam):
http://www.dbninja.com/?page=download
Mondjuk többet tud a phpMyAdmin, de ennek a konfigolása szinte nem tart semeddig, a phpMyAdminnál azért be kell állítani jópár dolgot. -
#1084
Sk8erPeter
nagyúr
PazsitZ
#1082
Sk8erPeter
nagyúr
válasz
PazsitZ
#1082
üzenetére
Kettőnk közül most nem én tekintettem magam "az igazság bajnokának", nem igazán hajlottál rá, hogy elfogadj a véleményemből bármit is.
Persze nem is kell.
Itt pedig GUI-n megoldható dolgokról volt szó, nem másról, ezt a témát próbáltam kivesézni.
Na, de örülök, hogy Te is megmondtad a magadét. Szóval igazából szerintem elég jól átrágtuk a témát, nem érdemes tovább ragozni. -
#1057
Sk8erPeter
nagyúr
PazsitZ
#1056
Sk8erPeter
nagyúr
válasz
PazsitZ
#1056
üzenetére
Tényleg kezd kissé fárasztó lenni.
Nem "pörgök" rajta, írták itt, hogy próbáljam mega progit, megpróbáltam: [link]; később még egyszer előkaptam (igen, 1 hónap múlva! De ettől még nem pörgök azóta ezen a témán, hagyjuk már
), amikor valamire szükségem volt, ismét írtam visszajelzést, mit hiányolok belőle: [link]kedves reakcióid:
[link]
[link]
[link]
Áá, nincs ám benned egy csöpp szarkazmus és cinizmus sem az igényeimmel szemben...Visszajeleztem valamire, amiről véleménycsere volt. Ha nem finomkodtam, ez nem azt jelenti, hogy neked kötelességed hősködve kiállni a program mellett, szándékos negatív hozzáállás nélkül is lehet vitázni valamiről, ha nem értesz egyet, és akkor valószínűleg meg is találjuk a közös nevezőt, és tudunk érdemben is előnyökről-hátrányokról dumálni, nincs is abban semmi rossz.
"Gizdulni" nagyjából annyit tesz, hogy vagánykodni, nagyzolni.
Sztem maradjunk annyiban, hogy nem kell a másikkal köcsögösködni attól még, hogy az illető a negatív tulajdonságait is bemutatja egy programnak, és ezért összességében kevéskének tartja.
Peace! -
#1054
Sk8erPeter
nagyúr
PazsitZ
#1052
Sk8erPeter
nagyúr
válasz
PazsitZ
#1052
üzenetére
Nekem egyáltalán nem baj, hogy számodra nem lenne hasznos, amit én szeretnék használni, ne értsd félre szándékosan.
De Te se próbáld beállítani hülyeségnek azt, ami meg számomra elvárás/igény, és van olyan open source, ingyenes program, ami ezt biztosítja. Nem mondom egyáltalán, hogy a phpMyAdmin az teljesen jó, mert azon is bőven van mit csiszolni, és nem vagyok oda érte, de biztosít egy csomó olyan lehetőséget, amit sajna még nem találtam meg ingyenes asztali kliensekben MySQL-hez, és itt a topicban többen is a MySQL Workbench-et hozták ki győztesnek a phpMyAdmin kontra MySQL Workbench párbajban, én pedig konkrétan erre a témára fókuszáltam - nem pedig arra, hogy neked vagy nekem mi az egyéni preferenciám. Próbáltam kiemelni, hogy jelenlegi állapotában miért tud kevesebbet szerintem sok szempontból a MySQL Workbench. Sajnos ezt sikerült elterelned olyan irányba, hogy szerinted amit én szeretnék, az kvázi pitiáner hülyeség, és emiatt ne erőltessem már, hogy kevesebbet tud a MySQL Workbench. Mást tud a kettő, de olyan dolgokban kevesebbet tud utóbbi, ami nálam pl. gyakran felmerülő igény (pl. tömörített dumpból importálni pár klikkre). -
#1049
Sk8erPeter
nagyúr
Soak
#1048
Sk8erPeter
nagyúr
Az előbb már írtam: nagyvállalati környezetben, bizonyos adatok kinyerése érdekében, naplózáshoz és egyéb célokhoz is. Ha nem hiszed, megadom az elérhetőségeit egyik haveromnak, ha szeretnél vele erről diskurálni, hogy egy németországi rohadt nagy cégnél miért művelnek ilyen elmebeteg dolgokat. Először én is le voltam hidalva a számokon, amikről mesélt. De félreértés ne essék, NEM MySQL-ben dolgoznak.
-
#1047
Sk8erPeter
nagyúr
PazsitZ
#1038
Sk8erPeter
nagyúr
válasz
PazsitZ
#1038
üzenetére
Jaj ne már... magadat sem veheted komolyan. Gizdulásnak is gyenge volt ez a gunzipes példád. Könyörgöm, tényleg ily' nehéz megértened, hogy itt GUI-n keresztüli adatbázis-manipulálásról volt szó, anélkül, hogy hozzányúlnál egyáltalán a konzolhoz/terminálhoz?
Minek kötöd az ebet a karóhoz?
Ilyen alapon a júzerek létrehozására, privilégiumainak módosítására is írhatnék akár egy konzolos kis progit C-ben, vagy sima batch-programot, biztos rendkívül izgi lenne, meg feltalálhatnám a spanyolviaszt. Körbeírjam még párféleképpen, hogy mi itt az alapvető probléma?"Egyébként szerintem meg nem."
Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz? -
#1046
Sk8erPeter
nagyúr
martonx
#1045
-
#1037
Sk8erPeter
nagyúr
PazsitZ
#1036
Sk8erPeter
nagyúr
válasz
PazsitZ
#1036
üzenetére
Valóban, nem hülyeségnek tartottad, rosszul emlékeztem, de ezt írtad:
"Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez."
Azért akkora gond, mert ha én tömörített formában exportálom az eredeti szerverről a dumpot, akkor szeretném azt egyből importálni. Nem tudom, mit nem lehet ezen belátni.A kitömörített változat esélyes, hogy működik, majd kipróbálom. De már megint olyan dolog, amivel nekem kell tökölni, ahelyett, hogy a program elintézné ezt helyettem. Szerintem ez alapvető elvárás, és annyira nem nagy dolog, ha a phpMyAdmin is képes rá.
"A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul..."
Ja igen, erre írtad, hogy ez szerinted f@szság. Hát nem az, és például kapcsolatok gyors létrehozására a phpMyAdminban is van lehetőség grafikus felületen keresztül is.
Mondjuk erre már korábban is reagáltam, hogy kár, hogy nem tudsz olyan esetet elképzelni, ahol a grafikus query-összeállító igen hasznos tud lenni. Nyilván nagyvállalati környezetben (nem magamról beszélek), egy 200 táblás query-összekapcsolást is bepötyögnek, igaz? Szerintem ott is tök jókat "eljátszanak" grafikus alapú adatbázis-kezelőkkel... -
#1035
Sk8erPeter
nagyúr
PazsitZ
#1029
Sk8erPeter
nagyúr
válasz
PazsitZ
#1029
üzenetére
Ó, tényleg, akkor a júzerek kezelésével kapcsolatban én voltam a figyelmetlen, sorry (ahogy ígértem, leírtam
), legalább ez megoldott kérdés, mégsem olyan "ostoba szar" a progi. 
(Csak a kedvedért használtam ismét ezt a kifejezést. ![;]](//cdn.rios.hu/dl/s/v1.gif)
Mivel úgy csináltál, mintha a korábban belinkelt hozzászólásaimban ne soroltam volna el azokat a dolgokat, amik viszont tetszenek a MySQL Workbench-ben, pedig de.) A gyökereknek szóló lmgtfy-s linkedet pedig külön köszönöm, eddig fogalmam sem volt, hogy kell ilyesmit a Gúúgölben keresni. A tömörített, gzippelt SQL-dumpokat viszont továbbra sem lehet importálni, most próbáltam, itt, mielőtt ismét küldenél egy lmgty-s linket:
Eredménye:
Pedig ez manapság elég alapvető elvárás, és ez megint csak olyan, amit a phpMyAdmin vicces, hogy tud, ez pedig nem.
Ja, várj, szerinted ez is nyilvánvalóan egy hatalmas baromság, ahogy korábban kifejtetted, hát ki a büdös franc akarna manapság nagyobb adatbázist tömörítve letölteni az eredeti szerverről, és átvinni egy másikra, miért is ne tartaná a terpeszkedő eredeti .sql-formában, hát ki az a hülye, aki ilyesmit manapság csinál, nyilván ez is csak egy játékszer, az ilyenek azzal játsszanak inkább, ami velük egyidős. Ha így látod, hát nagyon rosszul látod. -
#1028
Sk8erPeter
nagyúr
PazsitZ
#1026
Sk8erPeter
nagyúr
válasz
PazsitZ
#1026
üzenetére
Köszönöm a tanácsot, nem is használom.
Ami miatt most előkaptam, hogy hirtelen kíváncsi voltam valamire, és ha már telepítve van, megnéztem, van-e benne ilyen lehetőség, mert jobb' szeretnék faszányos asztali klienst használni, mint a böngészőben használható phpMyAdmint.
Egyébként a programra ajánlottam alternatívát is, ami szerintem tényleg fasza, nem csak a levegőbe hőbörögtem, a dbForge Studio for MySQL-t, csak azzal az a gáz, hogy fizetős."A múltkor konkrétan pl. azért volt rossz, mert te 1-2 funkciót nem találtál meg benne elsőre."
Ilyen mikor volt?
Szerintem erre gondolsz: [link]. Megmutatod nekem, hogy hol írtad le ezekre a megoldást, hogy hol találhatók meg a felületen? Segítek: sehol. Ha megírod, hogy ezek hol találhatók meg, és kiderül, hogy csak az én figyelmemet kerülték el, akkor azt mondom, sorry, én voltam a figyelmetlen, addig viszont ezek továbbra is nyitott kérdések, tények. Szóval? -
#1024
Sk8erPeter
nagyúr
whYz
#1023
Sk8erPeter
nagyúr
Igazából amiket írtál, csak kódformába kellett önteni (a zárójeleket az átláthatóság kedvéért pakoltam bele pluszban):
SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE
(
`date_start` <= $currtime
AND
`date_end` >= $currtime
)
AND (
( gametypeid=1 AND packetid=1 ) OR
( gametypeid=2 AND packetid=3 )
)
ORDER BY `id` DESC LIMIT 4Szerk.:
persze itt a gametypeid és a packetid "be van drótozva", ha a hozzá tartozó "legkisebb packetid-jut" szeretnéd automatikusan kideríteni, akkor ahhoz egy bonyolultabb alselectre lenne még szükség. -
#1022
Sk8erPeter
nagyúr
PazsitZ
#1021
Sk8erPeter
nagyúr
válasz
PazsitZ
#1021
üzenetére
Csak úgy sugárzik belőled a jóindulat, úgy általában, mindig megjelensz, ha valakit lehet cseszegetni.
De mondjuk engem speciel ez nem visel meg különösebben, szívesen reagálok a szándékosan rosszindulatú hozzászólásodra.
Biztos te is művelsz olyan dolgokat, amik meg nekem lennének furcsák.
Hogyhogy miért próbálom használni? Elég hülye kérdés, de válaszolok rá: egyrészt azért, mert ingyenes termék attól a cégtől, aki fejleszti a MySQL-t (komolyan magyarázzam tovább? jó, a kedvedért), és kíváncsi vagyok rá, másrészt azért, mert itt a topicban ketten javasolták, hogy adjak neki még egy esélyt, mert rendkívül fejlett, nagytudású, sokat fejlesztettek rajta az elmúlt időkben, blabla. Ezekre reagáltam, vissza is kérdeztem, hogy konkrétan milyen fejlesztésekre gondoltak, mert én nem vettem észre azt az óriási fejlődést rajta. De te sem mondtál egy nyomorult szempontot sem, csak azért jöttél ide, hogy trollkodj egyet, jó szórakozást kívánok hozzá. Az "ostoba szar" megfogalmazás meg szándékosan volt eltúlozva, örülök, hogy belőled legalább sikerült kiváltanom azt az érzést, hogy nem direkt szarkasztikusnak és cinikusnak veszed, hanem még személyes sértésnek is veszed szinte, és véresen komolyan kezeled az ügyet, kapsz tapsikolós smiley-t is cserébe:
"Sőt, miért nem írsz jobbat?"
Azért nem vártam, hogy ilyen reakciót pont tőled fogok olvasni, ennél egy csöppet intelligensebbeket szoktál írni. Bocs, ha többet feltételezek, mint kéne. (Na, nehogy ezen is megsértődj. ) -
#1020
Sk8erPeter
nagyúr
martonx
#1019
Sk8erPeter
nagyúr
válasz
martonx
#1019
üzenetére
- nyilván nagyon nagy méretű, komoly, sok-sokmillió rekordot tartalmazó adatbázisnál nem kezdenék el keresgélni egy stringet; az már vélhetően egy bejáratott, működő rendszer.
- ilyesmit nem illik művelni éles szerveren amúgy sem.
- szvsz nem biztos, hogy meg kell, hogy ölje az egész SQL-szervert a keresés, ha az ehhez tartozó alkalmazás normálisan van megírva: nem kell az összes adattáblát lockolnia addig, amíg végez. Elvileg egyetlen adatbázisban keresek, és a táblákon ciklikusan végig lehet menni, tehát egy lépésben csak egyetlen táblában keresek, string alapon, végignézve az összes szóba jöhető mezőt, kivéve ebből azokat, amiknek köze nincs a string típusú mezőkhöz (tehát elő sem fordulhat például az INT, DATETIME, stb. típusúak közt) - persze abban teljesen igazad van, hogy a string alapú keresés jó qrva lassú, és akkor is végig kell nézni a táblákat, és erőforrás-igényes az egész. Mégis meglepően gyorsan szokott végezni ezzel a phpMyAdmin, még amikor HDD-n volt az adatbázisszerverem, akkor is mindig meglepett, hogy akár 6500 találat esetén (amelyek több táblában voltak szétszórva) is nagyon gyorsan kész volt (de tény, nem tartok nagyon sokmillió rekordot tartalmazó adatbázisokat a gépemen!). Fogalmam sincs, hogyan van mindez megírva phpMyAdminban, de úgy tűnik, egész értelmesen; majd ha egyszer alkalmad nyílik rá, próbáld ki, csak úgy tesztelés gyanánt.
- hogy miért is lehet szükség minderre. Előfordul, hogy egy alkalmazást nem ismerek még teljesen, és ez felgyorsítja a megismerést. Például amikor egy CMS-ben felviszek néhány adatot sok-sok mezővel, kíváncsi vagyok, konkrétan milyen táblá(k)ba szórja szét azokat (pl. string jellegűeket), így meg rohadt gyorsan megtalálom, és mivel ezután tudom, melyik táblába, melyik mezőbe megy a cuccos, így magában a kódban is gyorsan rá tudok keresgélni, és el tudom kezdeni vizsgálgatni, mi is történik benne; kevesebb agyalás, hogy hol is logikus az egész dolog, kevesebb guglizás. Vagy mittudomén, költöztetted a webalkalmazásodat más domainre, alkönyvtárba, és kíváncsi vagy, vajon vannak-e még hivatkozások a korábbi elérési útra valamelyik tartalomban (például egy WYSIWYG-szerkesztőben a képet bepakoló plugin fosul volt beállítva, és teljes hivatkozásokat tákolt bele a tartalomba). De tudok még nyakatekertebb példákat is. Mindenesetre nem egy hülyeség, hogy ilyesmit lehet egy GUI-n keresztül (ahogy lehet a phpMyAdminban), ahelyett, hogy kézzel kéne összeszenvedni a teljes kódot, mondjuk egy tárolt eljárással, ami tényleg megölheti az SQL-szervert, mert épp készülsz feltalálni a spanyolviaszt. -
#1018
Sk8erPeter
nagyúr
martonx
#1017
Sk8erPeter
nagyúr
válasz
martonx
#1017
üzenetére
Ezt most nem egészen értettem. Ki kíváncsi itt a DB szerkezetére?
Konkretizálva például arra vagyok kíváncsi, hogy adott adatbázison belül mely adattáblák mely mezői tartalmazzák azt a stringet, hogy "árvíztűrő tükörfúrógép" (csak hogy egy elvetemült példát mondjak). Hogy nyered ki ezt az information_schema-ból?
De ha meg is tudod ezt tenni, itt arról volt szó, hogy GUI-n keresztül (!!) hogyan lehet kényelmesen kezelni az adattábláidat, anélkül, hogy egyetlen sort le kéne írnod SQL-ben. -
#1016
Sk8erPeter
nagyúr
Sk8erPeter
#975
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#975
üzenetére
Na, még egy dolog tűnt fel, ami hiányzik a MySQL Workbench-ből (nagyon), a phpMyAdminban viszont ötezer éve megvan: az összes vagy megadott nevű adattáblákban való keresgélés egy adatbázison belül.
phpMyAdminban ezek a kategóriák vannak:
- at least one of the words
- all words
- the exact phrase
- as regular expression
aztán meg lehet adni Ctrl-os kijelöléssel, hogy konkrétan melyik táblákban keressen, vagy ki lehet jelölni az összeset, meg lehet jelölni, melyik nevű mezőben keressen, lehet wildcarddal keresni.
Szóval egyértelmű, hogy a MySQL Workbench egy ostoba szar a phpMyAdminhoz képest.
-
#1008
Sk8erPeter
nagyúr
Lacces
#1007
Sk8erPeter
nagyúr
Jó kulcsszavakat beírva elég gyorsan lehet találni válaszokat, például:
Nem tudom, milyen, nem próbáltam még.
A másikra majd a többiek.
-
#1000
Sk8erPeter
nagyúr
laracroft
#998
Sk8erPeter
nagyúr
válasz
laracroft
#998
üzenetére
Szerintem ezzel van a para:
....
(select ......, LEIRAS
from NAPLO
where a.LEIRAS like '%Helyszínen%') as a
union
(select ...., LEIRAS
from NAPLO
where b.LEIRAS like '%Leellenõrizve%') as b
....az a.LEIRAS és b.LEIRAS mezőkre gondolok, így nem hivatkozhatsz rájuk, mert az alquery-ben nem ismeri a MySQL, hogy mi az az "a" meg mi az a "b".
Az alquery-n, a zárójeles részben belül szerintem nem is kell az alias, vagy ha mégis, akkor jó helyre írd az aliast, például:(select ......, LEIRAS
from NAPLO n1
where n1.LEIRAS like '%Helyszínen%') as aRemélem nagyjából érthető, mire gondolok.
Ja, bocs, most néztem tovább, tényleg, tuti, hogy az IF is szar.
De mondjuk sokat segített volna, ha bemásolod a konkrét hibaüzenetet, hogy mire hivatkozik.
Szerintem CASE-t kéne használnod:
http://dev.mysql.com/doc/refman/5.0/en/case.htmlNa, ha nem sikerül, megnézem normálisabban is, most ennyire tellett.
-
#996
Sk8erPeter
nagyúr
Apollo17hu
#995
Sk8erPeter
nagyúr
válasz
Apollo17hu
#995
üzenetére
"aposztróf kell, nem?"
Alapértelmezésben tök mindegy, ez MySQL.
http://dev.mysql.com/doc/refman/5.0/en/string-literals.html(#992) laracroft :
"egyenlőre" ----> "egyelőre" -
#991
Sk8erPeter
nagyúr
MadarasTESCO
#990
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#990
üzenetére
És milyen megoldást választottatok?
Amúgy üzenem a tanárnak, hogy elég rosszak a pedagógiai módszerei. Szerintem ez rohadtul nem kezdőknek való feladat, és messze áll attól, ami a gyakori adatbázis-kezeléshez kell. Ezerszer értelmesebb lenne táblák megtervezésével, összekapcsolásával kapcsolatos feladatot adni...
Nagyon tud irritálni, amikor egy tanár a diákok kedvét még idejekorán elveszi az informatikától. -
#989
Sk8erPeter
nagyúr
MadarasTESCO
#985
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#985
üzenetére
A legprimitívebb, legegyszerűbb megoldás talán ez lehet egy random rendszám kidobálására:
SELECT CONCAT(
CHAR(65+MOD(ROUND(RAND()*100),26)),
CHAR(65+MOD(ROUND(RAND()*100),26)),
CHAR(65+MOD(ROUND(RAND()*100),26)),
'-',
FLOOR(100 + RAND() * (900))
) AS 'rendszam' -
#987
Sk8erPeter
nagyúr
MadarasTESCO
#985
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#985
üzenetére
Most csak rohanva írok, úgyhogy csak részsegítség, de a háromjegyű szám generálása (a magyar rendszám második feléhez) elég egyszerű, lásd [link]:
"To obtain a random integer R in the range i <= R < j, use the expression FLOOR(i + RAND() * (j – i)). For example, to obtain a random integer in the range the range 7 <= R < 12, you could use the following statement:
SELECT FLOOR(7 + (RAND() * 5));
"Szóval például:
SELECT FLOOR(100 + RAND() * (900)) AS szamok
Ezt persze még konkatenálni kéne a háromjegyű, angol ábécéből generált random stringgel, meg a kötőjellel (mármint ezek a szám elé mennek), meg 15 ezer db-ot mindebből ledarálni. Biztos a tanár meg akarta oldani, de nem sikerült neki, ezért rátok bízza a piszkos munkát. -
#978
Sk8erPeter
nagyúr
PazsitZ
#976
Sk8erPeter
nagyúr
"user letrehozas, komplett elore konfiguralt jogosultsag szintekkel van. "
Hol?
Csak gyorsan végigkattintgattam, simán lehet, hogy elkerülte a figyelmemet, de én nem találtam."Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez."
Nem értem a kérdést. Hogyhogy miért gond? Ha egy tömörített dumpot akarok importálni, akkor már hogyne lenne gond? Ha phpMyAdminban meg tudták oldani, nem igazán értem, itt miért nem. De már a felvetésedet sem igazán látom be, hogy miért ne lenne gond."A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul..."
Azontúl is nagyon hasznos, sokszor jóval gyorsabb, mint kézzel megírni egy rohadt komplex query-t. A gyakorlatban is vettem már hasznát pl. dbForge-nál, amikor tényleg nagyon sok táblát kellett összekapcsolni egy számtalan paramétert, beállítást összekapcsoló query-hez.
Gondolom azért mondod, hogy csak játékra jó, mert nem volt még olyan igény, amire hasznát vehetted volna. Ettől még nem kell ilyen szélsőséges kijelentést tenni, mert számolhatnál azzal is, hogy nincs igazad. Még mindig jobb egy elég jól összepakolt, rohadt nagy query-t átírni pár helyen, mint kézzel, hibákkal lepötyögni a teljeset mindenféle segítség nélkül.
Talán ha kipróbálnád egyszer...(#977) lakisoft : OK.
-
#975
Sk8erPeter
nagyúr
lakisoft
#974
Sk8erPeter
nagyúr
válasz
lakisoft
#974
üzenetére
Na, megnéztem.
Nagyon kíváncsi lennék: szerinted konkrétan miben fejlődött "nagyon sokat"?
Nagyjából semmi különbséget nem láttam ahhoz képest, mint amikor legutóbb próbáltam.
Még új júzert sem lehet hozzáadni, jogait menedzselni, pedig azt még a korábban mutatott, böngészőben kezelhető DBNinjával is lehet, persze nem is beszélve a phpMyAdminról, ahol elég normálisan van ez is megoldva.
Mondjuk az tetszik, hogy ott van a táblákra jobb klikkelve a "Select Rows - Limit 1000", tehát hogy nem kell külön rányomni a query futtatására, mint a DBNinjában, de asszem ez elég alapvető elvárás. Meg a phpMyAdminban azt is be lehet állítani, hogy egy átlagos selectnél defaultból hány rekordot kérdezzen le (tök hülye számokat is be lehet állítani, pl. 37).
A rekordok szerkesztése viszont tényleg kényelmes.
Az is tetszik, ahogy pl. egy UPDATE vagy INSERT query összeállításában segít, hogy mutatja a default értékeket is: http://i.imgur.com/32k8O.png.
De mondjuk elvileg még ez is alapvető elvárás lehet egy ilyen proginál (még ha ingyenes is).
Az is jó, hogy a szintaktikai hibákat egyből jelzi az editorban - ez sem egy hű de nagy valami.
DE ami kifejezetten hiányzik, hogy én nem találtam grafikus alapú query-összeállítót, ami van a dbForge Studio for MySQL-ben - persze utóbbi nyilván többek közt ezért sem ingyenes. Habár most ugrik be, az Microsoft SQL Server 2012 Express-ben található SQL Management Studio is tök ingyenes, mégis tudja ezt... (lehet, hogy most jön a hivatkozási alap, hogy a Microsoftnak több a tőkéje)Ami viszont szerintem alapvető elvárás, az a korábban említett user-létrehozás, meg az, hogy importálni lehessen normálisan a MySQL dumpokat, a tömörített változatokat is (.gz), mint ahogy phpMyAdminban tök egyszerűen lehet is, kb. három klikk. De itt csak olyat találtam, hogy meg lehet nyitni egy .sql-fájlt, és azt le is lehet futtatni (OK, végül is így importálhatom a rekordokat), DE a tömörített állományokat (.gz) már el sem fogadja. Hát ez mi?
Szóval én ezek miatt nem vagyok túlságosan elragadtatva a MySQL Workbench-től, mert a böngészőalapú phpMyAdmin az alapvető, elvárható funkciókból (lásd utóbbi kettő) még mindig többet tud, még ha lassabb is.
-
#973
Sk8erPeter
nagyúr
Sk8erPeter
#972
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#972
üzenetére
Most látom, itt az 1-es pontban lévőt félreérthetően írtam, az SQL Management Studio-ban azért annyiból is sokkal jobb a dolog, hogy van lehetőség mondjuk az első 1000 sor listázására, nem kell külön rámenni, hogy na akkor ezt a query-t futtasd. Itt meg úgy működik, hogy ráklattyolsz a Use in Query > Selectre, aztán van egy külön gomb a query futtatására. Idegesítő ez a szükséges plusz felesleges kör.
-
#972
Sk8erPeter
nagyúr
Peter Kiss
#968
Sk8erPeter
nagyúr
válasz
Peter Kiss
#968
üzenetére
Köszi az ajánlást, ezt kipróbáltam, és tényleg meglepően gyors! Ráadásul elég modern a felülete (ahogy a cikkben is kiemelik), egész kényelmes és intuitív a kezelése.
Ami engem zavar, és elég gyorsan feltűnt, az első pár perc tesztelgetés után:
1.) táblákra kétszer rákattintva először a struktúráját mutatja, ami még önmagában nem lenne gáz, de magához a tartalmához viszont kénytelen vagyok az SQL Management Studio-hoz hasonlóan rákattintani jobb gombbal, majd Use in Query menüben kiválasztani a Selectet. Pedig tesztelésnél van, hogy inkább azt szeretném megnézni, hogy mi a táblák tartalma, a struktúráját meg alapvetően elég kevésszer módosítom.
2.) amikor az előbb említett Use in Query > Select menüpontot kiválasztom, akkor a hosszú, legörgetett táblalistában felugrik magának az adatbázisnak a nevére, igazából itt a bal oldali hasáb görgetési állapota nem tudom, miért nem tud független lenni a jobb oldalitól, miközben úgyis AJAX-szal töltődik be a tartalom, miért kell, hogy felugorjon a fókusz az adatbázis nevére. Ez nagyon zavaró tud lenni, ha ismét ugyanazon a táblán akarsz valami műveletet végezni, és már megint scrollozhatsz le a listában.
3.) a query-k összepakolásánál hiányolom azt, ami megvan phpMyAdminban: a query összeállításánál felkínált lista a mezők nevével, amire elég csak rákattintani, és bedobja a textarea-ba.Ettől függetlenül elég ígéretes, és tényleg nagyon gyors. De azért sztem a fentiekben még fejlődnie kell, mert elég alapvető igények (nem?).
Egyébként hol tárolja az elmentett dolgait? Nem kér külön adatbázist, táblák beállítását, mint mondjuk a phpMyAdmin. localStorage-ban vagy ilyesmi?============
(#969) lakisoft :
Már elég rég használtam, de a MySQL Wordbench a dbForge Studio for MySQL-hez képest elég sok mindenben elmaradt, sok mindent hiányoltam belőle. Most nincs előttem, nem ugrik be hirtelen, mik voltak ezek, de a query-k összepakolása a dbForge-ban iszonyat kényelmes, míg a MySQL Workbench-ben nem nagy szám, nem lehet olyan szépen összerakni komplexebbeket.
Az is hozzátartozik viszont, hogy a dbForge nem ingyenes. -
#967
Sk8erPeter
nagyúr
martonx
#966
Sk8erPeter
nagyúr
Hát nem tudom. Sajnos az általad ajánlott Toad for MySQL sem jobb az én tapasztalataim alapján.
Nem biztos, hogy a phpMyAdmin okolható az általa tapasztalt probléma miatt (pl. arról nem esett egy szó sem, hogy kipróbálta-e simán, konzolról). -
#957
Sk8erPeter
nagyúr
Speeedfire
#955
Sk8erPeter
nagyúr
válasz
Speeedfire
#955
üzenetére
-
#949
Sk8erPeter
nagyúr
Lacces
#943
Sk8erPeter
nagyúr
"2. Úgy vettem észre webes gyakorlatban, hogy a JOIN-lást nem nagyon szeretik. Számomra egyetem után meglepő volt, hogy inkább használjunk 3 SELECT-et, amit a szerver oldalon úgy mond összeállítunk és kérdezgetünk le WHERE ID = .... konstrukcióval, ez jobbnak tűnik, mint ha 3 táblát össze JOIN-olnék."
Ki mondta ezt a baromságot? Egyébként nyilván esetfüggő, milyen query-t érdemes használni, nincs erre általános recept.
De az egyszerűen hatalmas hülyeség ebben a formában, hogy jobb 3 különböző select, mint mondjuk egy értelmesen összerakott join.(#947):
"Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt."
Most mindenféle bántás nélkül, a hozzászólásaidból, kérdéseidből az derül ki, hogy nem igazán vagy még kellően tájékozott ahhoz, hogy cikket írj a témáról, hogy átfogó összehasonlítást tudj ezekről írni. Ehhez komoly háttértudás, tapasztalat kell, és kellő magabiztosság, különben nagyon nagy eséllyel csak téves vagy ingatag információkat fogsz megosztani a publikummal, vagy az állításaid nagy része pusztán spekuláció, saját vélemények, érzésekre hagyatkozás megfogalmazása lenne, aminek meg nem túl sok értelme van szakmailag.
Én személy szerint nem venném a bátorságot ilyen összehasonlító cikk megírására (mostani tudásom egyszerűen nem elég hozzá), főleg, ha olykor láthatóan alapfogalmakkal nem lennék tisztában. -
#937
Sk8erPeter
nagyúr
Speeedfire
#936
Sk8erPeter
nagyúr
válasz
Speeedfire
#936
üzenetére
Érdekes módon használat közben tényleg gyorsabbnak tűnik, viszont az indulási ideje valamiért iszonyat lassú, nem vágom az okát.
Egyébként a Te géped referenciának számít? -
#935
Sk8erPeter
nagyúr
Sk8erPeter
#933
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#933
üzenetére
Meglepődve tapasztaltam localhostos tesztelés után, hogy a phpMyAdmin jóval gyorsabban töltődött be az SQL Buddy-nál is, amit pedig elvileg alternatívaként szoktak ajánlani, mondván, hogy gyorsabb, mint a phpMyAdmin.
Most már tényleg kicsit átértékeltem a phpMyAdminnal szemben érzett erős fenntartásaimat.
Épp úgy általában is elég lassan töltődik be nálam a MySQL, de az SQL Buddy-t előbb is indítottam el, de még mindig nem töltött be, a phpMyAdminnal meg már egy query-t is lefuttattam. Elég furcsa, hogy ennyit szarakodik az SQL Buddy. -
#933
Sk8erPeter
nagyúr
martonx
#932
Sk8erPeter
nagyúr
"Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges)."
He? Nem értem a gondolatmenetet.
Ha Linuxban konzolon rámész, hogy mondjuk telepíteni akarod a phpmyadmint, akkor az összes függőséget is behúzza.
Windows-on meg végül is a külön telepítős macerát oldja meg az egyben telepítős módszer, ahogy a XAMPP is.
A WAMPP mozaikszóban az első pedig a Windows-t jelenti, de gondolom ezt nem kell külön mondanom. Akkor hogy érted, hogy Windows-ra ez felesleges?
Mondjuk Windows-on én még mindig IIS+Web Platform Installer-párti vagyok, ott is behúzza a függőségeket, és számomra tisztább megoldás. Meg értem én, hogy live serverhez hasonló környezetet akar valaki felrakni, ami esetek többségében Apache-on lesz, ez elfogadható érv, de én sokszor inkább a tájékozatlanságnak tudom be, hogy nem használnak az emberek PHP-zésre IIS-t Windows-on.Most kipróbáltam az általad javasolt Toad for MySQL-t, mert eddig nem tettem, de én sok alapvető dolgot nem találtam meg így elsőre, vagy csak nem kézenfekvő helyen van.
Ilyenek, mint az adatbázis egyszerű átnevezése, adatbázis tartalmának egy klikkre történő átmásolása vagy éppen mozgatása másik adatbázisba. Lehet, hogy ezt exportálni kell először egy scriptbe, és aztán behúzni, de nehogy már... ez phpMyAdminban egyből ott van az arcodba tolva, beírod az új db nevét, és megcsinálja, no para. Be lehet állítani, hogy egyből át is váltson arra az adatbázisra. Aztán továbbmenve importálási lehetőség. Ez miért nincs egyből jól látható helyen? Egyáltalán hol van? Biztos csak türelmetlenül futottam át rajta, de ez azért eleve nem tetszik, hogy nincs ott, egyértelmű helyen. Aztán diagramok létrehozásánál pattog, hogy túl sok a tábla, egy beállítás korlátozza. Miért nem kérdezi meg egyből, mennyi táblára akarom korlátozni épp a megjelenítést? A sokat szidott phpMyAdmin "Diagram" opciójára kattintva egyből kirajzolja az összes táblát, még ha rengeteg is van, aztán ezeket ki lehet szedni, és utólag korlátozni, melyek jelenjenek meg, így gyorsan lehet relationt létrehozni táblák közt.Kezdem átértékelni, hogy mégsem akkora fos ez a phpMyAdmin.
Amúgy nekem a dbForge Studio for MySQL jött be, de arra meg ugye korlátos az ingyen liszensz.
-
#931
Sk8erPeter
nagyúr
martonx
#929
Sk8erPeter
nagyúr
Azért nem egészen olyan ez a helyzet, mint a hasonlatod.
Ha a WAMPP-ot telepíti, akkor abból sejthető, hogy elkezdte érdekelni a webfejlesztés, és most szétnézelődik, elkezd PHP-zni, nézegeti a MySQL-t, próbálgatja az Apache-ot, stb. Én is így kezdtem, csak én eleinte még szopattam magam azzal, hogy egyenként telepítettem őket, és próbáltam rájönni, hogyan kell őket konfigurálni, összehozni, miközben még lószart sem értettem az egészből. Egy csomó időt megspóroltam volna, ha egyszerűen telepítek egy WAMPP-ot, csak akkor még úgy voltam vele, hogy megpróbálom ezeket megismerni. Így utólag úgy gondolom, tök hülyeség ilyennel kezdeni, csak a tököd tele lesz vele már az elején. Miért ne lenne jó telepíteni egy WAMPP-ot? Egyáltalán nem értelek.
Főleg a gonoszkodó stílusodat vele szemben. Kezdő, Te is voltál az.
Egyébként mi van akkor, ha telepíti a WAMPP-ot, talán megeszi a gépét? Értem én, hogy sok felesleges dolog is felmehet vele, de majd ha akarja, kiszedi utólag, és kész. Úgyis ki akarja majd próbálni élete első PHP-scriptjét, tehát kelleni fog az Apache és a PHP is. Mondjuk Windows-on én még mindig IIS-párti vagyok, de ez már másik kérdés.
Ettől még a kezdőnek ne vegyük el a kedvét, inkább segítsünk neki, nem kérdezett olyan vad dolgokat, nem az volt a kérdése, hogy "nem működik, mit tegyek?", hanem részletezte.Szerk.: mondjuk nem vagyok az ügyvédje, majd megvédi magát, csak ez már nekem is feltűnt.
Biztos neked is szarul esett volna, ha az elején jól beoltanak. -
#927
Sk8erPeter
nagyúr
martonx
#924
Sk8erPeter
nagyúr
Miért röhejes? Kezdőknek hasznos lehet, hogy nem kell szarakodni a külön-külön telepítéssel, egyben van minden, elindítod a setupot, next-next-csá. Van még pár ilyen gyorsan használható cuccos, mint az EasyPHP meg társai. Mondjuk Windows-on IIS + a Web Platform Installerrel is klattyolgatós felületen lehet ezeket telepíteni.
Azért egy kezdőt ne oltogass ilyen durván, ne vedd el a kedvét. Te is elkezdted valahogy, azóta a szokásaid nyilván sokat fejlődtek.
A phpMyAdmin lehet, hogy keveset tud, de a legtöbb hosting cégnél akkor is az van, nem árt, ha megtanulja kezelni.
A phpMyAdminban egyébként sztem az a nevetséges, hogy a mai napig framesetek használatára építenek, meg amúgy sem látok benne túl nagy fejlődést, már az is nagy számnak tűnt, hogy a jQuery UI-t kezdték el használni, meg AJAX-ot kezdtek el alkalmazni. Meg tényleg lassú.(#915) Bishoop :
tényleg "fura" az a tutorial, ahol ahelyett, hogy sql-dumpokat adnának a "kezedbe", inkább azt mondja, irányítsd oda a datadir-t... Lehet, hogy nem a legjobb segédanyag.(#920) Speeedfire :
tényleg könnyen feltörhető? -
#912
Sk8erPeter
nagyúr
Peter Kiss
#909
Sk8erPeter
nagyúr
válasz
Peter Kiss
#909
üzenetére
Na, ez tök jó, ilyen sem sűrűn volt közöttünk, most mindegyik mondatoddal egyetértek.
(Lehet, hogy ez egyszer nem fogunk vitába szállni, pezsgőt bontok 
) Kivéve azzal, hogy "nem PHP-s, tudom, kapjam be". Én aztán nagyon nem vagyok PHP-rajongó. Jelenlegi terveim szerint a jövőben webes területen éppen ASP.NET-re szeretnék átállni teljesen, vagy valamelyik Java-s technológiára. Eleve mondjuk az általam kedvelt C#, Java, C++ nyelvek közül bármelyikben sokkal szebben lehet kódolni (kevésbé sarkall gányolásra, vagy engedi azt), mint PHP-ben (tudom, kapjam be ).
Addig is az általad említett PHP-s frameworkök engem is foglalkoztatnak, pont ezek a "menőbbek", amiknek a használatát már sokszor szerettem volna megtanulni. -
#910
Sk8erPeter
nagyúr
Speeedfire
#908
Sk8erPeter
nagyúr
válasz
Speeedfire
#908
üzenetére
Az a jó, amikor felteszed a kérdéseidet, tanácsokat kérsz, aztán meggyőzöd magad végül a saját magad által kitalált megoldás helyességéről.
-
#907
Sk8erPeter
nagyúr
Peter Kiss
#906
Sk8erPeter
nagyúr
válasz
Peter Kiss
#906
üzenetére
Ha már itt tartunk, milyen framework az, ami tapasztalataid meg kódja alapján szted jónak minősül?
Minden frameworknek van valami bakija, de kíváncsi vagyok, szted melyik az, amelyiket lehet jónak nevezni. -
#905
Sk8erPeter
nagyúr
Speeedfire
#902
Sk8erPeter
nagyúr
válasz
Speeedfire
#902
üzenetére
"Persze, meg a juzer_id-hoz is."
Még elmondhatod tizenötször is, akkor sem lesz több értelme. Tervezési kérdés, és eleve nem helytálló olyanhoz kapcsolni a táblát, aminek köze nincs hozzá. A júzer felad egy hirdetést, aztán a hirdetéssel babrál, ezt a babrálást tartalmazza a másik tábla. Akkor mi értelme van a user id-hoz kapcsolni? Honnan a francból tudod, mondjuk a 100 hirdetése közül melyikkel babrált, ha nem tartalmazza a másik táblád a hirdetés id-ját?
Mindegy, nem foglak tovább győzködni, ha nem fogadod el, hogy csak szopatod magad ezzel a megvalósítással, és nehezen lesz lekérdezhető, továbbfejleszthető, akkor ez van."Ez igaz (kb 5x írtam már le, hogy igaz...), de nem a keresés fog dominálni az oldalon. Nem tudom máshogy leírni neked.
"
Már sokadszor írtam le más formában, de ez nem indokolja az igénytelenebb megvalósítást. Nem tudom máshogy leírni neked."A drupal.hu-t hanyagoljuk, mert ott a segítség nem erősség."
Ez sajnos sokszor helytálló (meg van kb. 10 ember, aki aktívan válaszol, és még ért is hozzá, bár néha a stílusuk nem valami simulékony), de ugyanez már kevésbé igaz a http://drupal.stackexchange.com/-ra. Ott a kérdések többségére tuti kapsz valami választ, hacsak nem túl komplikáltan fogalmazod vagy maga a kérdés nem teljesen egyedi/új problémát érint.
Szerk.: meg most már aktív a PH!-s Drupal topic is."De nagyobb is a biztonság, mert senki sem ismeri a kódot."
Hát erről a helyedben azért inkább nem lennék meggyőződve. -
#900
Sk8erPeter
nagyúr
Speeedfire
#890
Sk8erPeter
nagyúr
válasz
Speeedfire
#890
üzenetére
"A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb."
Attól még lehet a hirdetés_id-hoz kapcsolni."Nagyon keveset fognak az oldalra látogatók keresni hirdetőket."
Már megint kezdünk elbeszélni egymás mellett. Korábban még júzerek paramétereiről (hajszín, szemszín, csöcsméret, stb.) beszéltünk.
Arról beszéltem, hogy ha egyes paraméterekre szűkítenek, akkor nem mindegy a sebesség. varchar-alapú keresés meg lassabb lesz, mint a tinyintre keresés.
De nekem mindegy."Jogos, de nekem most itt nem ez volt a szempont. Legyen valahogy jelölve, melyek tartoznak az adott oldalhoz. Így később sem kell bajlódni a nevekkel, ha költözik másik szolgáltatóhoz."
Miért, a tbl_ prefix csak a saját védjegyed, teljesen egyedi valami?"Adott dolgokra jó, most is drupal van rajta. Csak ha már konkrét igények vannak, akkor én azt már drupallal nem tudom megoldani."
Pedig ott a Drupal topic, meg a drupal.hu meg még számtalan potenciális segítség.
Rengeteg dolog ráadásul készen van modul formájában.
Persze az tény, hogy a Drupal-modulfejlesztés beletanulásához is bőven kell idő, meg hogy az ember átlássa a dolgokat. De ehhez nagyon jó könyvek vannak az 1. hsz.-ben a belinkelt topicban."Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik."
Ez tény, de több is a potenciális hibalehetőség (pl. nincs felügyelve egy közösség által, mint a legtöbb Drupal-modul), meg egyes feladatok megvalósítása sokkal szopóbb lehet, ha mindent elölről, saját agyból és erőből kell megoldani. -
#888
Sk8erPeter
nagyúr
Peter Kiss
#887
Sk8erPeter
nagyúr
válasz
Peter Kiss
#887
üzenetére
"A tbl_user táblában miért van benne a salt?"
Na igen, ezt én is kérdeztem, még mindig nem látom az okát. -
#886
Sk8erPeter
nagyúr
Speeedfire
#885
Sk8erPeter
nagyúr
válasz
Speeedfire
#885
üzenetére
"A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben."
Ez itt attól még sztem nem szempont, mert a konkrét hirdetést boncolgatod tovább, arra jelölsz meg külön táblában kiemelést, tehát a hirdetés_id szerint lenne értelme összekapcsolni a két táblát."Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett."
Ezt kifejtenéd?
Ha tinyint vs. varchar, akkor az utóbbi mellett keresés ideje szempontjából nem túl sok szempont szól....."Nagyon sok keresés szerintem nem fog itt lenni."
Szép, magyaros mondattal jól megaszontad."Szinte az összes hirdető az emberek arcába lesz nyomva, így csak görgetnie kell és nézegeti a felhasználókat. Mivel te tudod már milyen tartalmú oldal, ajánlom nézd meg a konkurenciát.
"
Még mindig nem látok semmilyen érvet amellett, hogy varchar legyen a mező. Mi köze ennek ahhoz, hogy néz ki a többi oldal? Attól még nem látod, a háttérben hogy oldják meg, az, hogy a frontendre hogyan kerül ki a tartalom, nem befolyásolja azt, hogy hogyan kellene megoldani szépen a háttérben."Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban."
A prefix önmagában indokolt lenne, de inkább úgy, hogy egyértelműen jelölsz vele valamit, pl. application id-t vagy hasonlót."Miért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag."
A korábbi struktúrádban TEXT-et jelöltél meg a tagre, ez volt az elsődleges gond, de látom azt már legalább azóta javítottad.
A táblaszerkezet meg nálad közel sem volt egyértelmű, inkább félrevezető: volt forum tábla, volt postokat gyűjtő tábla, meg volt comment tábla. Ebből olyan, mintha a fórumokhoz lehetne postot is írni, meg kommentet is. Erre mondtam, hogy ennek úgy van értelme, ahogy a stackoverflow-n van, de ott mondjuk az is bonyolítja, hogy a postok majdnem ugyanúgy kezelendőek, ahogy az első, nyitópost is, mert mindet lehet pontozni, meg mindet el lehet fogadni, mint megfelelő választ, kivéve az első, nyitópostot.
A tagek meg csak magára a kérdésre kellenek, ami az elnevezéseidből úgy tűnt, magába a forum táblába tartozik, mint gyűjtőtábla. De akkor ezek szerint csak nem voltak egyértelműek az elnevezések.Amúgy csak azért kérdeztem rá, miért nem CMS-t használsz erre a célra, mert mások már eleget szoptak azzal, hogy megfelelő táblastruktúrát kialakítsanak ilyesmire, mint pl. a fórum, ami Drupalnál eleve a core része. Mondjuk ha tanulási céllal akarsz sajátot fejleszteni, akkor oké. De ha a könnyű továbbfejleszthetőség is cél, akkor ezerszer jobban járnál pl. egy Drupallal (persze minimum 7-es verzió), nagyon jól testreszabhatóak a fórumok is, jó modulok készültek hozzá.
-
#884
Sk8erPeter
nagyúr
Speeedfire
#872
Sk8erPeter
nagyúr
válasz
Speeedfire
#872
üzenetére
"A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát.
"
Miért nem a hirdetés id-vel kapcsolod össze? A kiemelés a hirdetésre vonatkozik, a hirdetés megvásárlója meg egyértelmű, hogy kicsoda, elég egyszer tárolni. Mivel a hirdetés részleteit boncolgatod tovább, tök értelmetlen a user id-t letárolni a külön táblában. Az összekapcsolás is egyértelműbb lenne.
A kérdéseimre meg nem nagyon válaszoltál, úgyhogy úgy veszem, hogy nem kell neked a segítség."A másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban"
Hát felőlem... de ha majd a teljesítmény-szempontok kerülnek majd előtérbe (keresés lassabb lesz, mert szövegalapú keresgélést kell végrehajtani, nem pl. egy tinyintre kell rákeresni, annak mentén összekapcsolni a táblákat), lehet, hogy változtatnod kell majd az adatbázis-struktúrát, és akkor majd szidni fogod magad, hogy miért nem alakítottad ki eleve jól. Mondjuk ha akkor újabb lóvét adnak, akkor nyilván nem.=================
(#873) Soak :
jaja, én is sokszor hasznát vettem már. Főleg akkor jön jól, amikor nincs kedved gondolkozni.=================
(#881) Speeedfire :
most ez ujjgyakorlat? Vagy miért nem használsz tényleg valami CMS-t? (pl. Drupalt, ha már van tapasztalatod vele...)
Miért kezded minden táblád nevét tbl_ prefix-szel? Mivel adatbázisban van, elég egyértelmű, hogy itt táblák lesznek.Amúgy mi az az "ext" mező a tbl_post_items-nél?
Az meg remélem csak egy rossz vicc, hogy a posthoz tartozó tageket TEXT-ként akarod letárolni. A másik, hogy ha már külön táblád van a tbl_forum-nak, akkor ahhoz kéne kapcsolni a tageket, nem a posthoz - vagy minden hozzászólásnak külön taget szeretnél? Gondolom nem.
De az mindenesetre biztos, hogy a tagek összekapcsolását egy teljesen különálló táblában kéne megcsinálni, nem pedig egy TEXT típusú mezőben...
A usernél a saltot miért tárolod külön?
Minél többet nézem a struktúrádat, annál furább dolgokat látok. Miért kell külön tbl_comment és tbl_post tábla a FÓRUMHOZ? Most akkor kommentálni is lehet a fórumot, meg külön hozzászólást is lehet írni? Mi a különbség? Ha kommentálni lehet, akkor már miért nem magát a bejegyzést, ahogy pl. stackoverflow-n van?
Na, most inkább nem nézem tovább.(#883) Speeedfire: miért, régen nem volt komolyabb?
-
#871
Sk8erPeter
nagyúr
Speeedfire
#869
Sk8erPeter
nagyúr
válasz
Speeedfire
#869
üzenetére
Jó, akkor elmondom a problémámat (egyébként gondolhatod, h ezeket segítő szándékkal mondom
Te is sokszor visszakérdezel, úgyhogy ne szóljá' be ) az itt írtakkal:
ha jól értem, vannak hirdetések "valamikre" az oldalon, amiket le lehet foglalni bizonyos időtartamra. Vagy meg lehet venni. Vagy kiemeltté lehet nyilvánítani egy adott hirdetést. Mittudomén, melyik, ez nem volt egyértelmű, pedig sokat segítene az érdemi megvalósításban. Vegyük mondjuk azt, h van egy kéró, amit bérbe lehet venni, megveszi mondjuk egy júzer az X-től Y-ig tartó időtartam erejéig. VAGY van egy júzer, aki felrak hirdetést, és azt kiemeltté lehet nyilvánítani, és akkor prioritást élvez a többi hirdetéssel szemben. De azt írod, "A kiemeléseknél van egy hely értéke, ami azt mutatja, hogy melyik helyet ki vetette meg mettől meddig." - attól függ a hely értéke, hogy mennyi ideig vette meg valaki? Vagy mennyi ideig számít kiemelt hirdetésnek?
Ez akkor ha jól értettem, változna mondjuk hetenként, mert egy-egy hétre lehet "megvenni" (ki tudja milyen értelemben) ezeket a helyeket. Akkor viszont csak adott időtartamra érdekes egy hely értéke, nem értem, miért akarod ezt nullázni: "Ha a következő hétre nem vett helyet akkor lenullázom az értékét." Adott hétre vonatkozik az érték, akkor a következő hétnél az előző hétre vonatkozó értékkel nem kell foglalkozni, újabb sor kerül a táblába, és annyi. De mondom, mindenféle megvalósítási kérdés a konkrét, jobban specifikált feladattól függene. Lehet, hogy szebben is meg lehetne oldani a feladatodat. Van egyszer user_id a hirdetés táblájában, meg a kiemelés táblában. Feltételezem, ennek az az oka, hogy van egyszer a hirdető, meg van egyszer a vásárló. De akkor ezek szerint nem a hirdetés kiemeltté minősítéséről van szó. Tehát körbe-körbe csavarodik valahogy ez a sztori, ha elsőre elolvasom a hsz.-edet, mert sztem a specifikáció így hiányos, és nehéz rá megmondani a tutit. De ha azóta megoldottad, akkor végül is nekem mindegy.==============
Amúgy erre nem nagyon reagáltál, hogy mi is a gondod vele. -
#868
Sk8erPeter
nagyúr
Speeedfire
#861
Sk8erPeter
nagyúr
válasz
Speeedfire
#861
üzenetére
A kiegészítő paramétereket nyilván nem kézzel kéne hozzáírnod, hanem mondjuk legenerálni.
Amúgy hány paraméter van?Egyébként próbáld ki a dbForge Studio for MySQL progit, szerintem iszonyat jó, sokkal jobb, mint a MySQL Workbench, nekem komplex query-k összeállításához való segítségként nagyon jól jött már párszor. Van, amikor nem áll össze fejben a query (pl. nagyon összetetteknél már belekavarodsz), és ilyenkor egy ilyen grafikus alapú program elég jól jön.
===
A unionos kérdésre azért nem reagálok, mert ott inkább először visszakérdeznék, de akkor meg jössz azzal, hogy na már megint én vagyok a hülye, mert nem értem a kérdésedet egyből. -
#859
Sk8erPeter
nagyúr
Speeedfire
#857
Sk8erPeter
nagyúr
válasz
Speeedfire
#857
üzenetére
"2-3-4 táblát join-olni? He? csak 1 táblát kellene a fő mellé, de az on záradékban lenne egy pár bejegyzés 40-50 mezőnél."
Hát nem tudom, ez neked hogy jön ki.A legegyszerűbb eseteket mondom.
- 1 tábla a paraméter (szemszín, hajszín, stb.) id-jának és ember által olvasható nevének; esetleg lehet machine_name-je is, ami nem tartalmaz ékezeteket, stb., csak olvashatóbb azonosításra szolgál (opcionális). Vegyük azt az esetet, hogy mondjuk nem kívánod lefordítani a paraméterek (szemszín, hajszín, stb.) nevét, VAGY ha lefordítod, akkor ugyanabba a táblába bedobálod külön mezőként a fordításokat nyelvek szerint (bár elvileg szét kéne bontani, és lenne mondjuk egy id-je egy fordítási "csomópontnak", ahogy már említettem). Szóval
id | name
(vagy translation_node_id)
- 1 tábla a paraméterek (szemszín, hajszín, stb.) lehetséges értékeinek (pl. szemszín: barna, zöld; hajszín: ugyanezek, stb.), tehát pl.
param_id | param_value. Ez szebben megint inkább külön id-val lenne tárolva, tehát param_id | param_value_id felosztásban, és a paraméterek lehetséges értékeinek lenne tök általános külön táblája is; ez azért is lehet érdekes, mert a szemszínek és hajszínek közt sok egyező is lehet (pl. barna).
- 1 tábla a felhasználók által beállított paramétereknek; lehet esetleg egy bitmezővel (vagy tinyint 0, 1) jelezni, hogy saját beállított paraméteréről, vagy a kívánt partner paramétereiről van szó; így pl.
user_id | param_id | param_value_id | is_own
felosztás.Ez egy lehetséges megoldás. És igen, a feltételek között az egyezőségek vizsgálatakor elég sok paraméter fog szerepelni, ha OR-ral választod el, akkor még paraméterek egyezőségét is tudod vizsgálni százalékosan, egyetlen lekérdezéssel akár... tehát rengeteg előnye van ennek a felosztásnak (tapasztalat).
"csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000."
500-600 felhasználónál sem mindegy, meddig tart egy lekérdezés eredményeinek megmutatása. Ha jól értem, az oldal legfőbb profilja egyfajta társkeresés lenne, így itt pont ez lehet a szűk keresztmetszet a sebességben a sok keresgélés miatt. -
#854
Sk8erPeter
nagyúr
Speeedfire
#849
Sk8erPeter
nagyúr
válasz
Speeedfire
#849
üzenetére
"Akkor te külön kapcsolótáblát tennél mondjuk a 40 mezőhöz?
"
Hogy mi van? Te valamit nagyon félreérthettél.
Én azt mondtam, hogy nehogy már ismétlődően stringeket tárolj, hogy sokszor előforduljon, hogy "szemszin", "szemszin", "szemszin", 'hajszin", "hajszin", "hajszin".............. Mi van, ha egyszer meg akarod változtatni az ember által is olvasható, stringesített nevét? Ha lesz mondjuk 5000 felhasználód, akkor 5000 helyen cserélsz majd le egy stringet?
Egy teljesen egyedi azonosítót viszont valószínűleg nem akarnál megváltoztatni, mert tök felesleges.
Ráadásul itt tök feleslegesen stringeket tárolsz, amikor tárolhatnál tiny/smallinteket is mondjuk...A lekérdezéshez meg elég a paraméter nevét tartalmazó táblát hozzákapcsolni, ha név szerint szeretnél lekérdezni...
ha meg "nincs kedved" joinolgatni 2-3-4 táblát - egy szebb megoldást választva -, akkor válassz másik szakmát. (bocs, de ezt muszáj volt )==============
(#850) martonx :
hát az szerintem meg nagyon nem "szabályos menet", hogy mindenhol ismétlődően stringeket tárol, mint a "hajszin", "szemszin", stb. stringek...
Tök jó, hogy megdicséred, de ne akkor tedd, amikor rossz módszert alkalmaz. -
#848
Sk8erPeter
nagyúr
Speeedfire
#841
Sk8erPeter
nagyúr
válasz
Speeedfire
#841
üzenetére
MINDENT id szerint azonosíts. Soak tanácsa szerintem nagyon rossz, hogy inkább mindent varcharral vagy texttel tárolj, kerülendő megoldás, mert nagyon sok partner közti keresésnél észrevehetően lassú lesz a szövegalapú keresgélés.
Az id-khoz tartozó neveket pedig külön tárold. Pl. legyen egy parameters tábla, abban pedig id | name vagy hasonló. De hogy továbbvigyük: gondolj bele, mi van, ha pl. ezeket a neveket fordítani is kell. Akkor még a fordításhoz tartozó "csomópontot" is id szerint érdemes inkább hozzákapcsolni, és a fordítást megint külön táblában tárolni. Tehát akkor meg id | translation_node_id felosztásban lehet. (persze beleerőltetheted azonos táblába az összes fordítást, úgy, hogy minden nyelvhez külön "oszlop" tartozik, de az sem egy túl szép megoldás, nem biztos, hogy mindenre van fordítás, és akkor ott addig NULL van)
Sok ilyen esetben érdemes inkább sok-sok logikailag különálló táblát külön is tárolni, a táblakapcsolások nem fogják nagyon lassítani a lekérdezéseidet, sőt, adott esetben sokkal gyorsabb lehet.Egyébként dolgoztam a tiédhez hasonló feladaton, akkor nem így "oszloponként" tároltam a paramétereket (úgy, hogy
id | hajszin | szemszin | ...
), hanem széjjelbontva,
id | param_id | param_value_id
"csoportosításban" (pl. 1 | 5 | 6, ránézve az adatbázisra persze nem túl beszédes, csak a megfelelő tábla hozzákapcsolásával). -
#814
Sk8erPeter
nagyúr
_Roy_
#813
Sk8erPeter
nagyúr
jó, akkor másképp kérdezem:
az egyik táblában lévő id-t tartalmazza a másik, aminek mentén be lehet azonosítani, hogy melyik névhez melyik e-mail tartozik?
Remélem...
Annyit tudtunk meg, hogy van password mindkét táblában (bár nem értem, minek, vagy miről van szó), van username az egyikben, a másikban meg ki tudja mi.
De gondolom mindkettőben van id.
Ne rohanva írd már le, ha neked kéne segítség, hanem írd körül normálisan. Vagy egyszerűen mutass egy SQL dumpot a táblaszerkezetről legalább. -
#812
Sk8erPeter
nagyúr
_Roy_
#811
Sk8erPeter
nagyúr
Igen, tudnánk segíteni, ha leírnád, mivel próbálkoztál, meg milyen mező "mentén" kellene összekapcsolni a két táblát.
Az sem mindegy, hogy LEFT JOIN, RIGHT JOIN, INNER JOIN, stb., mert tudni kéne, mely értékek kellenek neked. Csak azok, amelyek mind a két táblában megvannak? -
#804
Sk8erPeter
nagyúr
CSorBA
#795
Sk8erPeter
nagyúr
No de ezen az alapon az ügyfél akár csillagot vagy akármi mást is írhat a karakterek elválasztásaként kötőjel helyett. Erre a legegyszerűbb, ha a telefonszámot felhasználóbarát módon szétválasztod ország-előhívószámra, körzetszámra, stb., aztán vagy konkatenálva töltöd fel adatbázisba, vagy külön is tárolod ezeket. A validáció meg kliens- és szerveroldalon is elkerülhetetlen, de én a helyedben mindenképp szétbontanám, hogy elkerüljem az ilyen problémákat.
Szerk.: most látom, hogy már hatezer éves (soknapos) kérdés volt, és a (#793)-ban lényegében Te is azokról beszéltél, amiket leírtam.
-
#773
Sk8erPeter
nagyúr
vakondka
#772
Sk8erPeter
nagyúr
válasz
vakondka
#772
üzenetére
Szívesen, örülök, hogy segítettem.
Amúgy még annyi kimaradt, hogy a SELECT melletti felsorolásnál persze ne felejts el majd egyedi nevet adni a `products_name` mezőknek, hogy egyértelműen le tudd majd kérdezni mondjuk PHP-vel. (csak példa: pdesc_4.`products_name` AS products_name_4)======
(#771) PazsitZ :
nekem most nem jut eszembe jobb/gyorsabb megoldás tárolt eljárással sem.
Mire gondolsz? -
#770
Sk8erPeter
nagyúr
vakondka
#769
Sk8erPeter
nagyúr
válasz
vakondka
#769
üzenetére
Hali!
Szerintem legegyszerűbb megoldás INNER JOIN-olni újból ugyanazzal a táblával, az alábbi lekérdezést teszteltem is, nálam 0.0015 másodperc alatt lefutott:
SELECT
pr.`products_id`, pr.`products_model`, pr.`products_price`,
pdesc_1.`products_name`, pdesc_4.`products_name`, pdesc_5.`products_name`
FROM
`products` AS pr
INNER JOIN
`products_description` AS pdesc_1
ON pr.`products_id` = pdesc_1.`products_id`
AND pdesc_1.`language_id` = 1
INNER JOIN
`products_description` AS pdesc_4
ON pr.`products_id` = pdesc_4.`products_id`
AND pdesc_4.`language_id` = 4
INNER JOIN
`products_description` AS pdesc_5
ON pr.`products_id` = pdesc_5.`products_id`
AND pdesc_5.`language_id` = 5Itt a táblák neveit a JOIN-nál direkt úgy neveztem el, hogy beszédes legyen, tehát ha pl. a 4-es language id-vel JOIN-oltam, akkor pdesc_4 lett a JOIN-olt tábla neve.
Remélem erre gondoltál.
Nem csodálom, hogy rosszul esett. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ne haragudj, biker. 
Az ára, akciós ára meg aztán végképp állandóan változik... Szerinted nem épp az a feleslegesen redundáns, hogy a leírás ennyiszer szerepel a táblában? Vagy nem is értem az elgondolást.
Üdítőbb ezeknél egy érdemi kérdésről témázás, igaz, Apollo17hu lényegében másnak oldja meg a munkáját tök ingyen, mindenesetre a kitartásáért jár neki a virtuális sör. 
Mivel úgy csináltál, mintha a korábban belinkelt hozzászólásaimban ne soroltam volna el azokat a dolgokat, amik viszont tetszenek a MySQL Workbench-ben, pedig de.) A gyökereknek szóló lmgtfy-s linkedet pedig külön köszönöm, eddig fogalmam sem volt, hogy kell ilyesmit a Gúúgölben keresni. 
Új hozzászólás Aktív témák
- Asztali PC , i5 9500 , 1660 Super , 16GB DDR4 , 512GB SSD
- Dell Latitude 5410 Laptop 14", i5-10310U, 8 GB, 512 GB, Touch, Win11 - B
- BESZÁMÍTÁS! Sony PlayStation 5 Slim 1TB SSD lemezes konzol garanciával hibátlan működéssel
- BESZÁMÍTÁS! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
- BESZÁMÍTÁS! Sony PlayStation 4 PRO 1TB fekete játékkonzol garanciával hibátlan működéssel
- Bomba ár! HP Elitebook Folio 9470m - i5-3GEN I 8GB I 32SSD + 500GB I 14" I Cam I W10 I Garancia!
- Honor X6b 128GB, Kártyafüggetlen, 1 Év Garanciával
- Ventillátorok és tápkábel modding kitűnő árakon! Most extra 10% kedvezmény!
- iKing.Hu -Xiaomi 14T Pro Titan Gray Használt, karcmentes állapotban 12 GB RAM / 512 GB tárhely
- GYÖNYÖRŰ iPhone 13 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS2931, 100% Akkumulátor
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest