2 вопроса о философии и передовой практике в разработке баз данных

Question

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

Очевидно, что здесь есть компромисс, и я думаю, что любой скажет, что лучший ответ на этот вопрос: «зависит» или «это сочетание двух».Но я на самом деле не настолько удобен или достаточно опытен, чтобы в одиночку рассуждать на эту тему.Может ли кто-то поделиться некоторыми мыслями?

Кроме того, еще один другой вопрос: должна ли база данных быть «снимком» определенного момента времени или база данных накапливает всю информацию за предыдущий раз, позволяя отследить произошедшее?Например, предположим, что я моделирую банковский счет.Должен ли я сохранять баланс только в тот день или все транзакции одного, и из этих транзакций выводить баланс?

Любой указатель на такого рода вещи, которые каким-то образом более глубоки в базе данныхдизайн?

Спасибо

Answer 1

Мой быстрый ответ - хранить все в базе данных. Стоимость хранения намного ниже, чем стоимость обработки , если говорить об очень масштабных приложениях. В небольших приложениях данных будет гораздо меньше, поэтому хранилище все равно будет подходящим решением.

Большинство СУБД чрезвычайно хороши в обработке огромных объемов данных, поэтому, когда существуют миллионы / триллионы записей, данные все равно можно извлечь сравнительно быстро, чего нельзя сказать об обработке данных вручную каждый раз.

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

processing_time = data_size * num_users

---

Чтобы ответить на ваш другой вопрос, я думаю, что было бы лучше ввести «снимок» определенного момента только тогда, когда данные достигают такого высокого значения, что время обработки будет значительным .

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

Answer 2

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

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

Есть и другие вещи, которые, возможно, не нужно хранить исторически. В большинстве заявлений нам не нужно знать, что вы были Джуди Джонс 2 года назад и сейчас Джуди Смит (заявление на HR обычно исключение).

Answer 3

Это зависит от :) Сохранение производных данных в базе данных может быть полезно, потому что это позволяет вам реализовать ограничения и другую логику против них. Кроме того, он может быть проиндексирован или вы можете поместить вычисления в представление. В любом случае, попытайтесь использовать Boyce-Codd / 5th Normal Form в качестве руководства для разработки вашей базы данных. Вопреки тому, что вы иногда слышите, нормализация не означает, что вы не можете хранить производные данные - это просто означает, что данные не должны быть получены из неключевых атрибутов в одной таблице.

По сути, любая база данных - это запись известных фактов в определенный момент времени. Большинство баз данных содержат некоторый компонент времени, и некоторые данные сохраняются, а некоторые нет - требования должны диктовать это.

Answer 4

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

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

Что касается банковской метафоры, определенно сохраняйте полную запись всех транзакций. Храните любые данные, которые имеют отношение к делу. База данных должна быть хранилищем данных прошлого и настоящего. Журналы аудита и т. Д. «Текущее состояние» может быть вычислено на лету или может быть сохранено в плоской таблице и пересчитано во время записи в другие таблицы (триггеры хороши для такого рода вещей), если этого требует производительность.

Answer 5

Мне нравится динамическое программирование (ничего не вычислять по кругу). Если вы не ограничены в пространстве и можете использовать устаревшие данные, предварительно рассчитайте их и сохраните в БД. Это даст вам дополнительное преимущество, поскольку вы сможете выполнять проверку работоспособности и обеспечивать постоянство данных.

Но, как уже отвечали другие, это зависит:)

Answer 6

Вы ответили на свой вопрос.

Любой выбор зависит от требований приложения.

Иногда скорость выигрывает, иногда космос выигрывает. Иногда точность данных выигрывает, иногда снимки выигрывают.

Хотя у вас может не быть возможности сказать, что важно, человек, для которого вы решаете проблему, должен ответить на этот вопрос за вас.