У меня есть база данных школьных округов (примерно 15 000 из них и число их увеличивается) и пенсионные планы/льготы, доступные сотрудникам каждого из них. Данные довольно хорошо нормализованы:
- Запись округа связана с 0 или n вариантами пенсионного плана (где n ‹ 10 распределены по 3 объединенным таблицам).
- Запись округа связана с 0 или n льготами (где n ближе к 40 из 1 объединенной таблицы).
- Район также связан с несколькими другими вещами, где количество ассоциаций является номинальным.
Теперь клиент хочет сообщить. И они хотят сообщать очень динамично (подумайте об интеллектуальном плейлисте iTunes, в котором можно добавлять/удалять правила для любой собственности любого района, плана или льготы). Мне нужно разрешить им запрашивать любую собственность округа, его пенсионные планы или льготы и возвращать все.
Чтобы не усложнять (на данный момент) и избежать дублирования данных, я настроил пару представлений (тсссс, я знаю), которые просто позволяют мне получать доступ к данным таким образом, что любая запись 1 района фактически имеет 1- отношение к 1 с представлением all_retirement_plans
и запись 1 к 1 с представлением all_benefits_plans
. Это дает мне чистый набор объединений, который приводит к унифицированному набору результатов, но, очевидно, имеет свой собственный набор проблем, с которыми я столкнусь раньше, чем позже...
А именно, по мере добавления новых данных он будет работать смехотворно медленно.
Я ищу несколько советов по денормализации. Я думал о таблице отчетов, которая делает то же, что и представления, но может быть проиндексирована. Я также подумал о том, чтобы сбросить весь этот набор данных о районах в MongoDB (или аналогичный). Я уверен, что есть и другие варианты, но я буду играть методом проб и ошибок, поэтому я надеюсь, что кто-то здесь может посоветовать мне способ, который поможет мне найти разумное решение.
Суть в том, что мне нужно иметь возможность хранить около 15 000 (и растущих) записей по районам вместе с большим количеством дополнительных метаданных, а затем создавать отчеты по этим данным на очень детальном уровне. У кого-нибудь есть какие-нибудь мысли или советы помимо того, куда меня завели мои собственные размышления? Я пытаюсь опередить проблемы, которые, как я знаю, грядут.
all_retirement_plans
иall_benefits_plans
используютGROUP_CONCAT
для агрегирования и объединения всех разных строк? - person ruakh   schedule 21.02.2013all_benefits_pans
содержит запись округа, содержащую каждое свойство каждого преимущества. Он добавляет до ~ 100 столбцов. - person Rob Wilkerson   schedule 21.02.2013PIVOT
? - person ruakh   schedule 21.02.2013benefits
), много раз. - person Rob Wilkerson   schedule 21.02.2013PIVOT
я подразумеваю концептуальный поворот. MySQL не поддерживает фактическое ключевое словоPIVOT
, но вы можете использовать большое количествоJOIN
для достижения примерного эффектаPIVOT
. - person ruakh   schedule 22.02.2013