Как далеко взять нормализацию?
Выполните простую операцию reduce:
const data = [{
index: 0,
value: 3
},
{
index: 0,
value: 3
},
{
index: 0,
value: 3
},
{
index: 1,
value: 3
},
{
index: 1,
value: 3
},
{
index: 2,
value: 3
}, {
index: 2,
value: 3
}
];
const modified = data.reduce((val, acc) => {
if (acc[val.index]) {
acc[val.index].push(val);
} else {
acc[val.index] = [{
index: [val.index],
value: [val.value]
}];
}
return acc;
}, {});
console.log(modified);12 ответов
Денормализация имеет преимущество быстрых SELECT с на выполнении больших запросов.
Недостатки:
-
требуется больше кодирования и время для обеспечения целостности (который является самым важным в случае)
-
, Это медленнее на DML (ВСТАВЛЯЮТ/ОБНОВЛЯЮТ/УДАЛЯЮТ)
-
, Это занимает больше места
Что касается оптимизации, можно оптимизировать или для более быстрых запросов или для более быстрого DML (как правило, эти два являются антагонистами).
Оптимизация для более быстрых запросов часто подразумевает данные дублирования, быть этим денормализация, индексы, дополнительные таблицы что.
В случае индексов, RDBMS делает это для Вас, но в случае денормализации, необходимо будет кодировать его сами. Что, если Department перемещения к другому Office? Необходимо будет зафиксировать его в трех таблицах вместо одной.
Так, как я вижу с названий Ваших таблиц, не будет миллионов записей там. Таким образом, необходимо нормализовать данные, это будет simplier для управления.
Нормализуйте, пока это не причиняет боль, затем денормализуйте, пока это не работает
Стоимость соединений не должна волновать Вас слишком много по сути (если Вы не пытаетесь масштабироваться миллионам пользователей, в этом случае абсолютно необходимо волноваться).
я был бы более обеспокоен эффектом на код, который это называет этим. Нормализованные базы данных намного легче к программе против и почти всегда приводят к лучшей эффективности в рамках самого приложения.
Тем не менее не нормализуют вне границ причины. Я видел нормализацию для пользы нормализации, которая обычно заканчивается в базе данных, которая имеет одну или две таблицы фактических данных и 20 таблиц, заполненных только внешними ключами. Это - ясно излишество. Правило, которое я обычно использую: Если бы данные в столбце были бы иначе дублированы, они должны быть нормализованы.
Всегда нормализуйте до необходимый для удаления проблем целостности БД (т.е. потенциал дублированные или недостающие данные).
, Даже если было увеличение производительности от денормализовывания (который обычно является не случаем), цена потери целостности данных слишком высока для выравнивания по ширине.
Просто спрашивают любого, кто должен был работать над устранением всех неясных проблем от унаследованной базы данных, предпочли ли они хорошие данные или незначительный (если таковые имеются) увеличения скорости.
кроме того, как упомянуто John - если Вы действительно заканчиваете тем, что нуждались в денормализованных данных (для скорости/создания отчетов/и т.д.) затем, создают его в отдельной таблице, сохраняя необработанные данные.
DBA должен быть затронут, не нормализован ли Ваш дб правильно для начала. После того, как Вы тщательно измерили уровень и решили, что у Вас есть узкие места, можно начать денормализовывать, но я был бы чрезвычайно осторожен.
Вы не должны смотреть на денормализовывание перед попыткой всего остального.
производительность этого действительно проблема? Ваша база данных имеет какие-либо функции, которые можно использовать для ускорения вещей, не ставя под угрозу целостность? Можно ли увеличить производительность путем кэширования?
Я был бы больше всего обеспокоен DBAs, кто предупреждает Вас о стоимости соединений, если Вы не находитесь в очень патологической ситуации.
Лучше сохранить ту схему в Третьей Нормальной форме и позволить Вашему DBA для жалобы на стоимость соединений.
Если Вы используете Целые числа (или BIGINT) как идентификатор, и они - кластеризованный первичный ключ, необходимо быть в порядке.
, Хотя это походит, это всегда было бы быстрее для нахождения офиса из проекта, поскольку Вы всегда ищете первичные ключи, использование индексов на внешних ключах будет иметь значение, минимальное, поскольку индексы покроют первичные ключи также.
, Если Вы когда-нибудь находите, что потребность позже денормализовывает данные, можно составить таблицу кэша в расписании или триггере.
Нормализуйте для моделирования понятий в дизайне и их отношений. Думайте о том, что отношения могут изменить, и что изменение как этот будет означать с точки зрения Вашего дизайна.
В схеме Вы отправили, существует то, что смотрит на меня как явная ошибка (который не может быть ошибкой, если у Вас есть особый случай с точки зрения того, как Ваша организация работает) - существует неявное предположение, что каждый отдел находится точно в одном офисе, и что все сотрудники, которые находятся в той же работе отдела над тем офисом.
, Что, если отдел занимает два офиса?
, Что, если сотрудник номинально принадлежит одному отделу, но работает из другого офиса (принимающий Вас направляют в физические офисы)?
В примере брошенный индексный набор правильно на таблицах должен позволить соединениям происходить чрезвычайно быстро и масштабируется хорошо к 100 000 с строк. Это обычно - подход, который я проявляю для обхождения проблемы.
существуют времена, хотя это, которое данные записаны однажды и выбранный для остальной части его жизни, где действительно не имело смысла делать дюжину соединений каждый раз.
Не денормализовывать.
Дизайн Ваши таблицы согласно принципам простого и саунд-дизайна, которые помогут реализовать остальную часть Вашей системы. Легкий создать, заполните, используйте и администрируйте базу данных. Легкий и быстрый к выполнению запросов и обновлениям против. Легкий пересмотреть и расширить дизайн таблицы, когда ситуация призывает, чтобы он, и ненужный сделал так по легким и переходным причинам.
Один набор принципов разработки является нормализацией. Нормализация приводит к таблицам, которые легки и быстры для обновления (включая вставки, и удаляет). Нормализация устраняет аномалии обновления и устраняет возможность базы данных, которая противоречит себе. Это предотвращает большую ошибки путем создания их невозможными. Это также предотвращает много узких мест обновления путем создания их ненужными. Это хорошо.
существуют другие наборы принципов разработки. Они приводят к проектам таблицы, которые меньше, чем полностью нормализованы. Но это не "денормализация". Это - просто другой дизайн, несколько несовместимый с нормализацией.
Один набор принципов разработки, который приводит к радикально другому дизайну от нормализации, является дизайном схемы "звезда". Схема "звезда" очень быстра для запросов. Даже крупномасштабные соединения и агрегирования могут быть сделаны в разумный срок, учитывая хороший DBMS, хороший физический дизайн и достаточно аппаратных средств, чтобы сделать задание. Как Вы могли бы ожидать, схема "звезда" переносит аномалии обновления. Необходимо программировать вокруг этих аномалий, когда Вы совершенствуете базу данных. Вы для желания будет обычно нужен плотно управляемый и тщательно созданный процесс ETL, который обновляет схему "звезда" от другого (возможно, нормализованный) источники данных.
Используя данные, хранившие в схеме "звезда", существенно легко. Настолько легко, что с помощью некоторого OLAP и сообщая о механизме, можно получить всю информацию, необходимую, не пишущий кода, и не жертвуя производительностью слишком много.
Это берет хороший и несколько глубокий анализ данных для разработки хорошей нормализованной схемы. Ошибки и пропуск в анализе данных могут привести к неоткрытым функциональным зависимостям. Эти неоткрытые FDs приведут к невольным отклонениям от нормализации.
Это также берет хороший и несколько глубокий анализ данных, чтобы разработать и создать хорошую схему "звезда". Ошибки и пропуск в анализе данных могут привести к неудачному выбору в размерах и гранулярности. Это сделает ETL почти невозможным создать, и/или сделать информационную несущую способность звезды несоответствующей для появляющихся потребностей.
Хороший и несколько глубокий анализ данных не должен быть оправданием за аналитический паралич. Анализ должен быть правильным и довольно завершенным в короткий срок. Короче для меньших проектов. Разработка и реализация должна смочь пережить некоторые последние дополнения и исправления к анализу данных и к требованиям, но не устойчивому потоку изменений требований.
Этот ответ подробно останавливается на Вашем исходном вопросе, но я думаю, что это важно для быть разработчиком базы данных.