Příspěvky

1381

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 17. 07. 2015, 11:57:49 »

Ono to dost souvisí s použitím, spousta funkcí je pro větší sítě, controller sbírá data, který se můžou hodit při diagnostice potíží, nehledě k tomu, že to potom na lokálu může používat třeba recepční v hotelu, která vám může například aktivovat přístup na týden, nebo podobný chujovinky. Jinak pro samotný provoz kontroler potřeba není, pouze pro nastavení.

1382

Sítě / Re:Nestandardní maska sítě 255.255.254.0

« kdy: 17. 07. 2015, 10:47:40 »

Jestli by skoro nebylo lepší udělat druhou /24 síť a na routeru nastavit druhou gw a sítě proroutovat. Pokud mezi sebou zařízení nemají potřebu komunikovat, router to zatěžovat nebude a tobě to dost usnadní administraci.

Jinak ta maska /23 je rozhodně zcela v pořádku a není na ní nic špatnýho. Pokud by byla možnost všechny zařízení projít a předělat do nové sítě, nebyl by problém. Pokud budeš mít dvě překrývající se sítě, bral bych to jako silně dočasný řešení jen na dobu potřebnou ke změně, styl ono se to časem pomění tak nějak samovolně ti v tom mezičase nadělá dost problémů.

1383

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 17. 07. 2015, 10:31:23 »

Ale hlavně pořád nechápu tu primární potřebu připojování mnoha techniků? Nehledě k tomu, že si nejsem úplně jistej, jak se bude síť chovat, pokud se o ni "bude starat" víc controllerů a už vůbec jsem nepochopil, jak to souvisí s funkčností nějakých spojů... Snad síť na UniFi by měla být jako LAN a s připojením WAN to nemá nic společnýho... Buď se starám o internet, tudíž o WAN a nepotřebuju přístup do UniFi, nebo se starám o LAN a pak jsem buď přímo v ní a v ideálním případě je v ní i ten controller, na kterej se dostanu přes webůvku. Jinak, při realizacích těchto sítí se dost osvědčilo tam vrazit jako controller nějakej malej tupej PC s atomem za pár stovek, předpokládám by to měla zvládnout i malina?

1384

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 17. 07. 2015, 10:25:02 »

Wine uz nieje vobec potreba, na nete sa daju naist komunitne balicky a navody ako to rozbehnut pod linux, zalezi podla distro,

Wine nebyl potřeba nikdy, maximálně na "rozbalení" instalačky. Tuším pro *buntu nějakej balík je, ale ve výsledku je to jen javová aplikace, která se dá pustit na všem, jenom Ublitýkvi z nějakýho důvodu používá multiplatformní jazyk pro jedinou platformu...

1385

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 17. 07. 2015, 08:59:04 »

Trošku se v tom ztrácím... Je opravdu řeč o UniFi, nebo je to nějaká chybka v označení produktu? Protože to žádný webový rozhraní nemá a je to určený k pokrývání prostor signálem, ne k nějakým propojům. Rozchodit tu ovládací aplikaci pod Linuxem byl celkem zážitek (je to v javě, ale instalátor je pro win, muselo se to celý vykuchat a pak tam byl ještě nějakej problém... už si nepamatuju co přesně, ale něco jsem tam do té vykuchané instalace kopíroval ze starší verze? ale to už nemusí být pravda). Primárně se používá na pokrývání větších prostor/budov, na nějaký propojování se to moc nehodí, protože to má svoji prapodivnou logiku, která se nedá moc změnit a v zásadě si to dělá co chce... (kdo zkoušel používat wireless uplink, ví, o čem mluvím).

1386

Distribuce / Re:GRUB v koncích

« kdy: 13. 07. 2015, 15:11:22 »

Taky tak nějak od boku... UEFI?

1387

Vývoj / Re:SQL select

« kdy: 08. 07. 2015, 09:52:08 »

Upraveno, otestováno, řešení s naskládáním parametrů do BLOBu v nově vytvořeném VIEW funguje pro moje potřeby dostatečně dobře. V podstatě by mě zajímalo řešení, jak to udělat bez toho nového VIEW (nevím, jestli to celý jde nějak naskládat do nějakýho jednoho selectu klidně s dalšíma vloženýma).

