Új hozzászólás Aktív témák

• #1732 bpx őstag don_peter #1731

  Új Válasz 2015-06-02 12:38:56 #1732

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz don_peter #1731 üzenetére

  Feltételeztem, hogy olyan eset nem fordul elő, hogy egy fórum üzenethez nem létezik user (mert usert általában nem törlünk, csak inaktiválunk), és így nem kell ezek közé is outer join, de egyébként igen.

  Ezen kívül, ha van rá igény, azt kellene még megcsinálni, hogy a topikonként a legújabb hozzászólás dátumát és felhasználóját helyesen összegyűjteni, mert egy ilyen GROUP BY-t egy szigorúbb adatbáziskezelő (pl. DB2, MSSQL, Oracle) kapásból visszadob hibával, mert nem determinisztikus az eredmény. (Azt, hogy a MySQL egyáltalán megenged ilyet, én inkább hiányosságnak tartom, mint feature-nek - OK, kikapcsolható ez a működés.)

  MySQL-ben sajnos nincsenek analitikus függvények, helyette vannak ilyen kerülő megoldások:

  [link]

  Végül limitálni kellene, hogy hány sort kapunk vissza, hogy ne dolgozzon esetleg feleslegesen az adatbázis, és gondolom a felhasználónak sem a létező összes, akár több száz, ezer topikot rakod ki felületre, hanem csak egy fix mennyiséget, ahogy pl. itt a prohardveren is működik.

• #1730 bpx őstag don_peter #1729

  Új Válasz 2015-06-02 11:08:29 #1730

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz don_peter #1729 üzenetére

  Ha azok a topikok kellenek, amelyekben nincs hozzászólás, akkor miért a forum_uzenetek van a LEFT JOIN bal oldalán?

  forum_uzenetek fu
  LEFT JOIN topik t
  ON fu.topik_id = t.id

  Ez azt jelenti, hogy azokat fórum üzeneteket is kéred, amelyek egyik topikhoz sem tartoznak.

  forum_uzenetek LEFT JOIN topik + UNION bonyolítás helyett nem egyszerűbb lenne a topik LEFT JOIN forum_uzenetek?

• #1596 bpx őstag hati #1595

  Új Válasz 2015-01-05 12:17:13 #1596

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz hati #1595 üzenetére

  A 4 darab \-ből LIKE-nál 1 darab \ lesz, mert duplán escape-el.

  [link]

  Because MySQL uses C escape syntax in strings (for example, “\n” to represent a newline character), you must double any “\” that you use in LIKE strings. For example, to search for “\n”, specify it as “\\n”. To search for “\”, specify it as “\\\\”; this is because the backslashes are stripped once by the parser and again when the pattern match is made, leaving a single backslash to be matched against.

• #1480 bpx őstag bbTamas77 #1479

  Új Válasz 2013-10-30 15:29:37 #1480

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz bbTamas77 #1479 üzenetére

  select név, mértékegység, max(adat), count(*) from tábla group by név, mértékegység;

• #1385 bpx őstag Speeedfire #1384

  Új Válasz 2013-08-08 11:13:01 #1385

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz Speeedfire #1384 üzenetére

  [link]

• #1377 bpx őstag szmegma #1360

  Új Válasz 2013-08-01 13:47:51 #1377

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz szmegma #1360 üzenetére

  az a baj a mysqllel, hogy nincs benne egyszeru "generator" funkcio, mert egyebkent ez a feladat pl. arra is lefordithato, hogy generaljunk szamokat 1-31-ig es adjunk hozza ennyi napot a mostani datumhoz, ami tisztan SQL lenne

  de rekurziv lekerdezessel megoldhato, csak kell egy olyan forras, amelynek legalabb 31 sora van
  peldaul select SQL megoldas:

  select date_add(CURDATE(), interval o.num day) from
  (select @n := @n + 1 as num
  from information_schema.columns, (select @n := 0) n
  limit 31) o;

  ezzel persze az a baj, hogy mindig az information_schema.columns-hoz (vagy amire epp meg van irva) kell nyulni + akar el is lehetne tarolni a szamokat 1-31-ig egy kulon tablaban (es nem kell feltalalni ujra a kereket naptar tablaval):

  create table numbers (n int);

  insert into numbers
  select @n := @n + 1 as num
  from information_schema.columns, (select @n := 0) n
  limit 31;
  
  select date_add(CURDATE(), interval n.n day) from numbers n;

  csak hat ez meg megint ronda (szerintem)

  szemlelteteskeppen, Oracle-ben ez ennyi:

  select sysdate + level from dual connect by level <= 31;

  a dual tabla sajatossagai miatt ez raadasul sem diszkrol, sem a cache-bol nem olvas, nem kell PL/SQL-ezni meg context switch sincs

• #1345 bpx őstag bbTamas77 #1344

  Új Válasz 2013-07-27 23:38:54 #1345

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz bbTamas77 #1344 üzenetére

  a beosztas_addatum sorara panaszkodik, az elozo sor vegen hianyzik a vesszo

• #1262 bpx őstag spammer #1261

  Új Válasz 2013-05-25 18:48:45 #1262

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz spammer #1261 üzenetére

  jol elhalmoztal minket informacioval...

  de egyebkent ha ez peldaul egy varchar not null oszlop, akkor siman mondhat ilyet ha mar vannak sorok a tablaban

• #1243 bpx őstag spammer #1240

  Új Válasz 2013-05-21 19:11:09 #1243

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz spammer #1240 üzenetére

  nincs ra shortcut

  ettol persze meg lehetseges megvalositani (pl. ezek hasznalataval [link], lekerdezed az oszlopok neveit, osszeallitod belole a SELECT szoveget, majd EXECUTE), de ha csak a kenyelem miatt szeretned es ismered az oszlopokat, akkor NE

• #1239 bpx őstag spammer #1236

  Új Válasz 2013-05-21 18:44:50 #1239

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz spammer #1236 üzenetére

  na akkor tisztazzuk mit szeretnel

  egy adott tablarol megtudni, hogy milyen "color_" kezdetu oszlopai vannak (es semmi adatot)?

  ebben az esetben:

  SELECT column_name, data_type
  FROM information_schema.columns
  WHERE table_name='colors'
  AND column_name LIKE 'color_%';

  (a _ karaktert szerintem escape-elni kell ha biztosra akarsz menni, mert a LIKE-ban az pontosan 1 darab akarmilyen karaktert jelenthet, tehat a fenti minta illik arra is pl., hogy "color1")

  vagy pedig magat a lekerdezest szeretned eloallitani? tehat nem tudod elore, hogy a tablanak milyen color oszlopai vannak, de szeretned azoknak a tartalmat lekerdezni
  ez esetben dinamikus SQL kell

Új hozzászólás Aktív témák