|
|
|||||
По разработке структуры БД
Дано, в БД есть таблица, например Пользователи, есть другая, например какие то Акты совершенные этими пользователями. Будет возникать потребность суммировать кол-во актов в отношении кого либо из пользователей. Вариантов решений два:
1. Сделать поле для пользователя где вести учет кол-ва актов. 2. Каждый раз когда понадобится делать выборку в таблице актов, в отношении пользователя. Сразу, чтобы не рубили с плеча, поясню в чем проблема. Если вводить подобные поля, согласно пп 1 то это значит сильно увеличивать риск ошибок связанный с тем, что при любой реорганизации модели обмена надо помнить, что необходимо обновлять значения таких полей, упустишь один раз и можно получить серьезные перекосы в результатах... Вроде бы решение 2 лучше, ведь бд просто заточены под решение задач по выборке, но.... блин, это же такая работа каждый раз! Какое же решение предпочесть?? ПС. Здесь ситуация примерная и сильно упрощенная, в реале все конечно немного сложнее ( больше таблиц и подобных полей и тд. ), упростил чтобы яснее очертить проблему |
|
|||||
listener
|
Первый вариант очень скользкий, выгоды очень сомнительны, потом поле с учетом актов само по себе избыточно по логике. Ну, т.е. это не юзерская информация в том смысле, что нарушает инкапсуляцию: нафига пользователю знать что он там наделал? Он просто солдат....На худой конец, можно какой-нибудь триггер замутить, если уж очень хочется иметь сумму сразу под рукой.
Лучше оптимизируй второй вариант: индексы, ключи, процедуры хранимые. Еще такой ход: в отдельной таблице с двума столбцами хранить соответствие user_id <-> job_id. Тут можно избавиться от дублирования записей в актах, когда он выполнен несколькими пользователями, к примеру. |
|
|||||
Регистрация: Jan 2011
Сообщений: 200
|
Уже написал вам в чатике. Почитайте про денормализацию БД. Если количество подобных актов будет исчисляться миллионами, то легче завести счетчик в таблице Пользователи, чем постоянно делать выборку.
Ну и плюсом все зависит от архитектуры проекта, если количество условных записей нужно знать не при каждом обращении пользователя к серверу, то можно и выборку делать, а можно и в кеше их хранить и обновлять с каким-то периодом. |
|
|||||
Возможно вам помогут "представления". Это тот же запрос, но уже со сделанной выборкой в виде итоговой таблицы. Выборка переделывается только при изменении данных в исходных таблицах, так что для каждого просмотра выборка перепроизводиться не будет.
__________________
interplanety |
|
|||||
Спасибо за советы! Про "представления" очень интересно, покавыряю тему. Про денормализацию... , пока не предпологается что записей будет несколько миллионов, а если уже будет тогда решать надо будет привлечением спеца серверника и/или спеца по бд, в общем уже на другом уровне надо будет решать...
|
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
А данные нужно обновлять оперативно? Как насчет кэширования в редисе на часик для одного пользователя?
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Вобщем-то да.
Но непонятно – если твоя система не планируется в эксплуатации под хайлоадом – пусть себе БД делает кучу джоинов и считает каждый раз заново – ей всё равно скучать бОльшую часть времени.
__________________
Тут мужик танцует и поёт про флэш |
Часовой пояс GMT +4, время: 07:37. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|