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.

[ Szerkesztve ]

Sk8erPeter

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

Sk8erPeter

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!

Ne várjunk a nevetéssel, amíg boldogok leszünk. Különben félő: meghalunk anélkül, hogy nevettünk volna. /La Bruyére/

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

Üdv

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

Tigris, tigris, csóvafény...

Milyen területen, milyen szintre akarsz eljutni?

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

link

Én kérek elnézést!

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!

Sk8erPeter

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

Ü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!

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

"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

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?

[ Szerkesztve ]

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

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)

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?

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

igen, de a kapcsolótáblában

Ajja', kemény menet lesz ez!

Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091

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

[ Szerkesztve ]

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

[ Szerkesztve ]

" I'm going to make him an offer he can't refuse."

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?

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

Én kérek elnézést!

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

Én kérek elnézést!

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

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

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.

Én kérek elnézést!

é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.

Én kérek elnézést!

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).

Én kérek elnézést!

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...

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ó

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.

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.

Én kérek elnézést!

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ó.

[ Szerkesztve ]

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.

Én kérek elnézést!

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!

[ Szerkesztve ]

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!

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

" I'm going to make him an offer he can't refuse."

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.

Én kérek elnézést!

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

" I'm going to make him an offer he can't refuse."

Konkrétabban?

Sk8erPeter

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

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