Anonymní profil Ovrscout – Programujte.com

#10 Ovrscout
Zapomněl jsem napsat, že s MSSQL jsem už dlouho nedělal a nejsem na ni zrovna expert.
Raděj si zkontrolujte/nastudujte dokumentaci k této window funkci přímo v mssql dokumentaci (správné verze) :)

Nevím jestli splňuje zadání, ale pokud by vám stačil seznam děr a jejich velikost, tak by mohlo být zajímavé použít funkci LAG, která umí vrátit "předchozí" hodnotu. Tak by se dal udělat rozdíl času mezi řádky (seřazenými).

Výhody:
- databáze by to měla zpracovat jedním(seřazeným) průchodem tabulkou.
- v případě že bude chybět třeba několik dní/měsíců dat tak to bude odpověď z databáze jen jedna řádka.(případně by mělo jít velikost díry filtrovat)
- V případě že v tabulkce je více senzorů odlišených dle nějakého ID senzoru, tak dá se použít PARTITION BY a spočítat více senzorů jedním dotazem,
 

Nevýhody
- Výstupem nejsou jednotlivé chybějící záznamy ale asi by se asi museli "dopočítat" v aplikaci.

Pokud paralelní zápis nějak výrazně pomůže, tak to dost možná znamená že zápis není plně optimalizovaný, a šlo by to  udělat i rychleji.  Někdy je to ale jednodušší(i když nejspíše pomalejší, alespoň z mé zkušenosti) než přepisovat a optimalizovat kód pro import, obzvláště pokud cílíte na více různých databází(enginů).

Jak už psal Kit nejvíce zdržuje disk. Jen doplním že kromě samotné rychlosti zápisu má zejména pro rotační disky velký vliv i doba trvání fsync(což je zas závisle na rpm), což omezuje počet transakcí za vteřinu které je schopna db udělat. Což pro rotační HDD není zrovna moc velké číslo.

Dále, jak také už zmiňoval Kit, složité ORM (zejména pokud trackují změny) také nejsou tak úplně vhodné.
Nejvýkonější budou pravděpodobně přímo klientské knihovny pro danné databáze.
Ale já bych se nebál ani obecnějších knihoven jako ODBC, případně nějakých sjednocujících rozhraní jako ADO.NET pokud umožní si napsat vlastní SQL a umí parametryzované+prepared dotazy. Pokud se vkládá v dostatečně velkých dávkách tak případná režie tak moc nevadí.

Jinak vždy bude záviset na databázovém enginu, HW, komunikační cestě i tom jak "složitou" databázi máte.
A pro to je třeba měřit, měřit, měřit..

Pár základních optimalizací(první dva až tři jsou asi nejdůležitější):

• Správně veliké transakce, tj najít nějaký rozumný  počet insertů  který se provádí v jedné transakci.(odhad jednotky až desítky tisíc - je třeba změřit, příliš mnoho také může být problém)
• "Dávkové" vkládání, tj aby se do databáze neposílal jeden insert po druhém ale poslal se jeden povel s více "řádky" najednou.(kromně jiného omezuje vliv zpoždění komunikace)
  Toto se bohužel u databází občas dost liší a někdy je třeba si pomoci stored procedurou, nebo execute blockem (firebird)
• parametrizované+prepared dotazy.
• pokud máte hodně indexů, případně složité, může být vhodné je zapnout až po importu(pokud je to možné samozřejmně).
  Někdy může být rychlejší nejprve v rámci transakce vložit do temp tabulky(bez indexů, čistě v paměti, ideálně v rámci transakce) a až na konci transakce(nebo importu) provést jeden insert/merge do cílového umístění.(použil jsem pro firebird)
• Pokud komunikujete s databází na localhostu může být trochu rychlejší použít nějaký lokální komunikační protokol. Ale pokud už jste udělali optimalizace výše, tak to nejspíše nebude mít tak velký vliv.

Až zpětně jsem si všiml že píšeš o SqlBulkCopy, pro mssql by to měl být dobrý nativní způsob pro "dávkové" vkládání. Ale pro jiné db bude zřejmně třeba si poradit jinak.
Ale i tak raděj koukni jak velké transakce posíláte.

