it-swarm-eu.dev

Mám použít bitový řetězec PostgreSQL?

Dozvěděl jsem se o bit string typ dat v poslední době a jsem docela zvědavý na:

  1. Ve spodní části tato stránka dokument je věta:

    ... plus 5 nebo 8 bytů nad hlavou v závislosti na délce řetězce

  2. Jak se zpracovávají bitové řetězce v jiných jazycích, jako je PHP, Java, C #, C++ atd., Pomocí ovladačů, jako je Npgsql, ODBC atd.

Pro otázku č. 1 bude používání smallint nebo bigint mnohem efektivnější úložiště a pravděpodobně by nabídlo zvýšení výkonu, protože celá čísla jsou podporována všude. Většina programovacích jazyků zvládne bitové operace na celá čísla s lehkostí. Pokud je tomu tak, jaký je smysl zavedení datového typu bitového řetězce? Je to jen pro případy, které vyžadují velké množství bitových masek? Možná indexování bitového pole? Jsem více zvědavý, jak se v PostgreSQL provádí indexování bitových polí.

Pro # 2 jsem zmatený, víc než zvědavý. Co když například uložím bitové masky týdne v bitovém poli (7), jeden bit na den, přičemž nejnižší bit představuje pondělí. Potom dotazuji na hodnotu v PHP a C++. Co získám? V dokumentaci se uvádí, že budu mít bitový řetězec, ale bitový řetězec není něco, co mohu použít přímo - jako s celá čísla. Pak bych se v tomto případě měl vzdát bitového pole?

Může někdo propracovat, proč a kdy bych měl používat bit nebo bit různé?

postgresql
18
Jackey Cheung

Pokud máte jen několik proměnných, uvažoval bych o zachování samostatných boolean sloupců.

  • Indexování je snadné. Zejména indexy výrazů jsou snadné.
  • Podmínky pro dotazy a částečné indexování jsou snadno zapisovatelné a čitelné a smysluplné.
  • Booleovský sloupec zabírá 1 bajt. Pouze pro několik proměnných zabírá nejméně místa.
  • Na rozdíl od ostatních voleb povolí sloupce boolean NULL hodnoty pro jednotlivé bity, pokud to potřebujete. Pokud tak neučiníte, můžete vždy definovat sloupce NOT NULL.

Optimalizace úložiště

Pokud máte více než plných proměnných, ale méně než 33, integer sloupec může vám poslouží nejlépe. (Nebo bigint až pro 64 proměnných.)

  • Zabírá 4 bajty na disku.
  • Velmi rychlé indexování pro přesné shody (operátor =).
  • Zpracování jednotlivých hodnot může být pomalejší/méně pohodlné než u bit string Nebo boolean.

S ještě více proměnnými, nebo pokud chcete hodně manipulovat s hodnotami, nebo pokud nemáte obrovské tabulky a místo na disku/RAM není problém, nebo si nejste jisti, co vybrat, zvážil bych bit(n) nebo bit varying(n) .

  • Zabírá nejméně 5 bajtů (nebo 8 pro velmi dlouhé řetězce) plus 1 bajt pro každou skupinu 8 bitů (zaokrouhleno nahoru).
  • Můžete přímo používat funkce bitových řetězců a operátory .

Příklady

Pro pouze 3 bity informací, jednotlivé sloupce boolean získají 3 bajty, integer potřebuje 4 bajty a a bit string 6 bajtů (5 + 1).

Pro 32 bitů informací potřebuje integer stále 4 bajty, bit string Zabírá 9 bajtů za stejnou ( 5 + 4) a sloupce boolean zaujímají 32 bytů.

Další čtení

18
Erwin Brandstetter

Všechny typy PostgreSQL jsou užitečné pro některé věci a méně užitečné pro ostatní. Obecně získáte více z obav o funkčnost nejprve ao výkon později. PostgreSQL má velké množství funkcí pro manipulaci s různými druhy datových typů a ty nejsou výjimkou.

Očekával bych, že na aplikační vrstvě, pokud to váš ovladač db nezvládne převedením typu, získáte řetězcovou reprezentaci a musíte to zvládnout. Z tohoto důvodu to může nebo nemusí být užitečné.

Tam, kde je pravděpodobné, že je užitečné, když chcete vybrat záznamy založené na bitových operacích, jako je bitový nebo bitový tok, nebo jinak manipulovat s daty v dotazech SQL. Pokud tak neučiníte, mnoho dalších esoterických funkcí PostgreSQL je méně užitečné.

Všimněte si také pro delší řetězce binárních informací existuje velké objektové rozhraní, které vám umožní provádět streaming atd. A bytea rozhraní, které umožňuje kompaktnější reprezentaci řetězců.

tl; dr: Pokud to potřebujete, budete to vědět. Jinak to uložte do části „vyhrazeno pro budoucí použití“.

3
Chris Travers