Zde si přihřeji polívčičku - tsv i csv soubory lze prohlížet v terminálu pomocí pageru pspg https://github.com/okbob/pspg - původně se jednalo pouze o pager pro použití v TUI SQL klientech, podpora csv a tsv byla docela logická, tak jsem ji tam dopsal.
A jak je to s rychlosti? Je to dostatecne rychle pro obrovske soubory? Ja pro zpracovani tsv pouzivam toto:
https://github.com/eBay/tsv-utils
Nepodporuje (a asi ani nijak nemuze) to indexy, takze dotazy jsou obecne mnohem pomalejsi, nez z realne DB (PG atd.). Jeste to zhorsuji joiny. Takze kdyz budes mit tabulku s dejme tomu milionem zaznamu a budes se chtit podivat na najaky reporty, je to pouzitelny, pro realne nasazeni (kdy by TSV/CSV byly realny zdroj dat) asi ne.
Jeste to zkusim porovnat s ODBC, to by mohlo byt zajimavy.
Jaký by byl use case pro oindexované CSV?
Úplná náhrada za FoxPro tu není, ale pro uložení dat i s podporou indexů a zamykáním lze použít SQLite. U toho CSV si to moc dobře nedovedu představit - je to pouze write only nebo v nejlepším případě append only formát navíc bez metadat, bez kontroly konzistence. Už jen formátování tabulky je u CSV dost pracné, protože dopředu neznáte počet sloupců, datové typy, a vlastně ani nevíte jestli první řádek jsou data nebo metadata. Pro relativně málo dat - do 10K řádků to může být praktičtější náhrada databáze než Excel, a u takhle velkých dat indexy na dnešních mašinách zas nejsou až tak podstatné (a JOIN se může implementovat hashjoinem).
Jsem radši, když mi dá někdo data v CSV než v xls, ale že bych v tom chtěl dělat něco náročnějšího - to asi ne. q je šikovné pro menší data, kde chybějící podpora indexů nebo implementace v Pythonu není problém - a výsledek může být rychlejší a hlavně čitelnější, než kdybych totéž řešil sedem nebo awkem.
Deset tisíc řádků a join řekněme přes dvě nebo i tři tabulky q zvládne v pohodě. Ten limit je spíš někde u milionů záznamů.
Ale opravdu záleží, co člověk potřebuje dělat. Mě teď přistává spousta CSV a většinou jen potřebuju ověřit například to, že ve sloupci jsou skutečně kladná čísla (jen jednoduchý příklad). Kvůli tomu se mi nevyplatí dělat schéma a importovat do PG, i když mi tady samozřejmě běží kvůli dalším projektům.
PS: ty CSV jsou tak trošku zlo, ale pořád lepší, než když to lidi posílají jako pole objektů v JSONu - tady už je situace složitější.
Ja celkom chapem, ze postgres je uzitocny, ale napriklad ked chces s tym csv pracovat v nejakej CI pipeline tak sqlite binarka moze byt rychlejsia volba ako spustat postgres pre kazdy pipeline run. (je to len priklad, proste vseobecne je dovod preco sqlite existuje a okrem ineho sa da pouzit aj na toto)
Stařičká Foxpro měla indexy IDX (pro jeden klíč) případně CDX (pro více klíčů). To ale používaly všechny databáze té doby (Foxpro, DBase, Paradox, Clipper). Ten poslední zvládal i obecnější datový formát než DBF, ale pro běžné použití se moc nehodil - spíš pro experimenty. Jak byl výše uvedeno - struktura CSV souborů není pevná, tedy vytvoření obecnějšího datového stroje by se nevyplatilo. Takže standard - import do datavého stroje - další zpacování (souhrny, výstupy).
Zajímavější mi přijdou Relational pipes, které podporují více vstupních i výstupních formátů a více dotazovacích jazyků - kromě SQL třeba Scheme nebo AWK. Škoda jen, že to autor ještě neprohlásil za stabilní.