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

• #1270 Jester01 veterán martonx #1269

  Új Válasz 2013-05-30 02:23:34 #1270

  Ú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

  

  Jester01

  veterán

  válasz martonx #1269 üzenetére

  Azt kétlem, hogy egyetlen BIT mező tárolásához ne foglalna le legalább egy byteot. Esetleg ha több ilyen mező van egy rekordban akkor összepakolhatja őket.

  Alap b-tree indexben meg aztán pont nem számít a mérete, ott ugye a sor azonosító számít.

• #712 Jester01 veterán Norb37 #711

  Új Válasz 2011-09-16 19:26:33 #712

  Ú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

  

  Jester01

  veterán

  válasz Norb37 #711 üzenetére

  Oprendszered nyilván már van, nem? Hogy melyik partíción az totál mindegy az a lényeg, hogy fusson mind az oprendszer mind pedig a mysql.

• #710 Jester01 veterán Norb37 #709

  Új Válasz 2011-09-16 19:06:33 #710

  Ú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

  

  Jester01

  veterán

  válasz Norb37 #709 üzenetére

  Egyszerűen felrakod a D-re a mysql-t. A kliens pediglen hálózaton vagy pipe-on keresztül kapcsolódik majd a futó adatbázis szerverhez (ezt a kliensben kell beállítani). Vagyis nem a fájlokhoz fér hozzá. Tök mindegy milyen meghajtón vannak, mert a mysql szerver szolgáltatásnak kell futnia.

  Ha el akarod különíteni a mysql szervert és az adat fájlokat is, akkor ezt a mysql-nek kell beállítani. Windowson nem tudom hogy megy ez (gondolom kattintani kell valahol ), linuxon a my.cnf-ben van egy datadir változó.

• #705 Jester01 veterán sonar #701

  Új Válasz 2011-09-12 13:42:23 #705

  Ú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

  

  Jester01

  veterán

  válasz sonar #701 üzenetére

  Ugye a curdate()-t nem tetted aposztrófok közé?

  SELECT * FROM tdc_lc_lot_info where order_no like 'TDC%' and Create_Time < date_sub (curdate(),interval 10 DAY);

  -vagy-

  SELECT * FROM tdc_lc_lot_info where order_no like 'TDC%' and DATEDIFF(curdate(), Create_Time) > 10;

• #596 Jester01 veterán sonar #595

  Új Válasz 2010-09-27 16:59:40 #596

  Ú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

  

  Jester01

  veterán

  válasz sonar #595 üzenetére

  wireshark

• #590 Jester01 veterán anjani182 #589

  Új Válasz 2009-11-25 18:14:36 #590

  Ú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

  

  Jester01

  veterán

  válasz anjani182 #589 üzenetére

  De a számlázó progi az ugyanaz a verzió mint eddig? Mert ha nem, és más formátumot használ akkor hiába próbálod a régi adatbázist használni. Ha viszont egyezik, akkor a normál esetben használt adatbázis helyére attacholva (vagy átnevezve) mennie kellene.

• #588 Jester01 veterán anjani182 #587

  Új Válasz 2009-11-25 18:03:28 #588

  Ú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

  

  Jester01

  veterán

  válasz anjani182 #587 üzenetére

  De miért nem attacholod egyből az új helyére?

• #581 Jester01 veterán anjani182 #580

  Új Válasz 2009-11-24 17:43:27 #581

  Ú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

  

  Jester01

  veterán

  válasz anjani182 #580 üzenetére

  Ha megvannak az mdf fájlok egyszerűen attach-olni kell. Lásd pl itt

• #578 Jester01 veterán Bazsesz #577

  Új Válasz 2009-11-11 22:36:01 #578

  Ú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

  

  Jester01

  veterán

  válasz Bazsesz #577 üzenetére

  SUBSTRING(SORBA, 6, 1)

• #533 Jester01 veterán Drizzt #532

  Új Válasz 2009-02-06 16:57:46 #533

  Ú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

  

  Jester01

  veterán

  válasz Drizzt #532 üzenetére

  UPDATE eredeti SET cimid = (SELECT cimid FROM cim WHERE cim.cim = eredeti.cim);

• #411 Jester01 veterán alitak #410

  Új Válasz 2007-10-30 16:59:32 #411

  Ú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

  

  Jester01

  veterán

  válasz alitak #410 üzenetére

  Én ezt csak beágyazott select-tel tudtam megcsinálni, ilyesképp:

  select * from t where k in (5, (select max(k) from t where k < 5), (select min(k) from t where k > 5));

• #368 Jester01 veterán zeix #367

  Új Válasz 2007-06-14 17:23:20 #368

  Ú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

  

  Jester01

  veterán

  válasz zeix #367 üzenetére

  Kiszűrni = lekérdezni?
  SELECT f1, f2, ... FROM t GROUP BY f1, f2, ... HAVING COUNT(*) > 1
  
  ahol f1, f2, ... az egyediséget jellemző mezők, t értelemszerűen a tábla neve.

