Добавление избыточной информации в базу данных для упрощения модели запросов

Question

Давайте представим, что у меня есть нечто похожее на следующий надуманный пример

ParkingSpace         Car                   ParkingSpaceCar
-------------        -------------         ---------------
Id                   Id                    ParkingSpaceId
                     Date                  CarId

Итак, у меня есть история всех автомобилей, которые когда-либо были выделены для какого-либо конкретного места для парковки, и это здорово.

Но для того, чтобы найти выделенный в данный момент автомобиль, мне нужно выполнить запрос на соответствие самой последней Date в Car, которая добавляет накладные расходы с точки зрения LOC и производительности.

Итак, мой вопрос: допустимо ли добавить поле IsCurrent в ParkingSpaceCar для упрощения извлечения данных, даже если это фактически избыточное поле (поскольку оно может быть получено из уже имеющихся данных).

NB. Мне интересен ответ в общих чертах, я знаю, что приведенный выше пример немного глупый.

Answer 1

Да, иногда уместно делать такие вещи.

Общий термин для этого: denormalizaton : Вы активно нарушаете некоторые правила нормализации в порядкечтобы получить какое-то преимущество (обычно производительность запросов).

Поскольку нормализация имеет много преимуществ, вам следует тщательно продумать, перевешивает ли улучшенная производительность недостатки (например, возможность противоречивых данных).

Answer 2

Хорошо иметь сильно нормализованную модель, как обычно, что дает разработчику много знаний о модели данных домена.

Однако, как только вы начинаете писать запросы, трещины начинают показываться.Это правда, что нормализованная база данных сможет отвечать на каждый запрос и использовать меньше места для хранения данных, но по цене объединения после объединения (например, налоговая ставка по счету берется из таблицы Taxesчерез таблицу TaxesByCounty через таблицу Counties через таблицу Cities) и функцию агрегирования после функции агрегирования (например, вместо стоимости заказа постоянно рассчитывается общая стоимость счета-фактуры)хранения в таблице Invoices .

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

Answer 3

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

Answer 4

Если бы я проектировал базу данных, я сделал бы это так1005 * Я мог бы просто отсортировать все по ParkDate.

Answer 5

Я бы в общих чертах выбрал подход звездной схемы / хранилища данных.

• DimDate (одна строка на дату, первичный ключ kDate)
• DimCar (одна строка на машину,первичный ключ kCar)
• DimParkingSpace (одна строка на парковочное место, первичный ключ kParkingSpace)

Затем создайте таблицу фактов

• FactParkingAllocation (одна строка наcar, date и парковочное место, внешние ключи kDate, kCar, kParkingSpace)

Я бы не стал беспокоиться о флаге в таблице FactParkingAllocation, показывающей текущий, так как вместо этого мне придется часто обновлятьбудет иметь представление о таблице, подмножество которой основано на текущей дате (я оставлю вам логику SQL, поскольку это зависит от вашей СУБД).