- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
Új hozzászólás Aktív témák
-
#1468
martonx
veterán
Sk8erPeter
#1467
martonx
veterán
válasz
Sk8erPeter
#1467
üzenetére
Igazad van nem ildomos, de feladat függő, szóval ha jól értettelek, akkor ebben az esetben ez így jó lesz.
-
#1460
PiXeL90
tag
Sk8erPeter
#1456
PiXeL90
tag
válasz
Sk8erPeter
#1456
üzenetére
Adatbázis-kliens verziója: libmysql - 5.5.32
PHPMyAdmin Verziószám: 3.5.8.1deb1
Apache/2.2.22 alatt fut.A lefutatott query így nézett ki:"INSERT INTO regiok(`kereslet_id`, `regio_id`)VALUES($kereslet, $regio)";
De egy másik táblában is lefuttattam és ott nem volt ilyen hiba.
-
#1459
bbTamas77
aktív tag
Sk8erPeter
#1458
bbTamas77
aktív tag
válasz
Sk8erPeter
#1458
üzenetére
Nagyon szépen köszönöm, így már menni fog.
-
#1450
biker
nagyúr
Sk8erPeter
#1447
biker
nagyúr
válasz
Sk8erPeter
#1447
üzenetére
haha, szólj ha felnőttél...
-
#1440
biker
nagyúr
Sk8erPeter
#1439
biker
nagyúr
válasz
Sk8erPeter
#1439
üzenetére
"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.Van egy ömlesztett napló, amiben minden módosítás benne van, ebből kikereshető a kérdésre a válasz, de mondtam azt is, nem a legrugalmasabb, de ott van.
nyilván, ha külön helyen van kezelve, ez jobban követhető, van akinek még ez a naplózás is felesleges. -
#1434
biker
nagyúr
Sk8erPeter
#1430
biker
nagyúr
válasz
Sk8erPeter
#1430
üzenetére
nem, csak fáradt vagyok.
írtad, nem bírom a kritikát. de bírom, de kritizálni azt lehet, amit ismerünk, nem hallottunk róla.
tegnap el is kezdtem nézni Alföldi István a királyát, de rá kellett jöjjek, tényleg szar, előre nem írtam le a cuccot, hátha csak a kritikusok azok, de nem, tényleg az volt.a jelen állapotában lévő webshopom egy 2006-os, akkor kb 3 tábla összesen 30 oszlopából fejlődött egy 13-14 táblából, azokban összesen vagy 120 oszlopos szörnyeteggé, 7. verzió, toldozva foldozva, és nem volt kedvem modernizálni, mert nincs akkora kereslet fizetős webshopra, hogy dolgozzak és töltsem az időt, mert csak fizetős időm van, szabad időm 4 éve nincs, hogy hobbira magamnak fejlesszek.
A rendszer "működőképes", és nem "optimális" és nem "szent". Nem is állítottam soha, hogy csak így lehet, és ez a jó út, azt mondtam, működik, és nem értem, miért CSAK másképp lehet, ahogy ti mondjátok
(jut eszembe, várom a hirdetésem linkelését a kollégától még)Majd ha ez emberek nem a woocommerce féle ingyen sz@rokat keresik, lehet ki lesz fejlesztve a modern verziója, addig nem.
az akciós kérdésben nem értünk egyet, a többiben igen
és nem hinném, hogy ettől, hogy itt szétszedtetek darabokra, bármi hibát elkövettem volna az utóbbi pár év fejlesztéseiben (nem 2006-ban meg előtte, mikor még tapasztalat nem volt) mivel minden azóta írt egyedi rendszerem (szerintem) okosan szét van szeparálva, legyen az a fitness szoftver, aminél a tagokat, bérleteiket, vásárlásaikat kezeli a rendszer, sok sok táblában sok sok XY_ID kapcsoatokkal, joinokkal, vagy legyen az a szerviztámogató program, ahol tagok-kapcsolattartók-címek-klímák-események-munkalapok rendszerezése és kezelése folyik, ugyanígy, és azon kell vitatkozzak a kedves megrendelővel, hogy nem, qrvára nem kellene egy munkalap szám alá 4 klíma javítást felvinni, mert nem releváns infó, egyik gépen ezt csináltam, másikon azt, ha 1 év múlva csak X klíma érdekel, ne hozza már le munkalap kapcsolat miatt Y Z klímákat is, de nem akarja megérteni, mert szerinte 15 lapot nem lehet borítékbe tenni, mert nem látott még L6-ná nagyobb borítékot.
az ok azt jelentette, olvastam, köszönöm, nincs mondanivalóm, mert nem érek rá ontani a szót, és nem mosdatni akarom magam.
-
#1433
fordfairlane
veterán
Sk8erPeter
#1432
fordfairlane
veterán
válasz
Sk8erPeter
#1432
üzenetére
Utólag refaktorálható az adatszerkezet. Egyébként az ilyen függőséget nem kell feltétlenül tankönyvszerűen kezelni. Ha nincs túl sok mező, amit érint a dolog, a NULL használata is korrekt megoldás.
-
#1431
fordfairlane
veterán
Sk8erPeter
#1428
fordfairlane
veterán
válasz
Sk8erPeter
#1428
üzenetére
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.
Ha ez a tranzitív függőség bennmarad, az még nem olyan nagy tragédia ( 3NF helyett csak 2NF ).
-
#1429
biker
nagyúr
Sk8erPeter
#1428
biker
nagyúr
válasz
Sk8erPeter
#1428
üzenetére
ok
-
#1419
biker
nagyúr
Sk8erPeter
#1416
biker
nagyúr
válasz
Sk8erPeter
#1416
üzenetére
"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.
Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?
Ugyanazzal a lekérdezéssel lehet, mint amivel külön tábla esetén tennéd, és joinolnád az id-khez a termékeket a termékek táblából, nem?Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van
Pont ugyanúgy és ugyanaz elvégezhető így isAz echo "hello world"; is leírható így is
<?php
class myClass
{
function sayHello()
{
echo "Hello there!";
}
}
?><?php
require_once('myClass.php');
$myClass = new myClass();
$myClass->sayHello();
?>
-
#1417
Peter Kiss
őstag
Sk8erPeter
#1416
Peter Kiss
őstag
válasz
Sk8erPeter
#1416
üzenetére
A gond szerintem ott lesz, hogy gyakorlatilag a PH!-n is hirdet, és, ha valaki meglátja a megkérdőjelezést, akkor elbizonytalanodhat. Mi kérünk elnézést?
-
#1394
Jim-Y
veterán
Sk8erPeter
#1393
Jim-Y
veterán
válasz
Sk8erPeter
#1393
üzenetére
Még nem tudtam kipróbálni a kapott választ ezért nem válaszoltam, majd jövő héten.
Azok a tartományok, amik bővebbek, és amikből kevesebb van, azokat csv fájlokban kapok(unk) meg, és azt is egy ETL eszközzel töltjük be az adatbázisba. Időnként frissül. Az a tábla, ahol ezresek a felbontások, azt már én hoztam létre, mert az elvárás az, hogy ezres legyen a felbontás, ne pedig változó.
Az a feladat, hogy abban a táblában, ahol a bővebb felbontások vannak, 1-1 ilyen felbontásra meg van határozva valami, a példa kedvéért legyen az, hogy 'Fontos', 'Nem fontos'
Na, kipróbáltam az SQLFiddle-t, jó cucc, nem hallottam még róla
http://sqlfiddle.com/#!2/588bd6/3
És akkor talán így már világos a feladat is. T2 'range_jelolo' oszlopát szeretném feltölteni T1 'Jelolo' oszlopa alapján.
-
#1382
martonx
veterán
Sk8erPeter
#1381
martonx
veterán
válasz
Sk8erPeter
#1381
üzenetére
Ez igaz, de tudod mikor jut eszedbe minden évente, vagy két évente utánhúzni?
Mi pont idén szívtunk ezzel, amikor 5 évvel ezelőtt 5 évre előre belőttük az adatokat, aztán valamikor májusban tűnt fel elöször, hogy év eleje óta szarul számol pár algoritmus. -
#1376
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Nem is konkrét buktatókra gondoltam, hanem pl. az összes ünnepnapot, különös tekintettel a mozgó ünnepekre, mondjuk húsz évre előre meghatározni, elég babra munka tud lenni.
Azaz a végeredmény nem annyi, hogy egy szép nagy insert-tel feltöltesz minden napot, hanem utána az ünnepnapok, munkaszüneti napok, munkanap áthelyezések, hosszú hétvégék a macerásak. -
#1375
Jim-Y
veterán
Sk8erPeter
#1374
Jim-Y
veterán
válasz
Sk8erPeter
#1374
üzenetére
Végül tárolt eljárás lett belőle. Azért megosztom hátha valamire még használni lehet
DELIMITER $$
DROP PROCEDURE IF EXISTS `ranges` $$
CREATE DEFINER=`user`@`%` PROCEDURE `ranges`()
BEGIN
DECLARE v1 INT DEFAULT 2000000;
WHILE v1 < 9999999 DO
INSERT INTO test_table(range_from, range_to) VALUES (v1, v1+999);
SET v1 = v1 + 1000;
END WHILE;
END $$
DELIMITER ; -
#1358
martonx
veterán
Sk8erPeter
#1357
martonx
veterán
válasz
Sk8erPeter
#1357
üzenetére
Ez igaz, csak engem zavar, hogy akármikor benézek, mindig látom, hogy MySQL topikban esemény volt, aztán ide kattintva látom, hogy már megint egy 800 soros hsz. érkezett.
Persze azon el lehet témázni, hogy mi illik ide, meg mi nem. Szvsz a hogyan kell mysql-t telepíteni, meg miért fut le hibásan a select * from table lekérdezésem nem illik ide, mert aki ilyet kérdez, az meg se próbálja az agyát / guglit használni.
Ugyanakkor van az a szakmai mélység is, ami szintén nem illik ide, egyszerűen nem hiszem, hogy egy olyan komplexitású feladat, aminek a normális megfogalmazása, példa adatostól, egy - két alap lekérdezéssel több A4-es lapot venne igénybe, annak a megoldását egy fórum keretein belül kellene kiszenvedni.
Ráadásul most borítékolom, hogy a megoldás sem egy húsz soros sql script lesz a végén, ergo a topik tényleg semmit nem fog profitálni belőle.
Apollo-nak valóban nagy riszpekt érte, hogy ingyen ennyit segít, nem is ellene szólt az észrevételem, csak jeleztem, hogy ha ennyire ráér, meg ennyire érdekli a probléma, akkor vegye fel a kapcsolatot direktben szmegma-val, aztán skypeozzanak, emailezzenek, oldják meg egymás között. -
#1325
biker
nagyúr
Sk8erPeter
#1324
biker
nagyúr
válasz
Sk8erPeter
#1324
üzenetére
5385 sor érintett. ( a lekérdezés 0.0782 másodpercig tartott )
UPDATE users SET nev = LTRIM(nev); egész pontosan... -
#1302
nova001
senior tag
Sk8erPeter
#1301
nova001
senior tag
válasz
Sk8erPeter
#1301
üzenetére
köszi tényleg...megtaláltam
-
#1294
spammer
veterán
Sk8erPeter
#1293
spammer
veterán
válasz
Sk8erPeter
#1293
üzenetére
Ja, akkor félreértettem
Azt hittem, hogy röviden akarta kifejezni, hogy hogyan ne csináljuk Furcsa is volt, hogy így volt megfogalmazva 
Akkor jó, akkor maradok a != -nél
-
#1174
futár
senior tag
Sk8erPeter
#1173
futár
senior tag
válasz
Sk8erPeter
#1173
üzenetére
Teljesen félreértettél! A klónozás egyike a legjobb megoldásoknak, de azért lenne jó, ha a programot is tudnám átrakni, mert bővültünk egy géppel és azon Win 7 van. Azt viszont, cég lévén valamint mivel már nincs XP kereskedelmi forgalomban és a meglévőt nem is lenne gazdaságos lecserélni... Szóval erre a gépre is fel szeretném rakni. Ez egy készletnyilvántartó program, ahol képekkel, vonalkóddal spékelve lehet készíteni termék adatlapokat. Az elmúlt 5 év során megtanultuk. Anno meg is vettük. Ebben a gazdasági helyzetben örülünk, hogy élünk. Ezért lenne fontos a probléma ilyen módú megoldása, ha nem megy, akkor marad a "B" terv.A program könyvtárszerkezete a következő? Van a program a 'C' gyökérben és ugyanitt egy MYSQL könyvtár is. Tulajdonképpen ennyi. Ha nincs más, akkor megy 1 gépen.
-
#1172
futár
senior tag
Sk8erPeter
#1171
futár
senior tag
válasz
Sk8erPeter
#1171
üzenetére
Megpróbálom! A jogosultságra azért nem tudok mit mondani, mert soha nem állítottam semmit. Volt egy felhasználónevem és jelszavam a programhoz, és kész. Ennyi. Nem kellett semmit csinálni, csak annyit, hogy a MySQL-t elindítottuk parancssorból. De ezek rég voltak már. Mint írtam is. Csak a forgalmazó legalább 4 éve nem létezik. Még XP-re volt telepítve, de ugye már Win 8-nál tartunk. Ezért kérdeztem a többi lehetőséget. Mert akkor használhatnám azon a rendszeren is.
-
#1167
futár
senior tag
Sk8erPeter
#1166
futár
senior tag
válasz
Sk8erPeter
#1166
üzenetére
Azért a MySQL topikba írtam, mert a progi MySQL alapú, megvan az adatbázis is. A progi nem telepítős, vagyis a partíciómentésnél lehet egyszerűbb is lenne. Ha simán átmásolom, akkor a jelszó - felhasználónév nem változhat, mégis
"MySQL has gone away" hibát ír ki. És
"SQL hiba: denied for user 'ODBC'@'localhost' (using password: NO)
Ezekre gyógyír esetleg? Arra mód,hogy csak a programot klónozzam, vagy backupoljam? -
#1124
vakondka
őstag
Sk8erPeter
#1123
vakondka
őstag
válasz
Sk8erPeter
#1123
üzenetére
Most 97 találat van, szerintem ez lesz a jó verzió
Köszi!
-
#1122
vakondka
őstag
Sk8erPeter
#1121
vakondka
őstag
válasz
Sk8erPeter
#1121
üzenetére
A MySQL üreset adott vissza (nincsenek sorok). (A lekérés lefutott 0.0007 másodperc alatt)
-
#1120
vakondka
őstag
Sk8erPeter
#1119
vakondka
őstag
válasz
Sk8erPeter
#1119
üzenetére
Idáig én is eljutottam:
SELECT products.* FROM products
LEFT JOIN products_description ON
products.products_id = products_description.products_id WHERE products_description.products_id IS NULLViszont nem tudom hogyan szűkítsek az adott language_id-re, mert akárhogyan csinálom nulla eredmény a fenti lekérdezéssel meg 90 találat van
-
#1101
martonx
veterán
Sk8erPeter
#1100
martonx
veterán
válasz
Sk8erPeter
#1100
üzenetére
ööö ez igaz
-
#1099
martonx
veterán
Sk8erPeter
#1098
martonx
veterán
válasz
Sk8erPeter
#1098
üzenetére
php-s méretkorlát problémába biztosan nem futsz vele
-
#1097
martonx
veterán
Sk8erPeter
#1096
martonx
veterán
válasz
Sk8erPeter
#1096
üzenetére
hehe, no ilyenkor tud jó lenni a Toad for MySQL
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#1092
Babetta-X
senior tag
Sk8erPeter
#1091
Babetta-X
senior tag
válasz
Sk8erPeter
#1091
üzenetére
Ez a mondat nem hangzott túl meggyőzőnek
Már másolom fel az általad javasolt programot, meglátjuk mire jutok vele. Köszönöm a segítséget! -
#1090
Babetta-X
senior tag
Sk8erPeter
#1089
Babetta-X
senior tag
válasz
Sk8erPeter
#1089
üzenetére
Nem az egész adatbázist szeretném lementeni, csak az user és a post adatokat (háromszáz valamennyi regisztrált tag van és néhány adagnyi bejegyzés) a többi elvileg nem is olyan fontos nekem. Újratelepítés után ezeket az adatokat szeretném visszaimportálni.
Sajnos én semmilyen hibanaplóról nem tudok wordpress alatt, én eddig csak hobbiszinten foglalkoztam php-nuke-val szóval sok újdonság van a dolgokban Eddig akármilyen tárhelyen voltam volt külön oldal ahol be tudtam lépni az adatbázisba, sajnos ez itt elmaradt. -
#1088
Babetta-X
senior tag
Sk8erPeter
#1087
Babetta-X
senior tag
válasz
Sk8erPeter
#1087
üzenetére
Köszönöm, mivel ilyen téren 0 tudással és tapasztalattal rendelkezem, ráadásként az angol nyelv is nehézkes, ezért megpróbálom először az egyszerűbbet. Igazándiból a wordpress cms van most fent, ennek bizonyos tábláit szeretném lementeni majd újratelepítés után visszahelyezni.
-
#1082
PazsitZ
addikt
Sk8erPeter
#1057
PazsitZ
addikt
válasz
Sk8erPeter
#1057
üzenetére
Ha nem finamkodtál akkor én miért nem engedhetek meg magamnak egy kis fricskát?
Egyébként a hozzáállásom attól még nem negatív, hogy te valamiért oda vagy én meg nem. (értsd: grafikus kattintgatós query builder)El kell ismételnem úgy tűnik, még mindig se érdekem, se kedvem védeni a workbenchet.
Nem tudtam, hogy 2 darab pipe-olt konzolparancs felvágásnak számítana?
Nem köcsögösködtem.
Attól, hogy te az igazság bajnokának tekinted magad észrevehetnéd, hogy más véleménye sem fekete-fehér.
Ha azt mondom, hogy én nem látom hasznát, az nem ekvivalens azzal, hogy "hatalmas baromság", amit te mondasz, akárhogy is próbálod csavargatni.
-
#1080
biker
nagyúr
Sk8erPeter
#1079
biker
nagyúr
válasz
Sk8erPeter
#1079
üzenetére
ja, ugyanide jutottam én is
most egész kellemesen dobálja a találatokat gépelés közben. -
#1077
biker
nagyúr
Sk8erPeter
#1076
biker
nagyúr
válasz
Sk8erPeter
#1076
üzenetére
persze, alapvetően jó dolgok.
csak megtalálni az egyensúlyt az erőben, nehéz -
#1070
biker
nagyúr
Sk8erPeter
#1069
biker
nagyúr
válasz
Sk8erPeter
#1069
üzenetére
mikor a cimkefelhő még LIKE keresésekre ment rá, és jött a googlebot indexelni akkor végigpörgette azokat, termékenként 10-30 cimke, konkrétan 130.000 termékhez 1m feletti cimke, melyek random jelennek meg minden lap alján, ezért mindig változó tartalommal rágerjedt a bot rendesen) + a kereső mezőt is kezelte a bot, akkor 50-60.000 cikkig nem volt gond, aztán betoltuk a LÍRA 40.000 könyvét, és másnap letérdelt a site
és csak néztünk, mi a fene van?
egy keresés hirtelen 15mp lett, és mikor betelt a que akkor cumi, leállt a mysqlmost is megy, ez csak a googlebot(!!):
havi 370.000 keresési lekérdezés
22.000 kattintás1.403.400 egyedinek vélt oldal, amiből 620.000 indexelve (a keresett termékek is egyedi oldalon jelennek meg, becsapva a botot, + egyedi fejléc + egyedi keyword és description oldalak)
napi átlag 38.000 oldal feltérképezés (csúcs 68.000)
átlagos adatforgalom 850Megabyte (csúcs 1,6Giga) (gzipelés nélkül ez elment napi 4-5gigabyteba)
oldalak betöltési ideje átlag 852ms, csúcs 1,4s
(na ez ment át 25-30mp-be a várakozó lekérések miatt)Na ezt nem akarom feladni
-
#1068
biker
nagyúr
Sk8erPeter
#1067
biker
nagyúr
válasz
Sk8erPeter
#1067
üzenetére
mert nem szeretem, ha elérhetetlen az oldal, és ha elkezdi a user írni, átlagos mp-enkénti 2 karakter sebességgel a szöveget, hogy "fűrészlap" akkor az 6-7mp alatt 9 keresés, 9x0,2-0,3mp
ezt szorozzuk fel a napi 1200-1400 látogató oldalbetöltéseivel és keresésével, és kijön egy szép letérdelős oldal
Mint mikor régen másképp ment a kereső, és a google indexelte az oldalt az új cimkefelhővel, és naponta letérdelt az adatbázis emiattEzért alapértelmezett a kereső match-el indexelve, és csak az összetett keresőben tud a user olyat választani, hogy adott mezőkben szótöredékre keres
+ a LIKE lekérést nem lehet relevancia szerint rendezni, a match-ot meg lehet score-ba tenni és úgy megjeleníteni, és így a zsindelyes szőlő pálinka első találatot ad, míg LIKE esetén meg se találja, ha a név zsindelyes pálinka, szőlő
érted?
-
#1056
PazsitZ
addikt
Sk8erPeter
#1054
PazsitZ
addikt
válasz
Sk8erPeter
#1054
üzenetére
Nekem egyáltalán nem baj, hogy számodra nem lenne hasznos, amit én szeretnék használni
Ha nem, akkor miért ezen pörögsz lassan egy hónapja?Továbbá :
Még mindig nem próbáltam hülyeségnek beállítani az elvárásaidat/igényeidet.
Nem hoztam ki győztesnek semmit.
Még mindig nem mondtam, hogy amit szeretnél hülyeség.Legalább is emlékeim szerint, nincs kedvem visszaolvasni. De lassan belátom, igazából én vagyok a hülye, hogy válaszolok ezekre a posztokra.
Bár feltételezem nem a topikhoz tartozik, de mi az a "gizdulás"?
-
#1052
PazsitZ
addikt
Sk8erPeter
#1047
PazsitZ
addikt
válasz
Sk8erPeter
#1047
üzenetére
Nem tudom mi az a "gizdulás".
Nem tudom mit nem sikerült feldolgozni azon, hogy én szeretem pl .a konzolt. Elnézésedet kérem ezért.
Tippem szerint te big data kezelés, data mining megoldásokra gondolsz, ami kicsit másik műfaj, szvsz.
De azt még mindig nem értem ,hogy miért kell besértődni, hogy történetesen számomra felesleges, amit te konkrétan szeretsz használni.
Használd, senki nem írta, h ne tedd. Én meg nem használom, remélem ezt meg tudod emészteni. -
#1048
Soak
veterán
Sk8erPeter
#1047
Soak
veterán
válasz
Sk8erPeter
#1047
üzenetére
Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz?
Hol létezik olyan, hogy 100 táblát kell joinolni?
-
#1038
PazsitZ
addikt
Sk8erPeter
#1037
PazsitZ
addikt
válasz
Sk8erPeter
#1037
üzenetére
Belátom.
Nem tudom mit lehet nem belátni azon, hogy ez másnak (nekem legalább is) ez nem egy elgördíthetetlen akadály.
gunzip < [sqls.gz] | mysql -u [uname] -p[pass] [dbname]Ja igen, erre írtad, hogy ez szerinted f@szság
Nem így írtam és túlzásnak érzem ezt a kifejezést. Nem az, csak én nem látom igazi hasznát.
De lehet én szoktam az utóbbi időben túlzottan konzolhoz.
( ma is megkaptam, hogy miért akarok konzolból verziókezelőzni, mindenki GUI klienst használ hozzá )Nagyvállalati környezetről eddig nincs releváns tapasztalatom, 200 táblás
összekapcsolással kapcsolatosan sem.
Egyébként szerintem meg nem. De majd hátha van valaki, aki nagyvállalatokban jártas és megmondja nekünk. -
#1036
PazsitZ
addikt
Sk8erPeter
#1035
PazsitZ
addikt
válasz
Sk8erPeter
#1035
üzenetére
Emlekeim szerint nem irtam, h tudna ilyet, tovabba azt sem, h felesleges. De nem vagyok benne biztos, h kitomoritve nem tud egyszerre tobb sql dumpot is felnyalni.
-
#1032
martonx
veterán
Sk8erPeter
#1020
martonx
veterán
válasz
Sk8erPeter
#1020
üzenetére
CMS-nél tényleg hasznos lehet bizonyos esetekben egy ilyen feature. Én mondjuk olyan mélységben sose használtam CMS-t, mint te. Ellenben én meg minden táblámat ismerek, azaz fel sem merül, hogy vajon hol melyikben kezdjek keresni egy-egy értéket.
-
#1029
PazsitZ
addikt
Sk8erPeter
#1028
-
#1026
PazsitZ
addikt
Sk8erPeter
#1022
PazsitZ
addikt
válasz
Sk8erPeter
#1022
üzenetére
A múltkor konkrétan pl. azért volt rossz, mert te 1-2 funkciót nem találtál meg benne elsőre.
Most azért rossz, mert egy másik alkalmazás feature-e nincs beleépítve.
Továbbá megjegyzem, nem veszem komolyan a dolgot, semmi okom védeni a workbench-et, pláne nem zaklat fel, hogy hányan használják vagy nem használják.
Átjött, hogy szándékos túlzás, szarkazmus az ostoba szar kifejezés, ezért használtam idézetként.Minden esetre "trollozás"om megint csak idézet arra vonatkozik, hogy milyen racionális észérveket szoktál felsorolni.
De még mindig azt tudom, mondani, teljesen komolyan, sértődöttség, trollkodás nélkül (nem egy nyakatekert logika): hogy ha nem jó neked, akkor ne használd.
-
#1025
whYz
őstag
Sk8erPeter
#1024
whYz
őstag
válasz
Sk8erPeter
#1024
üzenetére
Igen, de a gametypeid es a packetid folyamatosan valtozni fog, tehat igazabol az egyedi gametypeid-re vagyok kivancsi.
-
#1021
PazsitZ
addikt
Sk8erPeter
#1020
PazsitZ
addikt
válasz
Sk8erPeter
#1020
üzenetére
Biztos én vagyok ilyen szempontból ingerszegény környezetben, de sosem volt szükségem, igényem ilyenre.
De hála neked legalább most már tudjuk, mitől ostoba szar valami a phpMyAdminhoz képest.
De tényleg, ha minden ilyen fos, szar, akkor miért próbálod használni?
Sőt, miért nem írsz jobbat? -
#1019
martonx
veterán
Sk8erPeter
#1018
martonx
veterán
válasz
Sk8erPeter
#1018
üzenetére
bocs, félreértettelek. Fel se merült bennem, hogy valaki ilyet akarna tenni, hogy egy DB összes táblájában keresni akar valamit. Miért teszel ilyet? Ha van jópár több millió soros DB-d, akkor azok mennyire szeretik vajon ezeket a fajta kereséseket? És miért jó az, ha két óra múlva kapsz mondjuk egy választ, de cserébe megölted a komplett SQL szervert az ártatlan kereséseddel?
Az, hogy egy GUI ilyen kényelmi funkciót biztosít, szvsz inkább hátrány, mint előny. -
#1017
martonx
veterán
Sk8erPeter
#1016
martonx
veterán
válasz
Sk8erPeter
#1016
üzenetére
ööö lehet én vagyok kocka, de ezekere a keresésekre vannak beépített SQL táblák, amik megmutatják a DB szerkezetét. Erre való az information_schema.
-
#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.
-
#1009
Lacces
őstag
Sk8erPeter
#1008
Lacces
őstag
válasz
Sk8erPeter
#1008
üzenetére
Köszi, elég béna voltam most keresésben... én valahogy nem találtam normálisat... kösz
-
#1007
Lacces
őstag
Sk8erPeter
#1006
Lacces
őstag
válasz
Sk8erPeter
#1006
üzenetére
Yeap, utána eszembe jutott... mysql workbench
.
Úgy értettem, mint a phpmyadmin, aminek segítségével a mysql adatbázist tudod "kezelni" weblapon keresztül, csak ugye a phpmyadmin-nak kell, hogy a webszerveren legyen telepítve és futattva a php. Ha jól tudom a phpmyadminnak meg mindegy, hogy linux/windows, a lényeg a webszerver neki (apache, iis)
Na én meg ilyesmit akartam java alaponMásik kérdésem ami nekem homály, ez a skálázhatóság dolog. Vannak sémák arra, hogy hogyan lehet egy mysql adatbázist megtervezni, hogy jól skálázható legyen?
-
#990
MadarasTESCO
csendes tag
Sk8erPeter
#989
MadarasTESCO
csendes tag
válasz
Sk8erPeter
#989
üzenetére
kösz, kiagyaltuk már.
-
#979
lakisoft
veterán
Sk8erPeter
#978
lakisoft
veterán
válasz
Sk8erPeter
#978
üzenetére
Meg kell írni a hiányosságokat a fejlesztőcsapatnak hátha ráharapnak és megcsinálják.
-
#977
lakisoft
veterán
Sk8erPeter
#975
lakisoft
veterán
válasz
Sk8erPeter
#975
üzenetére
Nem azt mondtam rá hogy tökéletes hanem hogy jól használható.
-
#976
PazsitZ
addikt
Sk8erPeter
#975
PazsitZ
addikt
válasz
Sk8erPeter
#975
üzenetére
user letrehozas, komplett elore konfiguralt jogosultsag szintekkel van. Szerintem korabban is volt.
Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez.
A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul... -
#974
lakisoft
veterán
Sk8erPeter
#972
lakisoft
veterán
válasz
Sk8erPeter
#972
üzenetére
Nyugodtan nézd meg szerintem nagyon sokat fejlődött korábbi verzióihoz képest.
-
#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.
-
#969
lakisoft
veterán
Sk8erPeter
#967
lakisoft
veterán
válasz
Sk8erPeter
#967
üzenetére
És mi a helyzet a MySQL Wordbench-el? Nekem ez tökéletesen bevált, eddig.
-
#955
Speeedfire
félisten
Sk8erPeter
#954
Speeedfire
félisten
válasz
Sk8erPeter
#954
üzenetére
Bezzeg ha te lennél a munkatársa...
-
#938
Speeedfire
félisten
Sk8erPeter
#937
Speeedfire
félisten
válasz
Sk8erPeter
#937
üzenetére
Nem referencia.
Csak leírtam, hogy én hogy teszteltem. -
#936
Speeedfire
félisten
Sk8erPeter
#935
Speeedfire
félisten
válasz
Sk8erPeter
#935
üzenetére
Ott akkor szerintem valami nem kerek. Nálam az sqlbuddy gyorsabb, win7 64bit/wamp64bit alatt.
-
#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. -
#932
martonx
veterán
Sk8erPeter
#931
martonx
veterán
válasz
Sk8erPeter
#931
üzenetére
Továbbra sem a wampp-al van a gondom. Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges).
Azon nevettem, hogy mindezt mysql-ezéshez, mert az első hsz-ből más nem derült ki. És igen, tudom bunkó vagyok
Ahogy visszaolvastam az egészet, ismét végig nevettem az első hozzászólás mysql - wampp - könyv javaslatán a data könyvtár átirányításáról. Legközelebb megpróbálom magamban tartani az érzelmeimet. -
#929
martonx
veterán
Sk8erPeter
#927
martonx
veterán
válasz
Sk8erPeter
#927
üzenetére
Életem első használt adatbázisa a MySQL volt. Anno letöltötem a mysql.com-ról, meg leszedtem mellé a Toad-ot (gugli dobta ki), és next-next telepítettem őket. Akkoriban még fórumok se nagyon voltak, mégis boldogultunk. A Toad varázslóit használtam, közben buzgón elemzve a generált SQL scripteket. Bevallom soha nem olvastam egy SQL-es könyvet sem.
A wampp, xampp dolgokban nem maga a wampp, xampp a gáz, hanem az a röhejes, hogy valaki mysql-t akar tanulni, és ehhez nem az az első logikus lépése, hogy felteszi a mysql-t, meg hozzá egy rendes gui-t, hanem felrak egy komplett keretrendszert, minden felesleges szarral együtt.
Olyan ez mintha autót akarna megtanulni vezetni, és ehhez előbb vesz egy komplett autószalont, miközben csak egy autó kellene.Mondjuk később kiderült, hogy webfejleszt emberünk a gépén, szóval ha értelmesebben fogalmazott volna, és nem azt mondja, hogy a mysql miatt raktam fel wampp-ot, hanem a wampp adott volt, akkor nem is kezdem el fikázni, hanem csak a PHPmyadmin helyett javasoltam volna valami rendes GUI-t.
-
#928
Speeedfire
félisten
Sk8erPeter
#927
Speeedfire
félisten
válasz
Sk8erPeter
#927
üzenetére
Állítólag a php-n keresztül könnyen feltörhető. Nem tudom. Én csak mindig ezt hallom a linux guruktól*.
*webhostingosok
-
#914
Peter Kiss
őstag
Sk8erPeter
#912
Peter Kiss
őstag
válasz
Sk8erPeter
#912
üzenetére
Igazából ezért hegesztek magamnak keret a .NET framework mentén (nyilván kisebbet, egyszerűbbet), építés közben szoktam néha ledöbbenni, hogy mennyire adják egymást a megoldások, pl. nem egyszer volt, hogy kigondoltam egy megoldást az adott problémára, és pont ugyanazzal a megközelítéssel találkoztam az MSDN-en is.
-
#913
Speeedfire
félisten
Sk8erPeter
#910
Speeedfire
félisten
válasz
Sk8erPeter
#910
üzenetére
Dehogy győzöm...
PazsitZ: Ezt nem is vitatom, hogy kisebb oldalakhoz ajánlott.
Vagy a yii vagy a symfony volt nálam terítéken. De mivel a symfony nekem egy brutális nagy állat, ezért annak nem estem neki. Nem is portálokat "szoktam" fejleszteni, ezért is marad szimpatikus a yii. Illetve közelemben is ezt használják, így segítséget is könnyebb volt az elején kérni. -
#909
Peter Kiss
őstag
Sk8erPeter
#907
Peter Kiss
őstag
válasz
Sk8erPeter
#907
üzenetére
Entity Framework meg az ASP.NET MVC (nem PHP-s, tudom, kapjam be).
Amelyek most mennek nagyobb frameworkok mindegyik bugzik, a Zend Framework 2-t szeretném majd jobban átvizsgálni, illetve a Symfony-t, Doctrine-t.
-
#908
Speeedfire
félisten
Sk8erPeter
#905
Speeedfire
félisten
válasz
Sk8erPeter
#905
üzenetére
Okcső! Ne is beszélgessünk többet! Nem tudjuk meggyőzni egymást!
Athlon64+: Én eddig pedig csak jókat olvastam a yii-ről. Több nagyobb cég/weblap is ezt használja. -
#902
Speeedfire
félisten
Sk8erPeter
#900
Speeedfire
félisten
válasz
Sk8erPeter
#900
üzenetére
Attól még lehet a hirdetés_id-hoz kapcsolni.
Persze, meg a juzer_id-hoz is.
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.
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.Miért, a tbl_ prefix csak a saját védjegyed, teljesen egyedi valami?
Pedig ott a Drupal topic, meg a drupal.hu meg még számtalan potenciális segítség.
A drupal.hu-t hanyagoljuk, mert ott a segítség nem erősség. Anno pont emiatt kezdtem el foglalkozni a php-val, mert nem tudtak/akartak segíteni.Ez tény, de több is a potenciális hibalehetőség
De nagyobb is a biztonság, mert senki sem ismeri a kódot.Mindenhez van pro és konktra. Én is mérlegeltem mindent, de nekem ezek a dolgok lettek szimpatikusak.
Athlon64+: Már, hogy ne használnám. Még illusztráltam is kóddal.
Illetve ez a salt jól jön még jelszó visszaállításkor is, meg bármire használható, mert ez is unique. Szóval minden felhasználónál egyedi.Az ORM-nek utána néztem, ha jól értem a yii is ezt használja és tudtomon kívül én is. Csak én nem tudom, hogy ez az ORM...
-
#890
Speeedfire
félisten
Sk8erPeter
#886
Speeedfire
félisten
válasz
Sk8erPeter
#886
üzenetére
"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."
A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb.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.....
Wááá!
Pont ezt írom, hogy ezeken az oldalakon a keresés nem jellemző. Belép valaki az oldalra és előtte van 100+x hirdető az 1. oldalon a második oldalon meg megint 100+x összesen max 500-600 hirdetés. Nagyon keveset fognak az oldalra látogatók keresni hirdetőket.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.
Nem, de látom az oldalon működését. Meg belső infókat kapok!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.
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.A tages dolgot meg indokoltam már.
PH! copy!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
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.
Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik.
Athlon64+:
A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
Azóta már azt is beleraktam, illetve egy ordert is. A status csak az aktív/inaktív miatt van benne más egyéb miatt még nem gondolkoztam rajta el.sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.
Nem tudom erre mennyire jó megoldás, de én láttam már olyat, hogy felvesznek a model-ben pár constans változót, ami ezeket hivatott megmondani.
plconst STATUS_DRAFT=1;
const STATUS_PUBLISHED=2;
const STATUS_ARCHIVED=3;Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
Hát, ezen még nem agyaltam. Csak írtam, ami eszembe jutott.Ugye lesznek majd index-ek is?
Nyilván lesznek és vannak is.Látom mindenki leragadt a salt mellett.
Ezt a yii-ből vettem.A salt regisztrációkor kerül a táblába ami egy unique kulcs és amikor valakit validál a rendszer akkor ezt is nézi.
public function validatePassword($password)
{
return $this->hashPassword($password,$this->salt)===$this->password;
}
public function hashPassword($password,$salt)
{
return md5($salt.$password);
} -
#889
Soak
veterán
Sk8erPeter
#888
Soak
veterán
válasz
Sk8erPeter
#888
üzenetére
Nem hash akart lenni vajon?
-
#885
Speeedfire
félisten
Sk8erPeter
#884
Speeedfire
félisten
válasz
Sk8erPeter
#884
üzenetére
A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben. Jobbnak láttam, inkább a user_id-t használni erre.
Valóban nem kell már a segítség, amilyen infó kellett azt megkaptam.Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett. Nagyon sok keresés szerintem nem fog itt lenni. 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.
De majd meglátjuk, hogy mit fog majd csinálni az oldal.Eddig is cms-t (drupalt) használtam, de nekem egyedibb megoldásokra, jobban fekszik egy saját kód, mint egy cms.
Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban. Nem tudom, ezt így szoktam meg.
Az ext mező a fájl kiterjesztése. Több féle fájl mehet egy bejegyzéshez. Akár kép, akár pdf stb. Képeknél meg jobb szeretem így használni, ha vannak kisebb/nagyobb képek. Könnyebb belinkelni a képeket. valami.tn.jpg/valami.jpg/valami.small.jpgMiért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag.
User salt. Mégis hol kellene ezt tárolni?Minden egyes bejegyzéshez tartozik egy fórum és a fórumhoz tartozik a comment. A fórum csak a fórum címeket tárolja el. Kicsit úgy, mint itt a PH!-n.
Ez az újabb, javított verzsön.
De, régen is komolyabb volt.
-
#873
Soak
veterán
Sk8erPeter
#868
Soak
veterán
válasz
Sk8erPeter
#868
üzenetére
Kurvajó ez a progi, kicsit probálgattam a trial-t , tök bonyolult queryket elsőre össze kattingattam 1perc alatt.
-
#872
Speeedfire
félisten
Sk8erPeter
#871
Speeedfire
félisten
válasz
Sk8erPeter
#871
üzenetére
Adott a 2 tábla. Mindenki hirdethet az oldalon, de ha gondolja akkor ki is emelheti magát, adott hétre, adott helyre*.
*adott hely: 100db kiemelési hely van. Az 1. van legelöl, a 100. van a legvégén.A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát.
Tehát, van a lekérdezés, ami már jól megy.
Itt ugye lekérdezi az összes felhasználót a hirdetés táblából, akik adott kategóriában hirdetnek. Ha van az aktuális időpontban lekérdezése, akkor ahhoz az 1-100 közötti értéket hozzárendeli. Ez lesz az order értéke.
Akiknek nincs adott hétre kiemelése, azoknak pedig 1000 lesz ez az order érték, így a lista legvégén lesznek.Én jelenleg ezzel értem el ezt a lekérdezést. Lehet van jobb, egyszerűbb, de nem vagyok egy sql májer.
SELECT t.id, t.cim, (t.nap_2_0) as start_time, (t.nap_2_1) as end_time, t.telszam, t.pid, t.kid, ifnull(k.kid, 1000) as sorrend
FROM `tbl_hirdetes` t
LEFT JOIN (
select kuid, kid from tbl_kiemeles_fizetve where k_ido<=1347353832 and v_ido>=1347353832
) k ON (t.pid=k.kuid)
order by sorrendA másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban. Emiatt páran biztos megköveznek majd, meg gányolás...de mindegy. Én ezt találtam most a legjobb megoldásnak. AR-ben nem fogok, mindent join-olni. Illetve nem is vagyok annyira megfizetve, hogy ezzel szenvedjek.
-
#861
Speeedfire
félisten
Sk8erPeter
#859
Speeedfire
félisten
válasz
Sk8erPeter
#859
üzenetére
Igen, ezt értem én is. Csak az on miatt nagyon sok lekérdezést kellene magamtól megírni.
Az unios kérdésre meg ezt találtam:
select h.id, h.pid, ifnull(k.id, 1000) as sorrend
from tbl_hirdetes h
left join tbl_kiemeles_fizetve k
on (h.pid=k.kuid)
where ((k.k_ido<=1346955990 and k.v_ido>=1346955990) or k.id is null)
order by sorrend -
#857
Speeedfire
félisten
Sk8erPeter
#854
Speeedfire
félisten
válasz
Sk8erPeter
#854
üzenetére
Dehogyis, az hajszin, szemszin csak a fő tábla mezője lenne, illetve a második kereszttáblában is csak amiatt, hogy számomra jól értelmezhető legyen. Lásd "1." hsz-emet.
Pont, hogy tinyint-eket akarok tárolni.
40-50 mezőhöz, ha mondjuk lesz olyan 300-400 sor sor a kereszt táblában. Ahol csak 1 mező a varchar és csak amitt, hogy Én tudjam legalább, hogy mi az.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.
Lényegében egy portál szerű dolog lenne, de csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000.
Gondolkozok rajta, hogy kőműves leszek.
martonx: Köszi, akkor marad a join. -
#856
martonx
veterán
Sk8erPeter
#854
martonx
veterán
válasz
Sk8erPeter
#854
üzenetére
Lehet nem voltam elég érthető? Én arra a módszerre értettem a szabályosat, hogy van egy paraméter táblája, és ebből csak az ID-ket tárolja le ténylegesen. Ezért is írtam a normalizálásról, meg a Paraméter tábláról.
-
#849
Speeedfire
félisten
Sk8erPeter
#848
Speeedfire
félisten
válasz
Sk8erPeter
#848
üzenetére
Akkor te külön kapcsolótáblát tennél mondjuk a 40 mezőhöz?
Illetve te a lekérdezést, hogy oldanád meg? Nincs kedvem a select selectjének a selectjét lekérdezni, illetve se joinolni ennyi táblát.
Csak, mert én simán arra gondoltam az előzőből kifolyólag hogy lenne egy Masodik_tabla model, amiben lenne mondjuk 2 funkció.$item = 'hajszin';
public function items($tem) {
//innen visszadna egy tömbböt, ahol az item mezőben hajszin van, illetve a hozzá tartozó code-ot is
//itt pl visszadná, hogy 1=>barna, 2=>szőke
}
//a másik funckió
$code = 1;
$item = 'hajszin';
public function item($item, $code) {
//itt pedig visszadná azt ahol az item a hajszin és a code értéke 1
//mondjuk azt, hogy barna
} -
#813
_Roy_
tag
Sk8erPeter
#812
_Roy_
tag
válasz
Sk8erPeter
#812
üzenetére
left joinnal próbáltam, mind a két tábla értékei kellenének, viszont vannak olyan mezők pl password, ami mind a kettőben password
az egyik elsődleges kulcsa (username) a másikban ezek az adatok email mezőbe vannak de nem elsődleges kulcs, ott id az elsődleges kulcs -
#805
CSorBA
őstag
Sk8erPeter
#804
CSorBA
őstag
válasz
Sk8erPeter
#804
üzenetére
És ami még jobb, hogy már minden létező telefonszám-tárolós helyen meg is csináltam a 3 oszlopos tárolást
-
#772
vakondka
őstag
Sk8erPeter
#770
vakondka
őstag
válasz
Sk8erPeter
#770
üzenetére
Szia,
Tökéletes!
Nálam az élő szerveren 0,0021 alatt futott le ami szuperKöszi!
-
#762
RexpecT
addikt
Sk8erPeter
#761
RexpecT
addikt
válasz
Sk8erPeter
#761
üzenetére
De ezt szeretném, köszönöm a segítséget
. -
#738
sonar
addikt
Sk8erPeter
#736
sonar
addikt
válasz
Sk8erPeter
#736
üzenetére
Elnézést. Nem mindig vagyok a szavak embere
-
#737
martonx
veterán
Sk8erPeter
#736
martonx
veterán
válasz
Sk8erPeter
#736
üzenetére
A sima sql-es topikban meg ott van a másik emberünk a "csak admin tudjon módosítani egy mezőt" SQL szinten agymenésével. Hihetetlenek.
-
#734
sonar
addikt
Sk8erPeter
#733
sonar
addikt
válasz
Sk8erPeter
#733
üzenetére
Azért mert ez azt adja vissza, hogy van nekem mondjuk 25 db 2755-ös bejegyzésem.
De én meg azt akarom látni, hogy van 2755 és van 2756 és van 2759 de nincsen 2758.
Talán igy már érthetőbb. Bocs ha keverek, de nem igazán tudom másképp megfogalmazni -
#732
sonar
addikt
Sk8erPeter
#731
sonar
addikt
válasz
Sk8erPeter
#731
üzenetére
Sajnos nem igazán jól fejeztem ki magamat.
Amit te irtál az megszámolja, hogy hány van. Nos nekem csak az kellene, hogy van
2755 és van 2756..
Szerintem a Distinct-tel kellene valahogy operálni -
#729
Sk8erPeter
nagyúr
Sk8erPeter
#728
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#728
üzenetére
Oké, csak most látom, hogy az SQL-kérdés topicban már oltottátok hasonló okok miatt a srácot.
-
#715
ArchElf
addikt
Sk8erPeter
#714
ArchElf
addikt
válasz
Sk8erPeter
#714
üzenetére
Teszel köré egy ilyet:
SELECT user_id, Count(*) As count_user_id
FROM ( ... )
GROUP BY user_idAE
-
#679
martonx
veterán
Sk8erPeter
#674
martonx
veterán
válasz
Sk8erPeter
#674
üzenetére
xdebug-ot én is használom, nem is azt mondtam, hogy PHP-t nem lehet debugolni, hanem azt, hogy sokkal nehézkesebb, mint más nyelveket. Egyébként SQL-t is lehet debugolni, legalábbis MS SQL-t 2008 fölött, illetve a MySQL-t 5-ös verzió felett.
Az indokaim, hogy miért jobb SQL szinten tartani az adatlogikát (félre értések elkerülése végett én sem 100%-ban SQL szinten valósítom meg, csak törekszek rá).
1. Az SQL nagyon buta, cserében bődületesen hatékonyan, akárhány szálra, akármennyi memóriára optimalizálva kezeli az adatokat, adatműveleteket. Rengeteg konkurens felhasználó kiszolgálására van optimalizálva, akárhány magot, akármennyi memóriát ki tud használni.
2. SQL szerverek általában jóval erősebb hardverek, mint a webkiszolgálók.
Hozhatnék itt ezeregy példát, ebben a fenti két pontban minden benne van, hogy miért érdemes az SQL szintre törekedni. És hangsúlyozom, nem a Pistike-féle olcsó hosztingokra gondolok, ahol egy Core2-es szerver egymaga a webkiszolgáló, és az adatbázis szerver is (bár kis mértékben, de az 1-es pont miatt itt is kijön az SQL-es megközelítés előnye), hanem a nagyvállalati infrastruktúrákra. Nálunk pl. a webkiszolgálók (igaz több is van belőlük), 1-4 processzormaggal és 2-4 Gb memóriával rendelkeznek. Míg a legkomolyabb SQL szerverünk 128 maggal, és 320 Gb memóriával rendelkezik.
Egy komolyabb programkód logika már néhány tíz konkurens felhasználónál kifekteti a webkiszolgálót, míg ugyanaz SQL szinten megvalósítva, mondjuk kisebb mint 5%-os processzorterhlést jelent az adatbázis szervernek, és emiatt szintén minimális terhet a webkiszolgálónak.
-
#670
martonx
veterán
Sk8erPeter
#668
martonx
veterán
válasz
Sk8erPeter
#668
üzenetére
Toad for MySQL-t szoktam használni. Nagy tudású, debug-ot is tud.
MySQL-nek van valami ingyenes menedzsment felülete is, állítólag az se rossz, de még sosem próbáltam.
A Toadban azt szeretem, hogy a felületénél megadható, hogy hasonlítson az MS SQL Mangement Studio-hoz, így nem kell mindent máshol keresnem, mint ahol megszoktam. -
#667
martonx
veterán
Sk8erPeter
#666
martonx
veterán
válasz
Sk8erPeter
#666
üzenetére
Nálam php 5.3.5 van, és MySql 5.5. akárhány van (amiket a legújabb xampp tartalmaz). Ha ezekkel megy neked a mysqli, akkor le a kalappal.
Én SQL fejlesztés alatt masszív tárolt eljárás írást értek kurzorokkal, deklarálásokkal, temporary táblákkal. Szeretem amennyire csak lehet adatbázishoz közel tartani a logikát. Aztán az már, hogy az adott tárolt eljárást mysql-lel vagy mysqli-vel hívom meg számomra kb. mindegy.
Mivel innentől kezdve a mysqli-t mellőzöm, a javasolt PDO-t ki fogom próbálni, felkeltetted az érdeklődésemet, köszi!
-
#665
martonx
veterán
Sk8erPeter
#664
martonx
veterán
válasz
Sk8erPeter
#664
üzenetére
Nem az a baj, hogy ezeket használod, én is használom a hoszting tárhelyeken. Na de ezeket fejlesztésre használni??? A szükség esetén használatával egyetértek, de amikor azt mondja valaki, hogy ezen fejleszt, az a szememben vicc kategória. Jó, mondjuk ki mit ért fejlesztés alatt. Két táblát létrehozni, meg köztük egy join-os selectre, valóban jó tud lenni bármi, még a mysql parancssora is. Ha már itt tartunk minek a phpmyadmin, ha ugyanezt tudja a parancssor is?
A mysqli többet tud, mint a mysql, viszont mysql is jó (ha akarod azt is beágyazhatod egy osztályba, és akkor megvan az objektum orientáltság is), és ott legalább nincsenek ilyen szívások, mint amikor én is pont a héten vettem észre, hogy a mysqli nem hajlandó a legújabb php, mysql, apache verziókkal működni. Egy rakás mysqli-s cuccal a gépemen nem volt felemelő felismerés.
Így magamban el is könyveltem fosként (ettől még nem kezdtem el átírni a régebbi munkáimat, hátha megint kijön majd egy stabil php - mysqli kombó), és egyszerűbb projektekben kerülni is fogom a használatát, mert az végképp nem hiányzik, hogy élesítéskor derüljön ki legközelebb, hogy az éles környezeten éppen nem hajlandó működni. A sima mysql-lel ilyen gonddal még sosem találkoztam.
Egyébként ha már phpmyadmin-t használ valaki fejlesztésre (lásd feljebb kéttáblás select), akkor nem mindegy, hogy mysql, vagy mysqli futtatja a végén a select-et?
-
#658
martonx
veterán
Sk8erPeter
#657
martonx
veterán
válasz
Sk8erPeter
#657
üzenetére
Szia!
Esetleg " " idézőjelek közé téve? Mintha MSSQL-ben, meg PostgreSQL-ben az " " jel lenne erre a megoldás. Bár érdemesebb inkább egybe írni, elvégre minek szivasd magad ilyen apróságokkal, nem?
-
#655
shev7
veterán
Sk8erPeter
#654
shev7
veterán
válasz
Sk8erPeter
#654
üzenetére
ezzel mas: as temptable
Igy letrehoz a memoriaban egy ideiglenes tablat, es a lekerdezest abban hajtja vegre majd az abbol kapott eredmeny alapjan update-el. Szoval itt az update es a select nem ugyanarra a tablara fut le.
-
#653
shev7
veterán
Sk8erPeter
#650
shev7
veterán
válasz
Sk8erPeter
#650
üzenetére
Hali!
Lehet valamit felreertek, de szerintem nem sok ertelme van annak amit csinalni probalsz.
SELECT kutya_id AS kutyuli_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutyuli_id
Ennek a lekerdezesnek az eredmenye minden olyan kutya_id ami benne van a tablaban. Ha erre meg mukodne is az update, akkor csak azt erned el, hogy minden sorra beallitanad a 'Y'-t nem csak azokra amikre szeretned.Amit te szeretnel, az valami ilyesmi lenne:
UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT kep_id AS ki_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutya_id
)Bar ez nem segit azon a tenyen, ahogy a hibauzenet is mondja, nem select-elheted es update-eleheted ugyanazt tablat ugyanabban a queryben.
Viszont, ha lenne egy inner temporal table-ed mar mukodne. Persze performance szempontjabol hagy kivannivalot maga utan, de ha jol sejtem ez a script egyszer futna le, szoval...
UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT *
FROM (
SELECT kep_id
FROM `tbl_ossze`
GROUP BY kutya_id
) as temptable
) -
#651
martonx
veterán
Sk8erPeter
#650
martonx
veterán
válasz
Sk8erPeter
#650
üzenetére
egy példa, hogy mire gondolok:
UPDATE FROM tblTransaction AS t
LEFT JOIN tblEmployee as e
ON e.emp_id = t.emp_id
SET t.emp_block = e.emp_block -
#649
martonx
veterán
Sk8erPeter
#648
martonx
veterán
válasz
Sk8erPeter
#648
üzenetére
Ez pedig nem tűnik rossznak. Milyen hibát kapsz vissza?
Esetleg nyelvi finomságokkal lehetne javítani pl. where és alselect helyett join, majd megadni, hogy melyik táblát update-eled? -
#615
Speeedfire
félisten
Sk8erPeter
#613
Speeedfire
félisten
válasz
Sk8erPeter
#613
üzenetére
Köszi mindkettőtöknek.
-
#587
anjani182
őstag
Sk8erPeter
#586
anjani182
őstag
válasz
Sk8erPeter
#586
üzenetére
Egyelőre úgymond, egymáson akartam importálni, exportálni...tehát volt a szűz adatbázis, ami most üres, nincs benne adat, beattacholtam a régit, volt ez a kettő, és akkor az egyiket a másikra akartam importálni, így nem ment!
Most kiexportálom egy új .mdf-be, és onnan majd megpróbálom beimportálni a másikba.
Az exportálás egy új .mdf-be most sikeres!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- Epson Expression 12000 XL Nagyformátumú A3 szkenner
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Phanteks NV5 MK2 White (PH-NV523TG DMW02)
- Telefon felváráslás!! Xiaomi 13T, Xiaomi 13T Pro, Xiaomi 14T, Xiaomi 14T Pro
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged