Дизайн базы данных?

Question

У нас есть проект, связанный с продажами.

Теперь мы храним запас продуктов в отдельной таблице с именем Stock. Во время продаж, продаж-возврата, покупки и возврата-покупки таблица запасов будет обновлена. Это хорошо работает, но пока мы удаляем или модифицируем одну из продаж или покупок, поддерживать запас становится сложнее.

Я сказал своему боссу, что мы не хотим хранить запас в отдельной таблице, а напишем функцию для расчета запаса из связанных таблиц (sales, purchase, ...). Всякий раз, когда пользователь хочет узнать запас, он вызывает функцию, чтобы получить запас очень легко. Таким образом, нам не нужно думать об обслуживании склада. Я думаю, это хорошая идея.

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

Как я могу спроектировать эту БД? Отдельная таблица Stock лучше или нет?

Answer 1

Аллен Браун (Allen Browne) проводит отличное исследование по этому предмету здесь .

Answer 2

Задумывались ли вы об использовании триггеров для обновления таблицы акций?

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

Аргумент производительности вашего босса тоже действителен. Каждый раз, когда вам нужно количество товаров на складе, вы должны суммировать все транзакции. Если у вас их много, это может стать узким местом в производительности, даже если вы правильно проиндексировали таблицу транзакций, чтобы вы могли сделать сумму из индекса.

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

Answer 3

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

Если ваша база данных должна быть быстрой для транзакций (обновления) и только изредка отчитываться, то нормализуйте как можно больше. Таким образом, легче поддерживать согласованность всех данных. Однако, если вы только изредка обновляете и в основном публикуете отчеты (т.е. читаете или просто извлекаете данные из базы данных), тогда ваш начальник может быть прав, и это может быть лучшим выбором для денормализации. Однако сложнее обрабатывать ошибки и поддерживать целостность данных (вам нужно больше думать о том, что такое «логическая транзакция» и когда отменить все обновления, сделанные до сих пор, когда что-то идет не так).

Answer 4

Каково содержание вашей биржевой таблицы? У вас есть разные акции, где можно хранить один и тот же продукт? Если есть только одна акция, я бы посоветовал против отдельной таблицы или расчетной акции. Расчет запаса может быть довольно сложным и отнимает много времени, особенно если вам приходится делать это чаще, чем выполнять обновления. Затем вы должны включить сумму запаса в свою таблицу продуктов.

Answer 5

В общем, лучше всего иметь нормализованную базу данных. Если у вас есть дубликаты данных, и однажды программное обеспечение не работает должным образом, вы можете получить противоречивые данные, которые никому не нужны.

Для большинства целей расчеты можно сделать достаточно эффективными, чтобы вы могли выполнять их на необработанных данных, как вы предлагаете. Если это представляет проблему в масштабируемости для вашего конкретного проекта, возможно, было бы лучше иметь таблицу с вычисленными значениями. Это никогда не будет рассматриваться как исходные данные и может быть пересчитано в любой точке. Тогда ваши данные в безопасности, и ваши вычисления быстрые.

Другой альтернативой, в зависимости от вашей СУБД, является рассмотрение представления.