Administrace komentářů

Na toto bych šel cestou několika tabulek. Sestavil bych si typovou hierarchii, která by popisovala ukládané objekty. Například v e-shopu se to udělá celkem snadno. Tím vyplynou skupiny parametrů, které se typicky vyskytují spolu. Každé takové skupině bych dal jednu tabulku se sloupcem pro každý parametr ve skupině. Žádná dědičnost v databázi, ta by byla jen na papíře pro identifikaci skupin. Skupiny by byly jinak už placaté – parametr by byl identifikován názvem skupiny a názvem parametru ve skupině.

Každý objekt by byl uložen spolu se sadou základních parametrů v centrální tabulce a vazbami 1:1 by se přidávaly tabulky skupin parametrů. Tím pádem nebude příliš mnoho ani prázdných sloupců, ani tabulek.

Číselníky bych obcházel přes ENUM, pokud by to šlo. Pokud ne, tak bych se snažil alespoň číselníky sdílet mezi parametry, například u kabelu je konektor na začátku i na konci a oba jsou ze stejného číselníku. Nabízí se otázka, zda mít jeden velký číselník, nebo hodně malých.

Pokud by měl mít parametr více hodnot, pak bych využil SET nebo bitmapy a číselníky. Málokdy bude potřeba, aby parametr nabýval hodnot z množiny větší než těch 64 prvků na které stačí BIGINT. Pokud to nebude stačit, M:N a tedy další tabulce se nevyhneme.

Určitě je však potřeba mít nad tímhle monstrem postavený bytelný framework, který to zvládne automaticky řešit a hlídat. Udržovat to jakkoliv ručně by byl slušný horor.

Pro malé databáze a relativně jednoduché modely se však hodí je serializovat do JSONu a nechat v jednom sloupečku (ať už pomocí nástrojů databáze nebo na úrovni aplikace). Šetří to čas na počátku vývoje a konverze na robustnější řešení je docela snadná.

Důležité v obou případech je, aby platilo, že jedna entita má někde jeden řádek. A že parametry mají sloupečky. Jakmile se tohle poruší, je horor s tím pracovat.