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

• pittbaba aktív tag

  #1600

  #1599 Sk8erPeter

  2013-02-08 18:20:47

  Új Válasz

  Ú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

  

  pittbaba

  aktív tag

  #1599 Sk8erPeter

  Látatlanban? Ott van minden már, épphogy az adatbázist nem csatoltam
  Indexelni melyik táblákat érdemes? Egyelőre csak a stop_times.stop_id-t, és a stops.stop_name -t indexeltem. Explain-t nem vágom, guglizom, nézem, de jöhet tipp!

• Sk8erPeter nagyúr

  #1599

  #1596 pittbaba

  2013-02-08 18:15:37

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1596 pittbaba

  látatlanban: indexelés, EXPLAIN?

  Szerk.: ja, most látom, hogy írtad is (csak átfutottam a kérdéseden):
  "Olvastam, hogy létre lehet hozni index-et a tábla oszlopaihoz, milyen oszlopokhoz érdemes?"
  legalább próbálkozz egy EXPLAIN-nel. Na de konkrétabbat majd ha esetleg kipróbáltam (és elolvastam normálisan a kérdésedet ), meg ha addig nem érkezik másik válasz.

• pista1235 tag

  #1598

  #1597 pista1235

  2013-02-08 17:53:13

  Új Válasz

  Ú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

  

  pista1235

  tag

  #1597 pista1235

  azaz én visszafele szeretnék keresni, hogy adott elem egy táblán belül hol található. ezt megoldható valahogy?

• pista1235 tag

  #1597 2013-02-08 17:46:48

  Új Válasz

  Ú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

  

  pista1235

  tag

  sziasztok! tudnátok segíteni abban, hogy egy mysql adatbázisban milyen paranccsal tudom azt megoldani, hogy ha beírok egy elemet, akkor kiírja hogy az az adatbázis melyik oszlopában található? előre is köszönöm a segítséget!

• pittbaba aktív tag

  #1596

  #1595 modder

  2013-02-08 17:06:31

  Új Válasz

  Ú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

  

  pittbaba

  aktív tag

  #1595 modder

  Itt a BKK GTFS db, csak hogy ne kelljen keresgélni:
  [link]

  Példák:
  stops:
  stop_id,stop_name,stop_lat,stop_lon,location_type,parent_station,wheelchair_boarding
  F00001,"Mihály utca",47.486079,19.034561,,,2

  stop_times:
  trip_id,arrival_time,departure_time,stop_id,stop_sequence,shape_dist_traveled
  A651191,03:46:00,03:46:00,F04679,010,0

  trips:
  _id,service_id,trip_id,trip_headsign,direction_id,block_id,shape_id,wheelchair_accessible,trips_bkk_ref
  6100,A65119ASZGPP-021,A651191,"Örs vezér tere M+H",1,A65119ASZGPP-021_10A,1226,2,61001

  A gps koordináta kerekítés elve megvan, de mivel az szerintem még lassabb lesz, egyelőre megálló névre keresek rá:

  SELECT stop_name,stops._id,stop_times._id,trips._id FROM "+MYDATABASE_TABLE+" JOIN stop_times ON stops.stop_id= stop_times.stop_id JOIN trips ON stop_times.trip_id = trips.trip_id WHERE stops.stop_name LIKE '%"+searchstr[0]+"%' GROUP BY stop_times.stop_id"

  Ha azt kérem: Deák tér, meg is kapom vissza, szóval megleli, de kb 10 perc alatt, mert a stop_times tábla nagyon nagy és végig kell nyálazza. Olvastam, hogy létre lehet hozni index-et a tábla oszlopaihoz, milyen oszlopokhoz érdemes? Ez után az eredeti lekérdezést kell használni továbbra is, csak az adatbázison gyorsít valamennyit?

  Nem tudtam jól megfogalmazni a módosítással mit akartam mondani. A lényeg, hogy lenne olyan megoldás is, hogy a három táblából csinálok egy leegyszerűsítettet, melyik GPS koordinátákhoz mely járatok tartoznak, viszont mivel az alapformátum CSV és a célformátum mysqlite db fájl, nehéz olyan scriptet írni ilyen sok sorú fájlnál, ami nekem ezeket összemergeli egy táblába logikusan. A kész db táblákból csinálni egy újat is lassú, mert ugyanúgy soronként kell haladni.

  UI: A GPS koordináták kerekített lekérdezését így oldom meg, hogy legyen hibahatár:
  SELECT * FROM "+MYDATABASE_TABLE+" WHERE ( stop_lat > '"+latstart+"' AND stop_lat < '"+latend+"' ) AND (stop_lon > '"+lonstart+"' AND stop_lon < '"+lonend+"')

  Egyszerű, működik, de gondolom bazi lassú lesz :S

• modder aktív tag

  #1595

  #1594 pittbaba

  2013-02-08 16:49:51

  Új Válasz

  Ú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

  

  modder

  aktív tag

  #1594 pittbaba

  érdekes probléma, és ebből nem tudjuk meg, hogy miért lassú.

  Azt mondod gps koordináták alapján akarod kiszedni, hogy melyik megállóban áll. Be tudnád írni a pontos lekérdezést, és egy-egy sor példát a három táblából? Feltételezemm, hogy a telefon nem pont ugyanazt a gps koordinátát fogja visszaadni, amit a táblában tárolsz, tehát ilyen kisebb-nagyobb összehasonlításokat végzel, ami elég költséges lehet.

  Plusz nem értem, hogy miért nehéz bármit is változtatni az eredeti formátumon. Gondolom úgy működik, hogy az ember wifi közelben updateli az adatbázist, ekkor akármilyen transzformációt csinálhatsz rajta, majd úgy mented el az SQLite adatbázsiban, ahogy akarod. Keresésénél kell gyorsan működnie, nem updatenél

• pittbaba aktív tag

  #1594 2013-02-08 16:24:17

  Új Válasz

  Ú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

  

  pittbaba

  aktív tag

  Sziasztok!

  Androidra fejlesztek BKV programot, ennek az adatbázisához kellene finomításhoz segítség, tipp nekem.
  A BKV kiadja a teljes menetrendet a Google GTFS adatbázis formátumban.
  Ebből készítek egy programmal egy SQLite adatbázisfájlt, amit az alkalmazás felhasznál az adatok kivételére.
  Ez egy 159Mb-os adatbázis file, egy telefonnak elég leterhelő, sajnos egy lekérdezés több perc jelenleg.

  Gps koordináták alapján próbálom kiszedni a user melyik megállóban áll, és milyen járatok haladnak át azon a megállón.
  Három táblát kell ehhez felhasználnom:
  stops táblában vannak a megálló nevei és a GPS koordináták
  stop_times táblában az időpontok vannak megadva, melyik percben melyik megállóban melyik járat megy(id)
  trips táblában vannak a trip id-hoz tartozó nevek.

  Egyértelmű, hogy a stop_times tábla nagyon nagy, úgy emlékszem, hogy 200 000 sor körül van, e miatt nagyon lassú lesz a lekérdezésem. JOIN-al összekapcsoltam a három táblát, az eredmény több perc után, de megérkezik helyesen egyébként.

  Hogy lehetne gyorsítani a lekérdezést?
  Az adatbázis feldarabolása nem jó, mert megállókra lehetne szétbontani, de az is 4000 fájlt jelentene, ami megint nem megoldás.

  Mivel létre kell hozni egy külön SQLite adatbázis fájlt, nehéz bármit is változtatni az eredeti formátumon, mivel a GTFS fájlok sima CSV formátumú fájlok, nem könnyű dolgozni velük.

  Milyen tippekkel tudtok segíteni?

• Ablakos addikt

  #1593

  #1592 rum-cajsz

  2013-02-06 16:22:45

  Új Válasz

  Ú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

  

  Ablakos

  addikt

  #1592 rum-cajsz

  Igen, így van. Neked

• rum-cajsz őstag

  #1592

  #1590 Ablakos

  2013-02-06 15:54:12

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1590 Ablakos

  Házi feladat: Hogy nézne ki mindez outer joinnal?
  Na úgy már jóval olvashatóbb a szabvány szerinte szerintem.

• sztanozs veterán

  #1591

  #1590 Ablakos

  2013-02-06 15:52:23

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1590 Ablakos

  Csak ugye, ha a több-join-os táblán van még egy rakat where feltétel, akkor mindjárt könnyeben olvasható az első rész, ahol a join "feltételek" és a query feltételek szépen elkülönülnek egymástól.

• Ablakos addikt

  #1590

  #1589 rum-cajsz

  2013-02-06 15:42:59

  Új Válasz

  Ú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

  

  Ablakos

  addikt

  #1589 rum-cajsz

  Meg szemmel elolvasni is mennyivel kulturáltabb az utobbi. De lehet csak szokatlan a vénebbeknek a modern írás.

• rum-cajsz őstag

  #1589

  #1588 Apollo17hu

  2013-02-06 15:40:36

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1588 Apollo17hu

  Ez az SQL szabvány szerinti, de csak az Oracle esetén új, más adatbáziskezelőkben ez volt a megszokott
  from egytabla t1
  join kettotabla t2 on t1.id = t2.id
  join haromtabla t3 on t1.id = t3.id

  Ez a leegyszerűsített, az Oracle optimalizáló állítólag ezt jobban szereti:
  from haromtabla t3, kettotabla t2, egytabla t1
  where t3.id = t1.id
  and t2.id = t1.id

  Mellesleg az új Oracle esetén azt jelenti, hogy kb. 10-12 éve került bele....

• Apollo17hu őstag

  #1588 2013-02-06 15:33:19

  Új Válasz

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Erre a régi meg új szintaktikára tudnátok egy-egy nagyon rövid példát írni? Miben jobb az új és miért? Van előnye a régi használatának? Köszi!

• martonx veterán

  #1587

  #1586 rum-cajsz

  2013-02-06 11:11:30

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1586 rum-cajsz

  Ezért is hangsúlyoztam mindenhol, hogy az Oracle-el felületesek (mondjuk azok nem túl pozitívak) az ismereteim, és egy szinte ismeretlen rendszerről nem volna etikus véleményt mondanom. Pláne, hogy történelmi okok miatt máig a legelterjedtebb db, annyira nem lehet rossz.
  Őszintén én is bármit el tudok képzelni az Oracle db motor működéséről, de mivel az Oracle-höz bevallottan nem igazán értek, és db motor flame-be se akarok belemenni, maradjunk abban, hogy Oracle esetén akár igaz is lehet, hogy biztos ami biztos alapon érdemes a régi join szintaktikát használni.

• rum-cajsz őstag

  #1586

  #1585 martonx

  2013-02-06 10:26:36

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1585 martonx

  Ó, én az Oracle optimalizáló fejlesztőiből bármit ki tudok nézni, annyi minden "faszsággal" érthetetlen dologgal találkoztam már. Ebbe belefér az is, hogy a joint rosszul (értsd: nagyobb költséggel) értelmezi egyik illetve másik esetben.
  De lehet, hogy csak a rosszindulat beszél belőlem, és mostanra már tényleg szép és jó az Oracle join szintaxisokkal.

• martonx veterán

  #1585

  #1584 rum-cajsz

  2013-02-06 09:50:59

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1584 rum-cajsz

  MS SQL optimalizációit ismerve nagyon nem mindegy, hogy az sql motornak néhány soros (hangsúlyozom néhány), vagy ennél több, mondjuk pár százezer adattal kell dolgoznia. De hogy 100.000 vagy 100.000.000 az már édesmindegy. Klasszikus optimalizálási hiba tud lenni, hogy pár sornyi teszt adatokkal az sql-t beoptimalizálja a motor, majd amikor mindezt ráengeded 100.000-re akkor csodálkozol, hogy miért lassú.
  De hogy jön ez a join-olás régi vagy új szintaktikájához? Nehogy már a használt join szintaktika határozza meg az sql motor optimalizálását.

• rum-cajsz őstag

  #1584

  #1583 martonx

  2013-02-06 08:34:49

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1583 martonx

  Nyilván az optimalizáló miatt. Amíg pár százezer soros adatokat dolgozik fel biztos mindegy, a pár milliónál már érdekes lehet.

• martonx veterán

  #1583

  #1582 rum-cajsz

  2013-02-06 08:29:07

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1582 rum-cajsz

  hehe, ezen tényleg csak nevetni lehet.
  Mondjuk ezt többször is hangoztattam, hogy leginkább MS SQL, PostgreSQL vonalon mozgok, néha egy kis MySQL-el, Oracle-el fűszerezve. Azért megkérdezném azt az oktatót, hogy mire alapozza amit mond (évtizedes berögzülés nem számít, illetve az Oracle 9i-re hivatkozást sem fogadom el érvként), és ugyan mutasson már egy példát.

• rum-cajsz őstag

  #1582

  #1578 martonx

  2013-02-05 22:32:50

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1578 martonx

  haha,
  Nem tudom melyik adatbázisra gondoltál, de hivatalos Oracle oktatáson mégis elhangzott (a tapasztalt Oracle szakértő szájából), hogy szép-szép az új join szintaktika, de ha biztosra akarunk menni akkor használjuk a régi módszert....

• Vision veterán

  #1581

  #1580 martonx

  2013-02-05 20:27:41

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1580 martonx

  Nálam is félreérthető volt, de ugyanarra gondoltunk.

• martonx veterán

  #1580

  #1579 Vision

  2013-02-05 20:06:22

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1579 Vision

  bocsánat, nem fogalmaztam pontosan, természetesen a join-ban használt alselectre gondoltam, azt hittem ez a szövegből egyértelműen kiderül. De ezek szerint nem. Senkit nem szeretnék félrevezetni!
  Szóval az egyértelműség kedvéért: A select-be ágyazott alselect a legrosszabb megoldás (még ha gyarkan az engine ki is tudja optimalizálni, de erre ne építsünk!). A join-ba ágyazott alselect viszont nagyon hasznos tud lenni.

• Vision veterán

  #1579

  #1578 martonx

  2013-02-05 19:29:05

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1578 martonx

  Nálam az alselectek sokkal több erőforrást elvittek, mint a join-ok. Esetleg úgy lehet egyszerűsíteni, hogy a join jobb oldalán egy alselect van. Így sokszor lehet a 3-ból 2-t csinálni.

• martonx veterán

  #1578

  #1577 Jim-Y

  2013-02-05 15:20:02

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1577 Jim-Y

  2013-ban nem illik ilyen old school join-okat csinálni. Írd át modern sql szintaktikára:

  from egytabla t1
  join kettotabla t2 on t1.id = t2.id
  join haromtabla t3 on t1.id = t3.id

  A hiba pedig elég egyértelmű. A három tábla descartes szorzata túl sok sort adna vissza, és (shared hosting környezetben jellemzően direkt) le van korlátozva a mysql memória használata, join-ok mérete.

  Ezt elkerülni úgy tudod, hogy vagy megpróbálod átkonfigurálni a mysql-t, ha nem vagy hosting környezetben akkor ez menni fog.
  Vagy alselecteket használsz, és megpróbálod csökkenteni a join-olt táblák visszaadott sorainak számát. Erre jó lehet akár egy szigorúbb feltételes join is. Az is lehet, hogy az id kapcsolat nem jó, és ez miatt többszörőződik meg indokolatlanul a join.
  Vagy átmész egy rendes hosting-hoz, ahol nincs ilyen korlátozás.

• Jim-Y veterán

  #1577 2013-02-05 14:02:14

  Új Válasz

  Ú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

  

  Jim-Y

  veterán

  sziasztok

  3 táblából szeretnék lekérdezni, mysql-ben, az elején csak két táblából kérdeztem le, az futott rendesen, így:

  SELECT table_1.id as ROW_1, SUM(table_1.VALAMI) as ROW_2, SUM(table_1.VALAMI) as ROW_3, SUM(table_1.VALAMI) as ROW_4, [B]table_2[/B].akarmi as isAKARMI
  [B]FROM EGYTABLA as table_1, MASIKTABLA as table_2
  WHERE table_2.id = table_1.id[/B]
  GROUP BY 1
  ORDER BY 3

  A kiemelt részek a fontosak, mert így működött, ellenben ha a

  FROM EGYTABLA, MASIKTABLA, HARMADIKTABLA -sorra kicserélem a fentit, akkor egy ilyen hibát dob:

  #42000The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay

  A kérdés tehát: hogy lehet három táblát összekapcsolni egy selectben? van egy oszlop, amivel a három táblát össze tudom kapcsolni, ez az "id".

  Próbáltam így is:

  SELECT ...
  FROM [B]EGYTABLA_CI [/B]as tabla_1
  INNER JOIN [B]MASIKTABLA [/B]as tabla_2 ON tabla_1.id = tabla_2.id
  INNER JOIN [B]HARMADIKTABLA [/B]as tabla_3 ON tabla_1.id = tabla_3.id
  ...

  üdv

  megj: rákerestem a hibára, de nem lettem okosabb amit ír az error, azt pedig nem tudom hova kéne beilleszteni a queryben.

• fordfairlane veterán

  #1576

  #1575 Vision

  2013-02-01 16:13:28

  Új Válasz

  Ú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

  

  fordfairlane

  veterán

  #1575 Vision

  Az MYI kiterjesztésű fájl elvileg MyISAM index.

• Vision veterán

  #1575

  #1574 martonx

  2013-02-01 15:31:35

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1574 martonx

  Töröltem az indexet, és újrageneráltam. A számosságra 204-et ír a ~37000 helyett, miközben az utóbbinak kéne ott állnia. InnoDb a tábla.

• martonx veterán

  #1574

  #1573 Vision

  2013-02-01 14:57:02

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1573 Vision

  Nem, de a hibaüzenet alapján újra kellene indexelni a táblát.

• Vision veterán

  #1573 2013-02-01 14:28:29

  Új Válasz

  Ú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

  

  Vision

  veterán

  Valamelyikőtök találkozott már ilyesmivel? Incorrect key file for table '/tmp/#sql_3c7_0.MYI'; try to repair it.

  Mysql-ről van szó.

• lakisoft veterán

  #1572 2013-01-31 09:09:57

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  Segítséget szeretnék kérni olyan embertől akinek Oracle DW és/vagy MSSQL BI fejlesztői tapasztalata van. Kérem keressen privátban a részleteket ott megírom.

• lakisoft veterán

  #1571

  #1570 Dave-11

  2013-01-30 06:56:51

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1570 Dave-11

  Örülök.

• Dave-11 tag

  #1570

  #1569 lakisoft

  2013-01-29 20:14:33

  Új Válasz

  Ú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

  

  Dave-11

  tag

  #1569 lakisoft

  Köszi, ezzel sikerült megoldani!

• lakisoft veterán

  #1569

  #1568 martonx

  2013-01-29 15:15:58

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1568 martonx

  [link], [link]

• martonx veterán

  #1568

  #1566 Dave-11

  2013-01-28 21:30:10

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1566 Dave-11

  MS Access SQL nyelvében nincsen case when, helyette IIF()-et kell használni.
  Nem próbáltam ki, de valami ilyesmi kellene neked:

  Select mezo1, mezo2, mezo3, IIF(mezo4 = 0 , 'Nő', 'Férfi') from tabla

• Apollo17hu őstag

  #1567

  #1566 Dave-11

  2013-01-28 19:38:20

  Új Válasz

  Ú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

  

  Apollo17hu

  őstag

  #1566 Dave-11

  Csinálj egy kétrekordos dimenziótáblát, amiben 1-1 rekordja lesz a nőknek és a férfiaknak. Kulcs a 0 és az 1, a dimenziótáblában meg felveszel egy "férfi" és egy "nő" értéket, majd ezeket pakolod a jelentésbe.

• Dave-11 tag

  #1566 2013-01-28 18:23:40

  Új Válasz

  Ú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

  

  Dave-11

  tag

  Úgy gondoltam, hozzátok fordulok a kérdésemmel:
  Nem konkrétan SQL a téma, hanem MS Acces. Az lenne a lényeg, hogy van egy táblám, benne személyekkel, és van egy Neme mező, ahol 0 vagy 1 található (0 ha nő, és 1 ha férfi). Ehhez készítek egy jelentést, és hogy tudnám megcsinálni azt, hogyha a Neme értéke 0, akkor Nőt írjon ki, ha pedig 1, akkor Férfit, mert egyébként ugye a számokat írja ki, de úgy meg elég csúnya.

• cucka addikt

  #1565

  #1563 martonx

  2013-01-24 15:32:55

  Új Válasz

  Ú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

  

  cucka

  addikt

  #1563 martonx

  Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?
  Annyi előny, hogy nem kell lefordítani, megszabadulsz a Make/Ant szkriptektől, vagy az xml-ek turkálásától Mavenben, stb. . (Meg persze bizonyos szempontból ez hátrány is, tudom jól, ne akadj fenn ezen)

  A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások?
  Ha alkalmazáslogikára szeretnéd használni, akkor szélesebb körű beépített libeket, és igen, több nyelvi eszközt.

  Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt...
  Az egy dolog, hogy a php egy nem túl jól kitalált nyelv, csomó furcsasággal, viszont a beépített eszközkészlete (magyarul a standard lib) igencsak jól használható és jól dokumentált.

  De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni.
  Emlékeztetlek, az eredeti hozzászólás a php topikban keletkezett, arra a felvetésre, hogy a php kódba nem kéne egyáltalán sql-t beágyazni/összerakni, hanem minden hasonló feladatot tárolt eljárással kéne megoldani. A php topikban pedig jellemzően nem a szakma krémje szokott kérdéseket feltenni, hanem kezdők.
  Szóval igyekezz ennek tükrében értelmezni, amiket írtam. Én is pontosan jól tudom, hogy komplex projekteknél és nagy adatmennyiségnél az adatbázis szerver és kliens közötti kapcsolat overhead-je elszaladhat. Ennek ellenére nem fogom egyik kezdő php fejlesztőnek sem tanácsolni, hogy dobja ki a php-vel legyártott dinamikus sql-t és kezdjen inkább tárolt eljárásokat írni ezek kiváltására.

• rum-cajsz őstag

  #1564

  #1562 cucka

  2013-01-24 14:55:21

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1562 cucka

  Tegyük hozzá, ha jól értelek, hogy te a webes programozásról beszélsz, nem a klasszikus adatbáziskezelési feladatokról, ugye?

• martonx veterán

  #1563

  #1562 cucka

  2013-01-24 14:42:02

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1562 cucka

  "A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz."
  Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?

  "Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van."
  A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások? Legyen bennük lambda, meg generikus függvények??? Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt...

  "A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást."
  Ne általánosítsunk már ennyire. Lehet, hogy a te eseteid kimerülnek abban, hogy egy darab adattábla van a weboldalad alatt. De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni. És ha készen vagy vesd össze a futásidőket. Tudnék mutatni olyan tárolt eljárásokat, amik több ezer sorosak, és percek alatt lefutnak. Az egyikkel konkértan egy 4 óra futásidejű webszerver oldali tákolmányt váltottunk ki.
  Csak gondolj bele. Minden egyes db-hez fordulás idő. Ha van egy komplexebb feladat, amihez több db hívás kell, hívásonként visszad az sql szerver pár millió adatot. Utána for-al megforgatod az adatokat, megcsócsálod, majd visszaírod db-be, akkor az nagyságrendekkel könyebben, gyorsabban, optimalizáltabban elvégezhető db oldalon.
  Az én eseteim pl. szinte minden esetben ilyenek. Mégse mondom azt, hogy az esetek többségében tárolt eljárást kell írni. Ehelyett maradjunk abban, hogy a helyzet dönti el, melyik megoldás a hatékonyabb a rendszer futása, terhelhetősége szempontjából.

• cucka addikt

  #1562

  #1551 sztanozs

  2013-01-24 13:19:17

  Új Válasz

  Ú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

  

  cucka

  addikt

  #1551 sztanozs

  Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.
  Igen, ez így van. Lehet adatbázis deploy scripteket írni, nincs ezzel semmi gond. Az eredeti kérdésfelvetés viszont a php topikban volt, méghozzá azzal kapcsolatban, hogy a php kódban implementált alkalmazáslogikát megérné tárolt eljárásként megírni. Na ezzel így már problémák vannak:
  - A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz. Tárolt eljárásokkal elvesződik az előny.
  - A legtöbb php-s projekt olyan kis léptékű, amin már egy adatbázis deploy script elkészítése és karbantartása is túlmutat.

  Nem azt mondom, hogy a tárolt eljárások ne lennének alkalmanként hasznosak, de abban a kontextusban, ahol felmerült a kérdés, egyáltalán nem tartom jó ötletnek.

  A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.
  Mi az a WSWG?

  (#1555) martonx
  Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn)...
  Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van.

  A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást.

• martonx veterán

  #1561

  #1560 iff

  2013-01-24 10:20:21

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1560 iff

  Nyilván hibás az ütemezett scriptben megadott autentikáció, de ezt innen nem fogjuk tudni helyetted megoldani.

• iff senior tag

  #1560 2013-01-23 18:23:35

  Új Válasz

  Ú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

  

  iff

  senior tag

  Sziasztok!

  Hátha tud segíteni valaki. Adott egy ubuntu 12.10 szerver, amin fut a PostgreSQL 9.1. Ennek a mentését szeretném, hogy automatikusan lefusson. Erre a script megvan ill. a cron is működne, de amikor eléri a pg_dump ... leáll. Ha WinScp-vel belépek és a scriptet kézzel próbálom futtatni akkor sem fut le. Terminálban root-ként a pg-hez jelszó beírása után indul is a backup és lefut. Amit eddig találtam, ott valami olyat írtak, hogy csatolni kellene az pg_backup.sh-t. Na ezt, hogy tudnám megcsinálni? (gondolom jelszó a probléma, nem tud hozzáférni az adatbázishoz)
  Előre is köszönöm a segítséget.

• Sk8erPeter nagyúr

  #1559

  #1556 Sk8erPeter

  2013-01-18 23:13:22

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1556 Sk8erPeter

  Hát ez is igaz, hogy ott nagyon OFF lenne. Rájöttem, hogy a legtisztább az lenne, ha az illető jönne inkább ide témázni a dologról, talán végre konstruktív vita is kialakulhatna, "nem arról szólna végre a topic, hogy nááám múúúkodik az, hogy lekérjem a termékek táblából a 123-as id-jú termék nevét, mééé' neeem?"

