Задать вопрос

coodan

Лайки

  • Нормализация БД. Зло или добро?

    Nipheris
    @Nipheris
    Видите ли в чем дело - нормализация это не столько для СУБД и не для приложения ее использующего. Это больше для вас, для разработчика (БД и/или приложения), и для целостности и согласованности данных.

    Безусловно, в продакшене идеальна та БД, структура которой позволяет выполнить наиболее частые (или тяжелые) запросы к БД максимально экономно с точки зрения аппаратных ресурсов (меньше чтений блоков с диска, меньше джоинов, наиболее эффективное использование индексов), и такая структура вовсе не обязательно должна быть в высокой нормальной форме. Однако, есть и другой вопрос - какая БД идеальна для вас, как для разработчика? Избыточность в базе - потенциал для ошибок. Если какую-либо информацию нужно обновить в двух местах (например, цену товара в чеке и общую стоимость заказа) - вы всегда имеете возможность где-то забыть это сделать.

    Именно по причине несовпадения двух структур БД: максимально нормализованной, удобной для разработчика/проектировщика, и оптимизированной для выполнения запросов - стандартный цикл проектирования БД включает в себя этап нормализации до опредленного уровня (хотя бы до 3нф), и последующей денормализации для ускорения конкретных запросов (также, как и построение необходимых индексов). Т.к. денормализация требует усложнения логики работы с базой (те самые обновления в нескольких местах), эту логику (чаще всего это хранимки или триггеры, реже - на стороне приложения) нужно реализовывать максимально аккуратно и формально. Это похоже на написание кода на высокоуровневом языке и последующая его компиляция под конкретную платформу с максимальными оптимизациями. Единственное важное отличие - особенности целевой платформы известны заранее, и компилятор, учитывающий эти особенности, можно написать один раз, а вот особенности работы БД в каждой задаче - свои, поэтому в каждом случае нужно проводить работу по оптимизации БД с нуля.

    Нужно отметить, что в современных системах денормализация схемы - не единственный и не всегда лучший способ повышения производительности. Кэширование часто используемых данных в каком-нибудь memcached - иногда проще и эффективнее, чем денормализация БД и поддержка ее согласованности.
    Ответ написан
    Комментировать
    Комментировать

  • Викторина: как Вы думаете, где ошибка (STL misconception)?

    @MiiNiPaa
    Если it — валидный итератор к контейнеру container, который можно разыменовать, то следущее условие должно когда-либо стать истинным ++it == container.end() и все промежуточные значения it должны быть валидными и разыменовываемыми.

    Можно это обойти, если заставить RingIterator быть равным end в некоторых случаях.
    Ответ написан
    4 комментария
    4 комментария

  • Как сделать так, чтобы std::set при добавлении объектов сравнивал на повторяемость по моим правилам?

    bogolt
    @bogolt
    Указать ваш компаратор:

    std::set<std::shared_ptr<CString>, MyCompare>
    Который будет сравнивать значения внутри умных указателей.

    Чтобы с пониманием делать такие вещи нужен опыт и некоторые навыки чтения литературы.

    upd:
    using namespace std;
typedef shared_ptr<string> SString;

class SharedLess
{
public:
    bool operator() (const SString& a, const SString& b) const
    {
        return *a < *b;
    }
};
    Ответ написан
    13 комментариев
    13 комментариев