Docela by me zajimalo, jake je doporucovane reseni pro tabulku s heterogennimi daty. Dam priklad - chci ukladat sekvencni vyskyt ruznorodych udalosti, samozrejme jsou tam nejaka data (sloupce) jednotna, typicky treba cas vyskytu nebo typ udalosti, ale zaroven se jednotlive typy udalosti lisi v popisnych atributech. Pokud je tech typu omezene mnozstvi, prijde mi dedicnost jako vhodna aplikace, tady nejde o ORM, ale ta data k tomu podle me prirozene vedou...
Obecně doporučované řešení jsou normální formy - v relačních databázích. V moderních databázích si můžete pomoci neatomickými typy - JSON, XML - anebo můžete použít NoSQL databáze. Za univerzálnost se ale platí. V relační databázi NULL mne stojí jeden BIT. V případě stovek sloupců už může být docela drahé zjistit jestli je hodnota NULL nebo ne. U XML, JSONu mne zase stojí rozbalení dokumentu, parsování, iterace. Záleží na okolnostech.
Můžete si pomoci funkcionálním indexem, případně nějakým speciálním indexem - v Postgresu např. GIN index pro jsonb typ - něco jako funkcionální index MySQL učitě má. Pokud ale uděláte full scan, tak Vám nic nepomůže - jedině se chytat jiných relačních (atomických) atributů a do neatomických typů jít až nakonec.
Díval jsem se na to, ale vypadá to, že to bude fungovat od verze 5.7.x, takže to zatím nepůjde, ale až bude chvilka, vyzkouším to na dev. serveru.
Prozatím jsem to vyřešil tak, že připojím k tabulce se společnými vlastnostmi tabulku specifickou pro daný typ. Ovšem tím musím nejspíše řešit celou logiku v aplikaci. Zatím to není problém.
Vypadá to, že jsem si v databázi udělal malého krakena a to v tom smyslu, že záznamy nespojuji pomocí primárního indexu, ale pomocí hashe, který je uložen v Varchar typu a nad ním je index.
Je to proto, že když generuji záznamy napříč tabulkami, tak nejprve vytvořím hash a pak jím sváži další záznamy, protože v tu chvíli neznám id záznamu. Hash ovšem může obsahovat všechny znaky ASCII.
pokud máte append only data, pak můžete použít sloupcové databáze. Tam tabulky se stovkami sloupců nejsou problém. Nicméně zase, dědičnost je špatně - obvykle - třeba u workflow systémů je to jedno - tam se většinou pracuje s izolovanými objekty a OOP přístup tam ničemu nevadí. Pokud ale databázi používáte pro agregaci, řazení, reporting tak je dědičnost koncept, který ve stávajících databázích není dobře podporovaný.
Predpokladam, ze nezpracovavate cele db vety, ale jedete jen po par atributech. Pokud vam jde o pohodli, pouzijte sloupcove baze. Pokud se vam v dotazech objevuji urcite sloupce pomerne pospolu a standardni sloupcove baze to uz neutahnou, musite jit na big-data reseni s log-merge strukturami a shlukovanim sloupcu v souvislych datovych blocich. Tohle umi principialne HBase, ale to je "nestastne" reseni kvuli svemu pomalemu podkladu "Hadoopu", resp. hdfs. Nejlepsi je proto u vykonostne narocnych reseni zaplatit profesionala.
Dekuju vsem za odpovedi, asi jsem mel napsat, ze mi jde o relacni DB se zvlastnim prihlednutim k PostgreSQL (protoze Pavel S. je na PG odbornik a shodou okolnosti je to databaze, se kterou pracujeme u nas nejvice). Podobnych prikladu je vic, resime to vselijak, ale nejak se mi nechce pridavat jeste dalsi technologii - snad by mohlo pomoci i vyuziti JSON storage. Zajima me to ale i obecne, co s tim kdo pripadne dela.
Jedná-li se o různé, nepříbuzné typy záznamů, je první chybou dávat je do jediné tabulky, je možno pro každý typ vytvořit jednu.
Jedná-li se o vzájemně příbuzné typy (podtřídy), není pro ně RDB vhodná, ale dá se to ojebat klasickými postupy ORM - buďto pro každý podtyp udělat extra tabuli, nebo to narvat do obecné tabule.
Další možností je použití neschématové DB, tj. dokumentové či jiné, tam je uložení vaším problémem, ne problémem databáze.