• lakisoft veterán

  #1558

  #1556 Sk8erPeter

  2013-01-18 13:54:23

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1556 Sk8erPeter

  Ez nem kibeszélés, csak megvitatás. Egy rossz szót nem szóltam. .

• martonx veterán

  #1557

  #1556 Sk8erPeter

  2013-01-18 08:55:27

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1556 Sk8erPeter

  mert az egy php-s topik, minek offolni benne SQL fejlesztő eszközökről. Annak meg nem látom értelmét, hogy egy szemmel láthatóan nem képben lévő, ám annál arrogánsabb embert, megpróbáljunk picit is képbe hozni.

• Sk8erPeter nagyúr

  #1556

  #1552 rum-cajsz

  2013-01-18 03:08:14

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1552 rum-cajsz

  "Vagy mit nevez ő a XXI. század fejlesztői eszközének?"
  Ezeket a kérdéseket miért nem teszitek fel közvetlenül neki a belinkelt topicban?
  (Szerk.: tisztább is lenne, mint a háta mögött beszélni a hozzászólásáról...)

• martonx veterán

  #1555

  #1550 lakisoft

  2013-01-17 12:15:16

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1550 lakisoft

  "- A tárolt eljárásként írt kódot nehézkes verziókövetővel használni"
  Butaság, miért ne lehetne, bár valóban nem annyira triviális. Én pl. TFS-ben egy külön mappát tartok fenn a DB scripteknek, amik ugyanúgy verziókezelődnek.

  "- Az adatbázisok által biztosított fejlesztői eszközök a 60-as évek színvonalát idézik"
  Ez mondjuk nagyon függ attól, hogy milyen DB-t használunk. Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn), MySql vonalon szeretem a Toad for MySql-t (mysql-hez van kismillió jó SQL IDE), PostgreSQL-hez meg egészen használható a PgAdmin.

  Klasszikus hibás programozói attitűd, amikor valaki nem akar megtanulni SQL-ezni (pedig gyakran nagyon hasznos), hanem mindent java-ban, c#-ban, php-ben akar programozni. Én használok ORM-et (sőt mostanra csak ezt), de az ORM-el ha a feladat azt kívánja meg akkor tárolt eljárást hívok meg. Sokan az ORM-et is félreértik.
  Attól, hogy ORM-et használ valaki, miért ne lehetne összerakni DB oldalon egy view-t, vagy egy tárolt eljárást, és azt használni ORM-mel?

• Lortech addikt

  #1554

  #1550 lakisoft

  2013-01-17 11:57:44

  Új Válasz

  Ú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

  

  Lortech

  addikt

  #1550 lakisoft

  Örökös vita a tárolt eljárás használata vagy nem használata.
  Én egyik mellett sem kardoskodnék, mert ezer + 1 körülménytől függ, hogy adott fejlesztésben / ellenjavalt, érdemes / kell használni tárolt eljárásokat.
  Csak egy a számtalan, neten fellelhető cikkből, threadből, ahol ez a téma: [link]
  Szinte minden érvre lehet ellenérvet találni ebben a témakörben. Szerintem az a fontos, hogy jól ismerjük a lehetőséges megoldásokat, ezek előnyeit, hátrányait, így lehet jó döntéseket hozni a tervezés, implementáció során.

• sztanozs veterán

  #1553

  #1552 rum-cajsz

  2013-01-17 11:46:23

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1552 rum-cajsz

  Más kérdés persze, hogy a keretrendszerek gyakran (?) nem készítenek tárolt eljárásokat, csak összehegesztik az adatstruktúrát és legenerálják a műveleteket közvetlen SQL utasításokként.

  De végül is nem mindegy, hogy az ember keretrendszert haszál, vagy speciális környezetet fejleszt. Természetesen egy kis fejlesztésnél keretrendszer használatával az ember nem fog minden adat-reprezentációt kézzel megvalósítáani, mivel pont azért használ keretrendszert, hogy ezzel ne kelljen foglalkozni.

• rum-cajsz őstag

  #1552

  #1550 lakisoft

  2013-01-17 11:41:29

  Új Válasz

  Ú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

  

  rum-cajsz

  őstag

  #1550 lakisoft

  A verziókezelés használata önfegyelem kérdése. Nem is értem miért ne lehetne a tárolt eljárásokat verziókezelni, hiszen végül is azok is csak sima szöveges "fájlok".

  A második résszel meg egyszerűen nem értek egyet. Vagy mit nevez ő a XXI. század fejlesztői eszközének?

• sztanozs veterán

  #1551

  #1550 lakisoft

  2013-01-17 11:33:08

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1550 lakisoft

  Az elsővel inkább az a gond, hogy a feljesztés előtt ha nincs rendes specifikáció, akkor az adattartalom és adat-reprezentáció komolyan változhat a fejlesztés során. Ilyen helyzetben tényleg hátrány lehet az adatbázis oldal verziókezelése. Azonban az adatbázis felépíthető tisztán text alapú utasításokon keresztül, amit már kezel a verziókezelő. Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.

  A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.

  Ráadásul amint adatbázis szintű jogosultságkezelésre kerül sor nagyon nehéz bekorlátozni egy felhasználó tevékenységét, ha bármilyen tevékenységre kell jogának legyen bármelyik táblán, mert közvetlen adatbázis műveletekkel megy a lekérdezés, frissítés.

• lakisoft veterán

  #1550 2013-01-17 11:20:55

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  Van egy HSZ amiről szeretném kikérni a szakmai véleményeteket: [link]

• lakisoft veterán

  #1549

  #1544 TheCompany

  2013-01-16 11:51:41

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1544 TheCompany

  Miért akarod leállítani a szolgáltatást?

• Sk8erPeter nagyúr

  #1548

  #1547 DonThomasino

  2013-01-16 11:45:38

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1547 DonThomasino

  Konkrétabban?

• DonThomasino veterán

  #1547

  #1546 martonx

  2013-01-16 08:59:47

  Új Válasz

  Ú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

  

  DonThomasino

  veterán

  #1546 martonx

  Hát az eleje ok, de második felében néhány helyen elveszettem a fonalat.

• martonx veterán

  #1546

  #1545 DonThomasino

  2013-01-16 08:46:08

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1545 DonThomasino

  De hiszen ez kezdőknek szóló könyv. Onnan indul, hogy hogyan hozzunk létre táblát, meg hogy kérdezzük le select * from tabla-val. Mit akarsz ennél kezdőbbet? Hogyan installáljunk SQL szervert? Letöltöd netről, majd next-next-finish.

