Nechci nijak hodnotit článek - neznám ani MySQL ani Firebird.
V databázi PostgreSQL mám hrubě přes deset miliónů záznamů. Pro databázi mám vyhrazených 1.5 GB RAM. Největší tabulku (zhruba 9 mil. záznamů) procházím sekvenčně nějakých dvacet vteřin, občas (jednou za měsíc) potřebuju přepočítat nad tabulkou nějaké statistiky, pak mašinka chrastí s disky několik minut. V reálném provozu je ale práce s těmito daty řádově v milisekundách. Takto rozsáhlý objem dat mě nutí psát aplikace jinak - vytvářet pomocné tabuky a krmit je přes triggery. Databáze je složitější o pomocné tabulky a pár funkcí a triggerů, aplikace je napsaná trochu nelogicky (data sypu to jedné tabulky, ale statistiky tahám odjinud), ale v reálném provozu díky tomu položím na lopatky kteroukoli nejrychlejší databázi bez těchto možností. Rychlost databáze pro mne NENÍ podstatná, v objemu miliónů záznamů bude každý databázový stroj pomalý. Podstatnější je, jestli databáze má dostatek prostředků pro vytváření "zkratek" a jestli dovede udržet tyto "zkratky" v konzistentním stavu.
K tomuto nazoru sa ciastocne pridavam. ciastocne preto, lebo pri velkych objemoch dat (nielen poctom zazanmov, ale aj velkostou dat) a netrivialnych manipulaciach s datami je vyladeny postgres asi stale najrychlejsi. Tento clanok by bol fajn, keby autor na zaciatku uviedol, ze testuje vhodnost pouzitia DB na webovy chat s jednou - dvoma tabulkami.
Ja mam v postgresql 8 asi 5GB dat a nemuzu si ji vynachvalit. Ja bych jeste podotknul, ze neni od veci obcas nechat zanalyzovat vsechny tabulky. Planer ma pak statisticke informace o jejich velikosti a dokaze tak lepe optimalizovat dotaz. Musim portvrdit, ze pri vyberu DB u me hrali roli predevsim vlastnosti DB.
ČLÁNKY DO MAILU