Co se týče různých profi řešení nahrát to celý do paměti a podobně, nápady jsou to pěkný, ale celý je to na virtuálu, kde toho běží víc a na takový fórky tam opravdu není HW a nebudu ho kvůli tomuhle řešit :-)

A co se týče přístupu Kolemjdouciho, "všichni jsou amatéři, já jedinej tu dělám s velkýma DB a já jedinej to umím dobře", tak k tomu nemám slov. Přiměřený funkční řešení odpovídající situaci nevymyslí, protože i když existuje (a jsem presvědčenej o tom, ze jich je víc a že nějaké hezčí ještě najdu i když už v podstatě o nic nejde), tak je asi moc deformovanej podnikovým prostředím na to, aby dokázal vytvořit řešení pro obyčejný lidi. Vidím to v práci, RAM, CPU a disky přihazuju do serverů pomalu vidlema, protože co chvíla přijde někdo z vývoje s tím, že něco předělává, aby to běželo o 10 procent rychleji a stačí mu k tomu jenom dvakrát víc jader CPU a 4x víc RAMky. Jestli jste si nevšiml, jedná se o malej projekt, nejedná se o žádnej kritickej systém s tisícema paralelních přístupů a  nevydělá si to ve výsledku ani na kafe, který u něho vypiju, natož na cokoliv jinýho.

1388

Vývoj / Re:SQL select

« kdy: 08. 07. 2015, 08:49:34 »

podla vsetkeho firebirdsql podporuje INTERSECT operator takze tu kveru mozes poskladat takto ():

kdyz jsem tohle videl, skoro jsem se zaradoval, ale bohuzel, firebird intersect nepodporuje (alespon ne v posledni stable verzi).

1389

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 14:00:46 »

mozna trosku mimo tema, jak nejlepe sber nasledujicich dat

osobne bych pridal do tabulky "veliciny" polozku "typ", ktera by urcovala, jestli bude velicina ciselna nebo textova a v samotnych datech bych udelal dve pole hodnota_num a hodnota_txt s tim, ze by se zapisovalo vzdy jen do jenoho, pripadne uplne rozdelit tabulku s datama na cteni_num a cteni_txt

jeste me napadlo ukladat velicinu vzdy jako text, s tim, ze uspech konverze text->num by urcil sam o sobe, jakeho typu jsou data, ale mohl by s tim nastat problem, pokud by z nejakeho duvodu hodnota v textove velicine byla cislo (to musis posoudit ty, jestli je to mozne)

Ale jsou tu urcite lepsi lidi na DB a nedokazu realne posoudit, jaky by s tim mohly byt problemy, jak to bude s vykonem pro vetsi mnozstvi dat atd...

1390

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 13:38:21 »

Tohle myslis vazne? heh ... to ti nikdy fungovat nebude. A jako bonus vyrobis do systemu diru jak hrom. Nehlede na to, ze stejne nikdy zadny usery ktery neumej psat primo SQL nenaucis to pouzivat. Podotykam, ze podobnou vec ktera se presne o totez snazi adminuju. Defakto to vypada tak, ze ja a kolegove si pisem rovnou SQLko, protoze je to radove rychlejsi nez to, ktery ten bazmek vygeneruje, a useri nezvladaj z 80% udelat ani filtr metodou vyberu pole, zvolim jestli =/like/...

Jo, myslim to vazne a funguje to. Neni to nic zase tak zasadniho, jedinej uzivatel bude manzelka, ktere bud ty zavorky a dva operatory vysvetlim, nebo to holt udelam za ni :-D

Jinak to neni zadnej "system", ale jednoucelova aplikace pro presuny a synchronizace dat z databaze dodavatele do e-shopu. Nebavilo me se koukat, jak to manzelka prepisuje vsechno rucne, tak jsem to chtel malinko zautomatizovat. Nejvetsi problem je v tom, ze v puvodni databazi muze byt jedna polozka v libovolnem poctu ruznych kategorii, coz jsem potreboval predelat, idealne na zaklade definice "urcita kombinace kategorii v DB"="jedna kategorie v E-shopu", coz skoncilo na nadefinovani te kombinace kategorii DB (respektive neskoncilo, je to nekonecny, aneb "udelej to jinak, neslo by to takhle, pak to upravime, znovu a lepe")