• DonThomasino veterán

  #1545

  #1530 martonx

  2013-01-16 08:39:50

  Új Válasz

  Ú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

  

  DonThomasino

  veterán

  #1530 martonx

  Esetleg valami olyan ami könyv ami abszolút kezdőknek való,
  jobban kitér az alapokra...?

• TheCompany csendes tag

  #1544 2013-01-08 21:37:04

  Új Válasz

  Ú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

  

  TheCompany

  csendes tag

  Sziasztok!

  Olyan kérdésem lenne, hogy MSSQL 08 Server R2-be lehet-e olyat csinálni, hogy SQL Server Agent Job-ba leállítani egy szolgáltatást, magyarán meg tudom-e oldani, valahogy, hogy pl. net stop dnscache?
  Steppeket szeretnék feltölteni, hogy állítsa le a szolgáltatást, aztán második stepbe, hogy backupoljon egyet, aztán meg indítsa újra el az adott szolgáltatást.
  Remélem valaki tud segíteni!

• Vision veterán

  #1543

  #1542 martonx

  2013-01-07 17:03:41

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1542 martonx

  Igen, már tegnap kiderült, hogy a szerver haldoklott, ezért volt lassú (most villámgyors). Ettől függetlenül még érdekelt a téma, és gondoltam megkérdezem a nálam tapasztaltabbakat, hogy van-e mód tovább gyorsítani az SQL-t. Mint írtam, egy más jellegű problémánál jól fog jönni a file-cache, de az kisebb jelentőségű, mint az első.

  Kösz a válaszokat!

• martonx veterán

  #1542

  #1541 Vision

  2013-01-07 16:35:51

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1541 Vision

  Rossz hírem van, mert ez tipikusan nem cache-elendő, nem cache-elhető eset. Illetve lehet próbálkozni a Zeratul által leírtakkal (bár mysql-nél pont ezt sem tudod megtenni). Pont erre való lenne az SQL, hogy szabadszavas kereséskor villámgyorsan kiszolgálja az alkalmazást.
  Gondolom azért akarod cache-elni, mert lassúak a válaszok?
  Pedig ez még nagyon nem is sok adat. Én a helyedben inkább annak néznék utána, hogy miért lassúak a válaszok, mert ennyi adat nem sok. Vagy eleve rossz a DB felépítése, vagy hiányoznak index-ek.

• Vision veterán

  #1541

  #1540 martonx

  2013-01-07 15:40:27

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1540 martonx

  Ok, leírom:

  Van 3 táblám: ugyvitel_marka, ugyvitel_termek, ugyvitel_termek_altipus, ugyvitel_termek_tulajdonsag_kapcsolat

  ugyvitel_marka: id, markanev; értelemszerűen márkanevek vannak benne, ~250 db.
  ugyvitel_termek: id, ugyvitel_marka_id, termeknev: a termékek listája. Egyelőre ~17000 rekorddal.
  ugyvitel_termek_altipus: id, ugyvitel_termek_id, ugyvitel_statusz_id, stb.. : termék alkategóriák listája. Szintén ~17000 rek.
  ugyvitel_termek_tulajdonsag_kapcsolat: id, ugyvitel_tulajdonsag_id, ugyvitel_termek_altipus_id, tulajdonsag: ez tartalmazza a termékekhez tartozó tulajdonságokat (cikkszám1, cikkszám2, ismertető, stb...). Az ugyvitel_tulajdonsag_id a tulajdonság típusát azonosítja (csz, ismertető, stb.). Jelenleg ~110000 rekorddal.

  Ezekből kéne leválogatni márkanév, terméknév, csz1, csz2, és ismertető alapján (szabad szavas keresővel).

  Az adatbázis tovább fog nőni, akár a többszörösére. MySQL-ről van szó.

• martonx veterán

  #1540

  #1536 Vision

  2013-01-07 15:14:53

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1536 Vision

  Fordítsunk a dolgon. Azt mond meg mit szeretnél. Milyen program alá, milyen platformon, mindenféle részlet jöhet, amu publikus. Aztán megpróbálunk segíteni. Mert ennyi részletből "Kereséshez van szükségem erre, szóval egy 7*20000 soros táblát kéne a cache-ben tartani." nem sok minden derül ki.

• Vision veterán

  #1539 2013-01-07 15:07:34

  Új Válasz

  Ú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

  

  Vision

  veterán

  Egyébként más problémával kapcsolatban - ahol tudom használni a file cache-t - adtatok ötleteket, szóval már ezt is köszönöm.

• bpx őstag

  #1538

  #1535 martonx

  2013-01-07 14:34:28

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1535 martonx

  jó, de nem mindenhol van webszerver ahol van, ott persze, hogy lehet
  egyébként a matview elsődleges célja valóban nem ez, de erre is használható

• sztanozs veterán

  #1537

  #1536 Vision

  2013-01-07 14:17:51

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1536 Vision

  Szerintem a kolléga file cache-re gondolt alapvetően.

• Vision veterán

  #1536

  #1533 martonx

  2013-01-07 14:14:57

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1533 martonx

  Tisztában vagyok a memcache-sel, de úgy vélem, hogy ennél gyorsabb lenne SQL szerveren belül maradni, hiszen a VIEW már úgy lenne összeállítva, hogy a legoptimálisabb legyen lekérdezés-szempontból. Csak azt tartom "pazarlásnak", hogy minden lekérdezésnél frissíti a tartalmát. Kereséshez van szükségem erre, szóval egy 7*20000 soros táblát kéne a cache-ben tartani. Ez sok...

• martonx veterán

  #1535

  #1532 bpx

  2013-01-07 14:11:18

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1532 bpx

  Azért a materialized view, illetve indexed view-k korántsem olyan hatékonyak, mint egy sima webszerver cache, mert ezek ha nem is olyan mértékben mintha elölről indulna mindegy egyes lekérdezés, de azért mozgatják az SQL-t. Az adatok felesleges mozgásáról, felesleges SQL-hez fordulásokról nem is beszélve. Szvsz nem is arra lettek kitalálva, hogy kvázi cache-t alkossanak bizonyos táblák felett, inkább az indexelt lekérdezéseket könnyítik meg nagyon komplex lekérdezéseknél (legalábbis MSSQL vonalon, ott használtam már indexed view-t).

• martonx veterán

  #1534

  #1532 bpx

  2013-01-07 14:03:44

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1532 bpx

  én is szerver oldali cachelésre gondoltam, csak nem sql szerver oldalán (annak van épp elég baja), hanem webszerver oldalon. Szvsz érdemes alkalmazás oldalon is cache-eltetni, ha okosan van felépítve az alkalmazás minden rétege.