Zdravím, potřebuji radu k tomuto kódu:

 if (vklad == 1 || vklad == 2 || vklad == 5 || vklad == 10 || vklad == 20 || vklad == 50)
            {
                kredit = vklad;
                if (vklad >= cena)
                {
                    int zbytek = vklad -= cena;
                    Console.WriteLine("Zbylo vám {0} korun.", zbytek);
                    Console.WriteLine("Dobrou chuť, přeji pěkný den.");
                }

                // else goto Platba;
                //}
                else goto Platba;
            }
            else
                goto Chyba;
        Chyba:
            Console.WriteLine("CHYBA: Vklad pouze mincemi CZK: 1, 2, 5, 10, 20, 50");
            Console.WriteLine("PROGRAM SE VYPÍNÁ: FATAL ERROR");

Když zadá uživatel do vstupu 10, 20 nebo 50, podmínka s vkladem následně platí, ale zároveň se přemístí na blok Chyba. Jak mám změnit podmínku tak, aby mohl uživatel zadat i tato povolená čísla dle podmínky?

#1 majo

#3 majo

Nemůžu se zbavit dojmu že nemáme celý obrázek toho jak,co a proč se používá, ale mozna by tomu nějaká změna prospěla. I když bych se v první fázi koukal více globálního pohledu než jen jen na použití Get/Set .

Nicméně, možná by ti ve stávající situaci mohla pomoci nějaká forma lazyloading-u.
Tj prvotní entita by se vytvořila - mělká - pouze s defaultními parametry(předpokládám že je to nějaké ID, typ atp. ktery se po nacteni dat nezmeni) a teprv při dotazu na další hodnoty, nebo na povel, by se provedlo natení z pomalého zdroje dat.
Možná by to mohlo být i tak že samotná entita bude obsahovat jen obecná defaultní data (pokud taková dokážeš určit), a zbytek který by se dotahoval by byl samostatný objekt -uvnitř entity, který by se inicializoval a dotahoval později, případně to tak trochu otočit a prvotní mělký objekt (pokud vyhovuje) jen použít k vytvoření "plného" ... .

Ale jak říkám, bylo by potřeba vědět jak to celé má fungovat a proč a jaká data chceš načítat ještě před vytvořením objektu. Také odkud pochází seznam (nevytvořených) objektů se kterými se má pracovat, kolik jich zhruba má být, atd, atd.

#1 vesi
Co jsem tak koukal, tak v .NET to běžně nejde, nebo alespon ne snadno. To co jsi zkoušel se vyhodnocuje jenom při průběhu tou řádkou kde to je umístěno.
To co hledáš jde udělat snadno v C++ kde debuger může ohlídat přístup do určitého místa v paměti - procesory na to mají podporu ale v .Net se ale "fyzické" adresy proměných mohou měnit např díky garbage colectoru.

Nejde to použít vždy ale nejjednodušší je přejmenovat původní proměnnou a doplnit Get Set pod původním názvem. Do těch (Get,Set) pak lze umistit běžný breakpoint.

Někde, ale už nevím kde a jak, jsem četl že jde debuger přepnout do "native" režimu, kde, pokud je danné proměnná připinovaná v paměti (pinned), by pak mělo to co chceš jít použít.

V extrémním případě by pak mohlo jít použít Windbg, ale tam už ti moc poradit nedokážu.

Můžeš zkusit zagooglit C# data breakpoint, možná se ti podaří něco najít.

#9 gna
Dobrý tip, ale jen deset položek je dle mne příliš málo na to aby hráči nemohli taktizovat (předpokládám tahovou hru). A u řekněme 100 předgenerovaných položek zase narazíme na to aby to náhodné míchání nebylo zase tak moc náhodné a neseskupilo třeba všechny "zásahy" k sobě. To míchání pole trpí v podstatě těmi stejnými problémy co jsem popisoval dříve, příliš málo hodnot znamená že to není dostatečné náhodné, příliš mnoho hodnot může trpět na špatné rozložení.

Navíc je třeba říct že pro třeba úspěšnost 5% nebo 1% nebude deset položek stačit a můžeme se dostat do podobné situace jako prve.

Ještě mne napadlo:

Pro 70% úspěšnost
A=7 zásahů
B=3 minutí
C=(volitelně) počet minutí (a nebo možná zásahů) za sebou které budeme korigovat
D= počet položek které se budou míchat mezi skupinami, např (A+B)/2
n=počet skupin (odhadem 100/(A+B), ale pro menší účinosti to může být jinak)