Navic me celkem zajimalo, jestli to zvladnu i z puvodniho FireBirdu (z ciste vyzkumnych a masochistickych duvodu) bez prevodu cele DB do MySQL. Takze ted je z toho krasnej slepenec HTML/PHP/JS/MySQL/FireBird plnej zakomentovanych slepych vetvi, promenych pokus1 az pokusmilion a ted uz to musim jenom cely uhladit (v tomto pripade spis prepsat) :-D Ale jinak dobry, pekne sem si zablbnul, neco se naucil, par lidi na rootu zamestnal a i pres nazory "to nejde" jsem to dokazal rozchodit. Mam z toho dobry pocit. :-D

1391

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 12:59:11 »

Relační databáze předpokládají, že význam je určený sloupcem - mám sloupec příjmení, mám sloupec jméno. Jakmile se sémantika určuje další hodnotou, nebo několika dalšími hodnotami, tak SQL jako celek přestane fungovat - dotazy přestanou být názorné a čitelné, odhady založené na statistikách budou ustřelovat - a z SQL databáze se stane polofunkční key/value databáze - protože celý ten aparát - SQL, optimalizace, exekuce je navržená na nějaký způsob uložení dat, a pro něj je 30 let optimalizována.

dekuji za pekny popis situace Databaze, ze ktere to taham neni moje a v podstate mam jen dve moznosti - bud ji celou z SQL predelat na neco jinyho a zpracovavat posleze, nebo udelat nejakou lehkou prasarnu, coz je asi v tomhle pripade jednodussi cesta a moc velky zmatky nehrozi. Databaze neni moc velka (250MB vcetne obrazku v BLOBech) a predpokladam, ze poroste pomaleji, nez vypocetni vykon

1392

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 12:53:28 »

Obecné elegantní řešení na takové obecné dotazování není.

Pomůže při importu uložit výsledek tohoto dotazu do speciální tabulky, řádně oindexovat a dotazy dělat tam.

select coalesce(table.id, table2.id, table3.id) as id, table.vlastnost as vlastnost_a, table2.vlastnost as vlastnost_b, table3.vlastnost as vlastnost_c
full outer join table as table2 on table2.id=table.id and table2.vlastnost='B'
full outer join table as table3 on table3.id=table.id and table3.vlastnost='C'
where table.vlastnost='A'

To by fungovalo s malym poctem vlastnosti, ale tech vlastnosti je hodne (cca 200) a jejich pocet se muze menit.

1393

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 11:20:06 »

Asi jsem dostatečně nezdůraznil, že uvedené možnosti byly pouze příklady, a potřebuji obecnější postup. Jde o to, aby si podmínku vytvořil v jednoduchým klikátku uživatel, který má k dispozici tlačítka "přidat vlastnost" "AND" "OR" "(" a ")" - mohl si naklikat cokoliv, třeba "(A and (B or C) and (D or E)) or G" - prostě cokoliv. Takhle naklikaný výraz potom jednoduše sparsuju PHPčkem do query, který použiju na to view, který jsem si vytvořil.

A ano, uznávám, s SQL nepracuju, spíš ho občas používám.

Jinak mám to sice vyřešený, ale jestli někdo přijde s nějakým elegantnějším řešením, tak ho určitě uvítám

1394

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 10:23:15 »

ten tvoj:

SELECT DISTINCT ID from TBL WHERE Vlastnost=A and (Vlastnost=B OR Vlastnost=C)

je na tento ucel presne to co hladas.

To je na nic, tabulka obsahuje páry "jedno ID <-> jedna vlastnost" , takže těžko použiju jakejkoliv výraz obsahující "AND", protože mi nemůže dát nikdy žádný výsledek.

1395

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 10:19:36 »

Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.

Jedná se o synchronizaci dat mezi databází dodavatele a e-shopem, která probíhá max 1x denně a jedná se o pár tisíc položek (z nichž se dál zpracovává jen pár set) Trvá to v řádu vteřin a nějaký výrazný skokový nárust objemu dat se nedá očekávat, takže zatím je to v pohodě.

Ale děkuji, aspoň jsem o něco chytřejší. Většinou pracuju s SQL jen v rámci vlastních projektů a datový modely si vytvářím tak, aby to bylo co nejpohodlnější a nejrychlejší na používání. Zpracování cizích databází (a ještě doprasených, většina dat nesmyslně rozházená do desítek malých tabulek s hromadou vazeb mezi nima, dotaz pro získání 10ti sloupců znamená 7 joinů) není zrovna můj koníček :-D