Kdy se vyplatí serializovat v php do db?

- 8 sloupců je v pohodě, jestli lze navrhnout tabulku tak, že tam bude mít každý záznam 8 smysluplných sloupců, určitě takto.
- Serializace je už návrhový ústupek a hodí se spíš tam, kde je třeba ukládat dynamické struktury, jejichž modelování by v relační databázi bylo složité. (Pak je v podstatě relační databáze chybně užívána jako hloupé uložiště, protože jiné databáze by toto zvládly lépe.)
- Lepší to má být v čem? Řešit tady rychlost mi přijde jako hloupost.

snazimse:
> je lepší mít víc sloupců v db tabulce zhruba 6-8, nebo mít dva, jeden použít jako
> unikát a do druhé serializovat veškerá data, která by se až, když si daná funkce vše stáhne proiterovala.

Jako jestli je lepší
• mít strukturovanou databázi a pokaždé si načíst jen co potřebuji,
• nebo mít data na jedné hromadě, pokaždé načítat všechno a to, co obvykle udělá databáze, si odprogramovat sám v PHP?

Já bych řekl, že to je poměrně jednoznačné.

snazimse:
Obecně se dá říct, že v relační databázi by ideálně každá „buňka“ měla obsahovat jednu dál nedělitelnou informaci a zároveň logicky totožná informace by se neměla opakovat ve více buňkách.

Ta první část (jedné „buňce“ odpovídá jeden údaj) je zároveň kritérium pro splnění 1. normální formy ( en.wikipedia.org/wiki/First_normal_form )

Zároveň vztah normalizace a výkonu bych já osobně popsal asi takhle:
- Méně normalizovaná databáze může být¹ rychlá v operacích, se kterými se počítalo a jdou „rozumně udělat“, ale rozsah toho, co jde „rozumně udělat“, je menší.
- Větší normalizace databázi zpomalí v operacích, které šly „rozumně udělat“ i předtím, ale rozšíří okruh toho, co jde „rozumně udělat“.

Extrémní případ by byla databázová tabulka o dvou sloupcích: Identifikátor a serializovaná data záznamu.
Pak skutečně jde velmi rychle vybrat data záznamu podle toho identifikátoru. Jenže to je zároveň asi to jediné, co ta databáze umí „rozumně udělat“.
Kromě toho identifikátoru tabulka nedokáže pracovat s ničím jiným, na žádnou jinou hodnotu se neumí (rozumně) zeptat, změnit ji, řadit podle ní, porovnat, atd.
Jakmile bych od toho chtěl cokoliv jiného než vybrat záznam(y) na základě identifikátoru, půjde to buď složitě (a pomalu), nebo vůbec.

¹ Při rozumném návrhu, poměrně často se stává, že když člověk „optimalizuje rychlost“ bez dostatečných znalostí, je výsledek pomalejší než kdyby to udělal „podle pravidel“.

Joker:
„Kromě toho identifikátoru tabulka nedokáže pracovat s ničím jiným, na žádnou jinou hodnotu se neumí (rozumně) zeptat, změnit ji, řadit podle ní, porovnat, atd.“
To už v dnešní době není tak úplně pravda. Jistě, z hlediska normální formy je lepší mít pro každou hodnotu zvláštní sloupec, ale např. JSONB v PostgreSQL se dá reálně používat jako objekt a dokonce se dá indexovat.