1. Naplnit pole tak jak říkáš (řekněme třeba těch A+B (7+3=10) položek) a zamíchat. U 10 položek mi tak nevadí pokud budou třeba tři "minutí" za sebou.
2. (volitelně) doplnit korekci že nebudou C*minutí zasebou. Např prohodit za nejbližší další zásah.
   ale to už hodně zasahujeme do faktoru náhodnosti.
3. zopakovat 10x
   takže budeme mít pole o 100 položkách, vždy po deseti promíchaných položkách
4. Promíchat část hodnot(D) mezi skupinami, tj v poli o 100 položkách se skupinami po deseti a D=5 promíchat položky 5..14, 15..24, 25..34, atd.

Tím by se udržela úspěšnost  přes 100 položek, jakžtakž by to sedělo i v rámci dvou skupin (10..20) položek. A přitom by to mělo punc náhodnosti. Jediný problém je s tím že tato tabulka by se musela udělat pro každou možnou úspěšnost kterou hra uvažuje.
A navíc nemusí být jednoduché určit správné hodnoty A,B,C,D a celkovou velikost pole pro kadou z těch úspěšností, jinak to bude pro 1%, 50% a 99%

Myslím že nejdůležitější teď je, aby tazatelka zhruba určila pro kolik asi tak střel má ta pravděpodobnost zásahu platit, aby to hráče nefrustrovalo. A V jakých hodnotách procent se bude požadovaná úspěšnost pohybovat, jestli jde o několik vybraných hodnot nebo jde o hodnotu vypočtenou dle vzdálenosti(pak předpokládám že bude požadovaná účinost třeba i s desetinnými místy. Teprve pak můžeme zkusit najít nějaký vhodný algoritmus.

#2 peter
hmm, nejak postradam pouziti prepared statement, coz byl puvodni tazateluv pozadavek :)

Pouziti prepared statementu ma smysl zaroven s bindovanim parametru a to zas resi escapovani ktere

• v pripade ze je zapnuta emulace prepared statement(default) - si mysqli provede samo
• v pripade ze je emulace prepared statement vypnuta
  Tak escapovani neni potreba protoze se data poslou do databáze mimo vlastní text SQL povelu.
  Je ale dobre bindovani dodrzet vsude, i u cteni. A dat pozor na pripadne injektovani druheho radu.

(pro uplnost, mysqli muze v nekterych pripadech fallbackovat na emulaci prepared statementu i kdyz ten je jako takovy zakazan :( )

Pouzivat jakekoliv jine escapovani (html atp) pro vkladani pres SQL text statement je podle mne dost risk, cimz nerikam ze escapovat html se nema,ale ze se ma delat az tam kde se ma  pouzit.

Priklad prepared statementu je zde (objektovy i proceduralni styl)

http://php.net/manual/en/mysqli.prepare.php

#3 Jozef01

Rozdel si to na dve casti:

Udělej funkci DelkaPosloupnosti() která ti spočítá délku posloupnosti od zadaného indexu do konce pole.
(pro tvuj priklad a projiti pole od prvni polozky by mnela vratit hodnotu 2.
 po projiti od druhe polozky do konce pole by mnela vratit hodnotu take 2, pak 5,..)

Potom tu DelkaPosloupnosti zavolas ve for-u tak abys zjistil delku posloupnosti od prvni pozice v poli, od druhé, ... až do konce pole. V kazdem kroku porovnas vracenou delku a pokud je delsi nez budes mit zapamatovano, tak si ji zapamatuj spolu s aktualni pozici v poli pro kterou byla spocitana.

Zamnerne jsem to nenapsal jako navod, aby ses o to mohl pokusit sam.
Take to neni zrovna ten nejefektivnejsi algoritmus jak to udelat, spis naopak - je to reseni hrubou silou.
Je ale mozne to reseni rozvinout a optimalizovat.
(napr ukoncit pocitani pokud je zbyvajici delka kratsi nez nejdelsi nalezena posloupnost. Nebo třeba ve vnějším cyklu neprocházet pole striktne po 1, ale vyuzit toho ze vnitrni funkce najde index (ten prvni, ne nakonci) hodnoty ktera se opakuje.)