• martonx veterán

  #1533

  #1531 Vision

  2013-01-07 14:00:55

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1531 Vision

  Nem a táblát cache-eled, hanem a választ. Mondjuk ASP.NET-tel egy programsor beállítani az adott válasz cache stratégiáját. De gondolom PHP-ban se kivitelezhetetlen feladat normális cache stratégiát felépíteni.
  Hogy jobban megértsd:
  Kliens oldalon lekérsz adatokat. Ezt úgy teszed meg, hogy elküldöd a kérést a webszervernek, és az odafordul az SQL-hez, lekéri az adatokat, ezekből mondjuk json-t, xml-t, html-t csinál, és azt visszaküldi a böngészőnek (ami persze lehet vastag kliens, bármilyen program, csak manapság a böngésző a legelterjedtebb).
  Nos ezt a webszerver választ tudod cache-eltetni, függetlenül attól, hogy mennyi sor van az sql tábládban. Adott kérdére mindig adott választ fog adni X ideig. Sőt továbbmegyek, a választ a kliensben is el tudod tárolni, így legközelebb még a webszerverig se fog eljutni a kérdés, mert a válasz már ott van a kliens memóriájában.

• bpx őstag

  #1532

  #1529 martonx

  2013-01-07 13:58:09

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1529 martonx

  egyáltalán nincs eltévedve, én nem feltétlenül cache-elnék alkalmazásoldalon (de persze én nem fejlesztő vagyok)

  ezt úgy hívják, hogy materialized view [link]

  Oracle-ben van, a többi RDBMS-ről nincs tapasztalatom
  wiki szerint MS SQL-ben van hasonló, MySQL-ben csak workaround

• Vision veterán

  #1531

  #1529 martonx

  2013-01-07 13:11:42

  Új Válasz

  Ú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

  

  Vision

  veterán

  #1529 martonx

  Nem vagyok eltévedve, és hogyan cache-elsz egy 20.000 soros táblát?

• martonx veterán

  #1530

  #1527 DonThomasino

  2013-01-07 12:59:22

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1527 DonThomasino

  Tényleg csak pár hsz-t kellett volna visszaolvasnod...

• martonx veterán

  #1529

  #1528 Vision

  2013-01-07 12:58:36

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1528 Vision

  Szerintem el vagy tévedve. Ezt klasszikusan nem SQL-ben, hanem a programodban kell megoldani, és cache-elésnek hívják

• Vision veterán

  #1528 2013-01-07 12:28:39

  Új Válasz

  Ú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

  

  Vision

  veterán

  Sziasztok!

  Tudtok egy olyan parancsot/függvényt/módszert, amely ugyanúgy működne, mint egy VIEW, de nem frissülne a lekérdezéskor a tartalma, hanem mondjuk csak óránként?

  Illetve mennyivel gyorsabb a lekérdezés egy VIEW-ból (hiszen frissítenie kell a szervernek a tartalmát), mintha én szedném össze az adatokat az összekapcsolt táblákból?

• DonThomasino veterán

  #1527 2013-01-07 12:04:58

  Új Válasz

  Ú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

  

  DonThomasino

  veterán

  Tud valaki ajánlani egy jó könyvet ? az alapoktól és ha lehet magyart.
  2008 és 2012 főleg üzemeltetéshez...
  

• bpx őstag

  #1526

  #1525 csabyka666

  2012-12-31 13:27:02

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1525 csabyka666

  itt egy példa táblákkal, egy olyan alkatrésszel, ami 3 autóba is beépíthető

  alkatrész
  ---------
  cikkszám | alk_név | ...
  ---------------------------------
  1 | féktárcsa | ...
  2 | ablaktörlő | ...
  
  autó
  ----
  típusnév | gyártott_db | ...
  ---------------------------------
  Audi | 10000 | ...
  Suzuki | 50000000 | ...
  Trabant | 10000000 | ...
  
  kapcsolótábla
  -------------
  cikkszám | típusnév |
  -----------------------------
  1 | Audi |
  1 | Suzuki |
  1 | Trabant |
  2 | Audi |

  szerk: javítottam mert a PH! máshogy értelmezi a tabokat

• csabyka666 veterán

  #1525

  #1524 bpx

  2012-12-31 13:21:16

  Új Válasz

  Ú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

  

  csabyka666

  veterán

  #1524 bpx

  Ajja', kemény menet lesz ez!

• bpx őstag

  #1524

  #1523 csabyka666

  2012-12-31 13:20:00

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1523 csabyka666

  igen, de a kapcsolótáblában

• csabyka666 veterán

  #1523

  #1522 bpx

  2012-12-31 13:17:57

  Új Válasz

  Ú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

  

  csabyka666

  veterán

  #1522 bpx

  Hm, ez igaz. A lényeg, hogy én úgy akarok felvenni minden alkatrészt, hogy megadom a felvételnél, hogy melyik autótípusokba lehet beépíteni. Itt jön a következő gond, hogy például ugyanazt a féktárcsát beépíthetem 8 féle autótípusba is, akkor azt a rekordot 8x kell felvennem, csak más autókkal?

• bpx őstag

  #1522

  #1521 csabyka666

  2012-12-31 13:14:42

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1521 csabyka666

  1. konkrétan Access-ben fogalmam sincs, nem használok Access-t

  nyilván lesz az autó és alkatrész tábla az ábrán látható oszlopokkal és elsődleges kulcsokkal
  lesz a kapcsolótábla, amiben idegen kulcs a másik 2 tábla elsődleges kulcsa

  2. kelleni semmit se kell
  autót és alkatrészt is lehet felvenni a kapcsolótábla piszkálása nélkül
  az autó és alkatrész tábla között nincs közvetlen kapcsolat
  és a diagram szerint nem kötelező, hogy minden alkatrészhez tartozzon autó és fordítva sem (hiszen a * az lehet 0 is)

• csabyka666 veterán

  #1521

  #1520 bpx

  2012-12-31 12:10:37

  Új Válasz

  Ú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

  

  csabyka666

  veterán

  #1520 bpx

  Biztos, hogy ez egy nagyon egyszerű dolog, de pontosan hogyan kell ezt csinálni Access-ben?

  Más: csak akkor kell a kapcsolótáblát "piszkálni", ha alkatrészt veszek fel? Autó felvételénél nem, ugye?

• bpx őstag

  #1520

  #1519 csabyka666

  2012-12-31 12:07:47

  Új Válasz

  Ú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

  

  bpx

  őstag

  #1519 csabyka666

  "ha fel akarok venni egy alkatrészt, akkor meg kell adnom a kapcsolótábla "típus_név" mezőjét is, és így jelölöm, hogy milyen autóba passzol"

  erre van a kapcsolótáblád, amit az alkatrész felvétele után tudsz beállítani

