Új hozzászólás Aktív témák
-
PazsitZ
addikt
ha létezik egy sor a relációban, ahol az idegen kulcsban levő attribútumok valami adott értékeket vesznek fel, akkor léteznie kell a hivatkozott relációban is egy olyan sornak, ahol a hivatkozott attribútumok értékei ugyanezek.
lekérdezésben kapcsolatot idegen kulcs nélkül is létrehozhatsz.
[link]AUTO_INCREMENT
[I]To let the AUTO_INCREMENT sequence start with another value, use the following SQL statement:ALTER TABLE Persons AUTO_INCREMENT=100
[/I]
Az egynél többel növelést nem tudom még sosem próbáltam. A SQL Server esetén ír róla, alapból nem.
[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
-
PazsitZ
addikt
válasz Speeedfire #612 üzenetére
SELECT fid, COUNT(fid) FROM tabla GROUP BY fid
lassú vagyok[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
Összetett kulcs esetén nem. Esetleg alkalmazol egy PK oszlopot is és az id1, id2 oszlopokat simán UNIQUE-ra rakod.
PRIMARY(id1, id2)/ kulcs esetén lehet 100 kapcsolat is.
Arra kell figyelni, bár ez függ attól, hogy logikailag hogyan kezeled, hogy az (1,2) és (2,1) relációk szükségesek-e számodra vagy sem.
Ha csak a kapcsolat megléte számít az iránya nem, akkor ne engedd az ilyet, ha számít, akkor szerepeltetned kell mindkét "kapcsolatleírást" a friendship tábládban.[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
válasz vakondka #769 üzenetére
Elsőre ez ugrik be:
SELECT products_id, products_model, products_price, pd1.products_name, pd2.products_name, pd3.products_name
FROM products
LEFT JOIN products_description pd1 ON pd1.product_id = products.product_id AND language_id = 1
LEFT JOIN products_description pd2 ON pd2.product_id = products.product_id AND language_id = 2
LEFT JOIN products_description pd3 ON pd3.product_id = products.product_id AND language_id = 3;De biztos van szebb megoldás is, mondjuk PROCEDURE-t használva.
mod: Lemaradtam.
[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
A tába így néz ki:
users:
id name
1 Soak
2 PazsitZ
3 xyrelation (id elhagyható, akkor a elsődleges kulcs: (user, friend), egyéb esetben csak unique key):
id user friend
1 1 2
2 1 3kérdés ezzel magvan a kapcsolat vagy kellenek továbnbi mezők, nálad ezek szerint számít az irány tehát kell:
3 2 3
Ekkor mi kölcsönösen haverok vagyunk id:1. relation soka haverja PazsitZ-nek
id:3 PazsitZ haverja Soaknakid:2 itt csak Soak haverja xy-nak, de xy-n nem haverja Soaknak.
Amit írsz, hogy text/blob-ban tárolni egy user kapcsolatát, nem működőképes, nem tudsz kapcsolatot felállítani join-al, nehezen kezelhető...
- http://pazsitz.hu -
-
PazsitZ
addikt
Szimplán fel kell a select után sorolni a mezőket.
Vagy a tábla nevével prefixelve vagy aliassal.
SELECT table1.password, table2.password FROM table1 LEFT JOIN table2 ON table1.id = table2.fkidAkár még a selectált fieldeknek is adhatsz egyedi alias nevet:
SELECT t1.password AS table2_pass, t2.password AS table2_pass FROM table1 t1 LEFT JOIN table2 AS t2 ON t1.id = t2.fkid[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
válasz Speeedfire #908 üzenetére
Én meg azt mondom, hogy a yii -annak ellenére, hogy több nagy megrendelő is hajlamos használni/kérni- nem való túl nagy rendszerekhez.
Kisebb szájtokhoz viszont nagyon kényelmes, hasznos, aránylag gyors társ tud lenni. Pl. a crud-os és egyéb generált kódok, extension-ök segítségével.
Egyébként viszont rengeteg static függvénnyel, félig konfigurálható, félig viszont beégetett implentációval rendelkezik.
[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
1.
Azt tudom elképzelni, hogy id-val lett beszúrva a 16588-as id-jű sor. Így az increment érték onnan folytatódik.
Magától nem ugrál2.
Rendes indexelés tábla reláció mellett, 3 tábla összekapcsolása nem szabad, hogy gondot jelentsen.De alap esetben nézzük mit csinálhatsz.
Legyen product, category, region táblák.Lekéred az aktív product-okat.
Kapsz mondjuk 5000 rekordot. Ekkor a kategória lekérdezés WHERE IN -be sűríteni 250 id-t, a régió lekérdezésbe 2000 id-t elég fura megoldás.
Teljes kategória és régió táblalekérdezése és szerverkód általi összepárosítása megint csak fura megoldás.Kis adathalmaznál persze logikusabbnak tűnhet a WHERE IN. Viszont ilyenkor egy indexelt tábla JOIN is gyorsabb.
Speciálisabb esetekben elképzelhető, hogy optimalizálhatóak szétbontva egyes lekérdezések, de ez nem általános szvsz.
- http://pazsitz.hu -
-
PazsitZ
addikt
válasz Speeedfire #958 üzenetére
A LIMIT a leszűrt, kapott adathalmazra vonatkozik.
Így a 11, 12, 13, 18, 19 id-val ellátott sorok, amíg megjelennek LIMIT 10, 50 -nél, addig az említett 5 sor nem LIMIT 15, 50 -nél. Nem értem mi a probléma.Ha 15-ös id feletti sorokat akarsz megkapni, akkor ugye a WHERE-ben kell megadnod, az id >15 feltételt.
Ígyál egy kávét, tolj egy minesweepert és fuss neki újra
(#961) Speeedfire:
A limittel lehet játszani, csak nem azt, amire itt most szerintem gondolsz.
Egyenletes, "szünetmentes" id sor esetén lenne esetileg igaz, amire gondolsz.De ha bővebben kifejted, mi a cél lehet többet tudunk segíteni.
[ Szerkesztve ]
- http://pazsitz.hu -
-
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...[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
Jobban megnézve tévedtem. A TYPE helyett ENGINE kell, ez volt a hiba.
Azt meg nem is tudtam, hogy így lehet auto increment-et inicializálni.CREATE TABLE `members` (
`id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
`username` VARCHAR( 65 ) NOT NULL DEFAULT '',
`password` VARCHAR( 65 ) NOT NULL DEFAULT '',
PRIMARY KEY ( `id` )
) ENGINE = MYISAM AUTO_INCREMENT = 2;[ Szerkesztve ]
- http://pazsitz.hu -
-
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?- http://pazsitz.hu -
-
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.
- http://pazsitz.hu -
-
-
PazsitZ
addikt
Egy mysql hibának kellett volna.
A GROUP BY a WHERE után következik [link]
FROM ... WHERE ... GROUP BY ... ORDER BY ... LIMIT ...;SELECT `id`, `gametypeid`,MIN(`packetid`) AS `packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE `date_start` <= $currtime AND `date_end` >= $currtime
GROUP BY `gametypeid`
ORDER BY `id` DESC
LIMIT 4;U.i.: meg most nézem a group by mögött benne maradt még egy pontosvessző is a query-ben.
[ Szerkesztve ]
- http://pazsitz.hu -
-
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.
- http://pazsitz.hu -
-
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.[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
Mondjuk:
SELECT COUNT(*) FROM table WHERE code = 'code_to_find'
Így megkapod, hogy hány darab ilyen kód van. Ha a kód unique, 0 vagy 1 lesz az eredmény.Vagy lekérdezed:
SELECT code, name FROM table WHERE code = 'code_to_find'
Majd szerver oldalon megnézed a query hány eredményt adott.Más konkrét parancs nem jut eszembe ehhez.
- http://pazsitz.hu -
-
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.- http://pazsitz.hu -
-
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"?
[ Szerkesztve ]
- http://pazsitz.hu -
-
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.[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
válasz Babetta-X #1085 üzenetére
Nem teljesen ertem mi a gond. Tokeletesen leirtak, h nincs kulon felulet a db-hez. Tehat vagy egy script-el mented le vagy feltelepitesz mondjuk egy phpmyadmint.
Az elerhetoseget magad irtad le. phpmyadmin configban ugyanazokat a db konfig adatokat kell megadnod, mint amit eddig is hasznaltal.- http://pazsitz.hu -
-
PazsitZ
addikt
válasz Apollo17hu #1496 üzenetére
Ha kevés field van akkor végül is mehwet a union is. De szvsz én akkor már nem join-olgatnék subquery-t.
(SELECT id , val1 FROM sample WHERE val1 IS NOT NULL AND val1<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val2 FROM sample WHERE val2 IS NOT NULL AND val2<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val3 FROM sample WHERE val3 IS NOT NULL AND val3<>'' ORDER BY id DESC LIMIT 1)result:
4 ló
5 3
5 12345- http://pazsitz.hu -
Új hozzászólás Aktív témák
- AKCIÓ Új Dobozos Macbook Pro dokkoló új ára 70.000 forint
- ThinkPad Hybrid USB -C USB -A Dock 40AF Új ára 80.000 Forint Ingyen szállítás
- Xiaomi Redmi Note 9s 128/6 GB 34.9E !!!
- Új Hp Pavilion 15-eh Fémházas Szuper Laptop 15,6" -30% AMD Ryzen 7 5700U 8Mag 16/1TB FHD MATT
- ATI RADEON RX 480 -8 gb DDR5 256 bit videokártya