По разработке структуры БД

[fish_r]

Дано, в БД есть таблица, например Пользователи, есть другая, например какие то Акты совершенные этими пользователями. Будет возникать потребность суммировать кол-во актов в отношении кого либо из пользователей. Вариантов решений два:
1. Сделать поле для пользователя где вести учет кол-ва актов.
2. Каждый раз когда понадобится делать выборку в таблице актов, в отношении пользователя.

Сразу, чтобы не рубили с плеча, поясню в чем проблема. Если вводить подобные поля, согласно пп 1 то это значит сильно увеличивать риск ошибок связанный с тем, что при любой реорганизации модели обмена надо помнить, что необходимо обновлять значения таких полей, упустишь один раз и можно получить серьезные перекосы в результатах... Вроде бы решение 2 лучше, ведь бд просто заточены под решение задач по выборке, но.... блин, это же такая работа каждый раз! Какое же решение предпочесть??

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

[alexcon314]

Первый вариант очень скользкий, выгоды очень сомнительны, потом поле с учетом актов само по себе избыточно по логике. Ну, т.е. это не юзерская информация в том смысле, что нарушает инкапсуляцию: нафига пользователю знать что он там наделал? Он просто солдат....На худой конец, можно какой-нибудь триггер замутить, если уж очень хочется иметь сумму сразу под рукой.
Лучше оптимизируй второй вариант: индексы, ключи, процедуры хранимые.
Еще такой ход: в отдельной таблице с двума столбцами хранить соответствие user_id <-> job_id. Тут можно избавиться от дублирования записей в актах, когда он выполнен несколькими пользователями, к примеру.

[bifidokk]

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

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

[Korchy]

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

[fish_r]

Спасибо за советы! Про "представления" очень интересно, покавыряю тему. Про денормализацию... , пока не предпологается что записей будет несколько миллионов, а если уже будет тогда решать надо будет привлечением спеца серверника и/или спеца по бд, в общем уже на другом уровне надо будет решать...

[Psycho Tiger]

А данные нужно обновлять оперативно? Как насчет кэширования в редисе на часик для одного пользователя?

[fish_r]

Почитал поверхностно про редисы/мемкешид и т.п. Очень интересно, но пока о таких решениях рано задумываться ( насколько я понял это для нагруженных систем ), но за инфу спасибо! Буду иметь в виду.

[Psycho Tiger]

Вобщем-то да.
Но непонятно – если твоя система не планируется в эксплуатации под хайлоадом – пусть себе БД делает кучу джоинов и считает каждый раз заново – ей всё равно скучать бОльшую часть времени.