• csabyka666 veterán

  #1519 2012-12-31 12:00:10

  Új Válasz

  Ú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

  

  csabyka666

  veterán

  Üdv!

  Lenne egy alap kérdésem. Access-es beadandót csinálok, és egy alap dologgal nem vagyok tisztában.
  Itt egy kép, amivel kapcsolatban kérdezni szeretnék:
  
  Ez egy részlet egy ER modellből. Mivel ez egy több-a-többhöz kapcsolat, a relációs modellben megvalósítom az egyedeket külön külön, plusz csinálok egy kapcsolótáblát, amibe belerakom az elsődleges kulcsokat. Eddig ok. Amit viszont nem tudok, hogy az adatokat hova, melyik táblába kell felvinni?
  Én úgy érzésre azt mondom, hogy ha fel akarok venni egy alkatrészt, akkor meg kell adnom a kapcsolótábla "típus_név" mezőjét is, és így jelölöm, hogy milyen autóba passzol? Jól látom, vagy teljesen butaság, amit beszélek?

  Köszi!

• lakisoft veterán

  #1518

  #1517 Sk8erPeter

  2012-12-29 02:12:58

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1517 Sk8erPeter

  Ez így van .

• Sk8erPeter nagyúr

  #1517

  #1516 lakisoft

  2012-12-28 22:43:10

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1516 lakisoft

  Nem is neked küldte, hanem a kérdezőnek.

• lakisoft veterán

  #1516

  #1514 martonx

  2012-12-28 22:02:09

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1514 martonx

  Ismerem az irodalmat. Használjátok egészséggel.

• Sk8erPeter nagyúr

  #1515

  #1514 martonx

  2012-12-28 21:52:43

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1514 martonx

  Hű, ez tényleg jónak tűnik! Beleolvasgattam, és tök jó látni végre olyan e-bookot, ahol nem hordanak össze hülyeségeket, és tök emberi nyelven közlik a JÓ információt. Biztos én is hasznát fogom venni, köszi!

• martonx veterán

  #1514

  #1512 cellpeti

  2012-12-28 21:40:36

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1512 cellpeti

  Ha MSSQL megfelel, akkor itt egy meglepően jó, meglepően naprakész, teljesen ingyenes, kezdő szintű könyv:

  link

• lakisoft veterán

  #1513

  #1512 cellpeti

  2012-12-28 17:45:49

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1512 cellpeti

  Milyen területen, milyen szintre akarsz eljutni?

• cellpeti nagyúr

  #1512 2012-12-28 17:31:25

  Új Válasz

  Ú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

  

  cellpeti

  nagyúr

  Üdv

  teljesen kezdő vagyok, milyen könyvet ajánlanátok a kezdéshez?

• lakisoft veterán

  #1511

  #1510 Jeti1

  2012-12-28 08:43:25

  Új Válasz

  Ú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

  

  lakisoft

  veterán

  #1510 Jeti1

  Ez a kérdés inkább ide való: [link]

• Jeti1 tag

  #1510

  #1496 Jeti1

  2012-12-28 00:05:17

  Új Válasz

  Ú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

  

  Jeti1

  tag

  #1496 Jeti1

  Utána néztem a dolognak, el is kezdtem megvalósítani a tervem, de problémám akadt. Az SSIS FTP Task Itemjét használva szépen fel és le tudok tölteni egy-egy fájlt az FTP tárhelyemről, de egyszerre többel már nem boldogulok. Érdekes módon letöltésnél (receive) a RemotePath résznél tudok joker karaktereket (?,*) használni, fetöltés (send) esetén a LocalPath résznél már nem, emiatt letölteni tudok egyszerre több fájlt, de feltölteni nem. Gondoltam használok egy For each Containert, összekapcsolva azt az FTP Taskkal, de ez sem hozta meg a várt sikert. Nem így kellene csinálnom vagy csak valahol valamit elírtam? Kellene kis segítség!

  

• Sk8erPeter nagyúr

  #1509

  #1508 Inv1sus

  2012-12-19 00:05:31

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1508 Inv1sus

  Na, ez gyorsan ment, jóhír, szívesen!

• Inv1sus addikt

  #1508

  #1505 Sk8erPeter

  2012-12-18 18:17:51

  Új Válasz

  Ú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

  

  Inv1sus

  addikt

  #1505 Sk8erPeter

  Sikerült, köszi. Tényleg sokkal egyszerűbb így.

• martonx veterán

  #1507

  #1502 Inv1sus

  2012-12-18 15:04:54

  Új Válasz

  Ú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

  

  martonx

  veterán

  #1502 Inv1sus

  Igaziból szereztél pár vidám percet, szóval mindenképpen hálás vagyok ezért.

• sztanozs veterán

  #1506

  #1504 fordfairlane

  2012-12-18 14:58:15

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1504 fordfairlane

  megfelelő helyzetekben

• Sk8erPeter nagyúr

  #1505

  #1504 fordfairlane

  2012-12-18 14:53:52

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1504 fordfairlane

  De ilyen tagelés-kategorizálás esetében miért lenne már jó a pipe-karakterrel elválasztott módszer? Indokot még nem írtál, szerintem jogos volt, hogy elég csúfnak találták a megoldást a többiek, meg én is.
  Nehézkes és lassú lehet a keresése, nehezebb szűrni, eleve ez a LIKE-os megoldás elég hányadék. Nem is lehet normálisan végigiterálni a kapcsolt elemeken. Módosítás/törlés is problémás, és még elég sok más érvet is fel lehetne sorolni ellene.

• fordfairlane veterán

  #1504

  #1501 sztanozs

  2012-12-18 14:44:20

  Új Válasz

  Ú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

  

  fordfairlane

  veterán

  #1501 sztanozs

  Mintha egyébként ne lehetne megfelelő helyzetekben denormalizált adatszerkezetet használni.

• Sk8erPeter nagyúr

  #1503

  #1502 Inv1sus

  2012-12-18 13:46:02

  Új Válasz

  Ú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

  

  Sk8erPeter

  nagyúr

  #1502 Inv1sus

  Szívesen! Írd meg itt, ha nem megy.

• Inv1sus addikt

  #1502

  #1500 martonx

  2012-12-18 13:43:36

  Új Válasz

  Ú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

  

  Inv1sus

  addikt

  #1500 martonx

  És? Ezzel a hozzászólásoddal meg kitörölhetem, nem gondolod?

  Sk8erPeter: köszönöm, megcsinálom úgy, ahogy írtad.
  fordfairlane: neked is köszi, átolvasom, hogy képben legyek.

• sztanozs veterán

  #1501

  #1500 martonx

  2012-12-18 09:59:42

  Új Válasz

  Ú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

  

  sztanozs

  veterán

  #1500 martonx

  Ugyanmár, honnan tudná, mi fán terem az adatbázis-normalizáció

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