• #366 Jester01 veterán VladimirR #365

  Új Válasz 2007-06-07 16:59:00 #366

  Ú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

  

  Jester01

  veterán

  válasz VladimirR #365 üzenetére

  A mező collation legyen BINARY. Ha ez még mindig nem elég, akkor add be hexában.
  
  mysql> create table t(hash char(20) BINARY);
  Query OK, 0 rows affected (0.01 sec)
  
  mysql> insert into t values (0xC3A9);
  Query OK, 1 row affected (0.00 sec)
  
  mysql> select hex(hash) from t;
  +-----------+
  | hex(hash) |
  +-----------+
  | C3A9 |
  +-----------+
  1 row in set (0.00 sec)
  

• #354 Jester01 veterán Protezis #353

  Új Válasz 2007-04-10 18:56:21 #354

  Ú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

  

  Jester01

  veterán

  válasz Protezis #353 üzenetére

  Én legalábbis nem tudok. Megfelelő indexeket rá és kész.

• #352 Jester01 veterán Protezis #351

  Új Válasz 2007-04-10 18:33:46 #352

  Ú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

  

  Jester01

  veterán

  válasz Protezis #351 üzenetére

  Ránézésre az IN-es verziót nem használnám. A másik kettő meg ekvivalens.

• #331 Jester01 veterán emitter #330

  Új Válasz 2007-01-21 23:57:21 #331

  Ú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

  

  Jester01

  veterán

  válasz emitter #330 üzenetére

  Nem valami alias, függvény vagy script az a mysqld amit indítasz?

• #319 Jester01 veterán VladimirR #318

  Új Válasz 2006-12-12 03:39:11 #319

  Ú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

  

  Jester01

  veterán

  válasz VladimirR #318 üzenetére

  A biztosabbat úgy értettem, hogy így csak kisebb mértékben bízod a query optimizer-re a döntést. A két egyszerû lekérdezésnél (RedAnt javaslatával) valószínû, hogy 2 index lookup lesz az egész. Elvileg az optimizer is ezt adja és úgy megtakaríthatsz egy parancsfeldolgozást. Persze csak ha bízol benne
  
  Ami a varchar-t illeti valóban igazad van. Mondjuk egy ilyen utalást találtam azért a leírásban: ''Remember that MySQL may treat VARCHAR columns as if they're CHAR columns, in which case the fixed format is used.'' De fogalmam sincs mire céloz.

• #314 Jester01 veterán VladimirR #311

  Új Válasz 2006-12-11 15:06:52 #314

  Ú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

  

  Jester01

  veterán

  válasz VladimirR #311 üzenetére

  egy up a kesonkeloknek
  
  
  mi a kulonbseg a varchar es a text adattipuxok kozott
  
  varchar -nak a rekordban van foglalva hely (a maximális hossznak), text esetén csak a hossza és egy pointer van eltárolva. Ez utóbbi egy külön területre mutat. A text ezért lassabb, de kevesebb helyet foglal.
  
  mi az az index prefix length
  
  Az index csak ennyi karaktert használ. Az olyan értékeket amik ezen hosszig megegyeznek azonosnak tekinti. A lekérdezéskor a látszólag egyező értékekre még egy szűrés fut.
  
  mi a kulonbseg szoveges (varchar, text) mezo eseteben a sima index es a fulltext index kozott?
  
  Fulltext indexben mindenféle vicces módon lehet keresni (MATCH ... AGAINST), sima indexben csak összehasonlítás van (kisebb-nagyobb-egyenlő).
  
  hogy jobb index-et kesziteni? melyiknek mik az elonyei, hatranyai?
  -a) alter table tablanev add index ( mezo1, mezo2 );
  -b) alter table tablanev add index ( mezo1 ).|. table tablanev add index ( mezo2 );
  
  Ez a két eset nem ekvivalens. Az első esetben mezo2-re nincs index (ha az adott adatbáziskezelő jobbról használja az összetett indexeket - ellenkező esetben mezo1-re nem lesz index). Ha mindig mind a két mezőre van szűrés, akkor az első módszer jobb lesz. Ha viszont a két mezőre külön-külön is akarsz keresni akkor a másodikra van szükséged. Plusz ha UNIQUE feltételed is van, akkor az első esetben a (mezo1, mezo2) pároknak kell egyedinek lenni, míg a másodikban a mezo1 és mezo2 értékeknek külön-külön.
  
  MOD: szóval az összetett indexet (az adatbáziskezelőtől függően jobbról vagy balról) tetszőleges hosszig lehet használni. Pl. a (mezo1, mezo2, mezo3) indexet lehet (mezo1), (mezo1, mezo2), (mezo1, mezo2, mezo3) indexként is használni.
  
  ha van ket tablam van-e kulonbseg sebessegben, memoriahasznalatban az alabbi ketto kozott:
  
  Ránézésre nincs (feltéve, hogy van index mind a 2 lekérdezéshez). De az első a biztosabb.
  
  Ha valahol hülyeséget írtam, javítsatok ki
  
  [Szerkesztve]
  
  [Szerkesztve]

