Krátká odpověď na nadpis :Ne
Trochu delší odpověď :
Měli byste se naučit používat pole, když je to vhodné. Pole samy o sobě nejsou špatným designem, jsou atomické jako pole měnící charakter (pole postav, ne?) a existují proto, aby nám usnadnily život a zrychlily a odlehčily naše databáze. Existují problémy týkající se přenositelnosti (většina databázových systémů nepodporuje pole nebo to dělá jiným způsobem než Postgres)
Příklad:
Máte blog s příspěvky a štítky a každý příspěvek může mít 0 nebo více štítků. První věc, která vás napadne, je vytvořit jinou tabulku se dvěma sloupci postid a tagid a přiřaďte značky v této tabulce.
Pokud potřebujeme prohledávat příspěvky pomocí tagid, pak je nutná další tabulka (samozřejmě s příslušnými indexy).
Pokud však chceme, aby se informace o značce zobrazovaly pouze jako doplňkové informace příspěvku, pak můžeme do tabulky příspěvků snadno přidat sloupec s celočíselným polem a extrahovat informace odtud. To lze stále provést pomocí další tabulky, ale použití pole snižuje velikost databáze (není potřeba dalších tabulek nebo řádků navíc) a zjednodušuje dotaz tím, že nám umožňuje provádět naše výběrové dotazy se spojením o jednu tabulku méně a zdá se snazší na pochopení. lidským okem (poslední část je v oku pozorovatele, ale myslím, že zde mluvím za většinu). Pokud jsou naše značky předem načteny, není nutné ani jedno spojení.
Příklad může být ubohý, ale je první, který mě napadl.
Závěr :
Pole nejsou nutná. Mohou být škodlivé, pokud je používáte nesprávně. Můžete žít bez nich a mít skvělou, rychlou a optimalizovanou databázi. Když uvažujete o přenositelnosti (např. přepsání vašeho systému pro práci s jinými databázemi), pak nesmíte používat pole.
Pokud jste si jisti, že zůstanete u Postgresu, můžete pole bezpečně používat tam, kde uznáte za vhodné. Existují z nějakého důvodu a nemají špatný design ani nevyhovují. Když je použijete na správných místech, mohou trochu pomoci s jednoduchostí databázových struktur a vašeho kódu, stejně jako s optimalizací prostoru a rychlosti. To je vše.