• #310 Jester01 veterán Haok #309

  Új Válasz 2006-11-26 21:19:09 #310

  Ú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

  

  Jester01

  veterán

  válasz Haok #309 üzenetére

  mysql> CREATE TABLE ME
  -> (
  -> ID INTEGER NOT NULL,
  -> NEV VARCHAR(10) NOT NULL
  -> );
  Query OK, 0 rows affected (0.03 sec)
  
  mysql> CREATE TABLE TERMCSOP
  -> (
  -> ID INTEGER NOT NULL,
  -> NEV VARCHAR(20) NOT NULL,
  -> SZULO INTEGER
  -> );
  Query OK, 0 rows affected (0.00 sec)
  

• #308 Jester01 veterán Haok #307

  Új Válasz 2006-11-26 17:44:12 #308

  Ú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

  

  Jester01

  veterán

  válasz Haok #307 üzenetére

  Ez Oracle szintaxisnak tûnik, mysqlben simán varchar(10) formában lesz jó.
  

• #306 Jester01 veterán VladimirR #305

  Új Válasz 2006-10-23 02:33:45 #306

  Ú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

  

  Jester01

  veterán

  válasz VladimirR #305 üzenetére

  delete from posts where topicid not in (<halmaz>)
  Szerintem semmi baj nincs ezzel a megoldással. Gondolom a <halmaz> egy al-select, jelen esetben tehát valami ilyesmi lesz a parancs:
  delete from posts where topicid not in (select topicid from topics)
  Alternatív módszer:
  delete from posts where not exists (select * from topics where topics.topicid = posts.topicid)
  Az explain parancs által adott infók alapján nekem úgy tûnik, hogy az elsõ a gyorsabb. Ha van index a topics.topic_id mezõre, akkor azt mind a két verzió kihasználja.

• #293 Jester01 veterán _Petya_ #292

  Új Válasz 2006-09-28 15:46:05 #293

  Ú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

  

  Jester01

  veterán

  válasz _Petya_ #292 üzenetére

  Foreign key arra jó, hogy eleve a táblaszerkezet leírásában rögzíted a viszonyt. Ekkor az adatbáziskezelő ezt ellenőrizni fogja és nem enged olyan módosításokat amelyek ezt a szabályt megsértenék. De lekérdezéskor ettől függetlenül a L3zl13 által mutatott join-t kell alkalmazni.

• #290 Jester01 veterán L3zl13 #289

  Új Válasz 2006-09-28 15:11:26 #290

  Ú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

  

  Jester01

  veterán

  válasz L3zl13 #289 üzenetére

  Elírtad, fordítva
  

• #255 Jester01 veterán vakondka #254

  Új Válasz 2006-08-22 15:24:20 #255

  Ú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

  

  Jester01

  veterán

  válasz vakondka #254 üzenetére

  A t1 és a t2 csak két tetszőleges alias név a tábláknak, mivel önmagával joinolva nem tudnánk másképp megkülönböztetni őket.

• #253 Jester01 veterán vakondka #252

  Új Válasz 2006-08-21 21:20:02 #253

  Ú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

  

  Jester01

  veterán

  válasz vakondka #252 üzenetére

  Jah, most meg fordítva van (azokat listázta amik angolul vannak csak)
  A 4est és az 1est cseréld meg.
  
  select count(*) from products_description t1 left join products_description t2 on t1.products_id = t2.products_id and t2.language_id = 1 where t1.language_id = 4 and t2.language_id is null;
  +----------+
  | count(*) |
  +----------+
  | 1618 |
  +----------+
  

• #251 Jester01 veterán vakondka #250

  Új Válasz 2006-08-21 19:45:51 #251

  Ú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

  

  Jester01

  veterán

  válasz vakondka #250 üzenetére

  Itt a javított verzió, most van mysqlem ki is tudtam próbálni:
  
  select t1.products_id, t1.language_id from products_description t1 left join products_description t2 on t1.products_id = t2.products_id and t2.language_id = 4 where t1.language_id = 1 and t2.language_id is null
  
  (A t1.language_id = 1 feltétel a join helyett a where részbe kell.)

• #247 Jester01 veterán vakondka #246

  Új Válasz 2006-08-19 15:50:01 #247

  Ú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

  

  Jester01

  veterán

  válasz vakondka #246 üzenetére

  Pl. saját magával összejoinolod a táblát, vhogy így:
  
  select t1.products_id, t1.language_id from products_description t1 left join products_description t2 on t1.products_id = t2.products_id and t2.language_id = 4 and t1.language_id = 1 where t2.language_id is null
  
  Most éppen nem jutok be mysqles gépre de talán jó

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