Задача:

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

Собственно, как наиболее проше это можно реализовать архитектурно на таблицах MySQL, чтобы можно было в итоге потом отслеживать изменения балансов.

Здравствуйте, MasterMind, Вы писали:

MM>Задача:

MM>1. Есть клиент которому на некий баланс кладутся деньги, а периодически могут и обратно сниматься.
MM>2. Этот клиентский баланс должен периодически по оказываемых услугам уменьшаться до нулевого.

MM>Собственно, как наиболее проше это можно реализовать архитектурно на таблицах MySQL, чтобы можно было в итоге потом отслеживать изменения балансов.



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

Здравствуйте, MasterMind, Вы писали:

MM>Задача:

MM>1. Есть клиент которому на некий баланс кладутся деньги, а периодически могут и обратно сниматься.
MM>2. Этот клиентский баланс должен периодически по оказываемых услугам уменьшаться до нулевого.

MM>Собственно, как наиболее проше это можно реализовать архитектурно на таблицах MySQL, чтобы можно было в итоге потом отслеживать изменения балансов.

Вы можете вести две отдельные таблицы. Одна таблица хранит кредиты (Credit), вторая долги клиента (Debt). В этом случае текущий баланс клиента, есть сумма актуальных значений по данным таблицам. В этих таблицах могут быть ссылки на операционные таблицы, к примеру платежей (Payments) и оказанных услуг (Charges), чтобы можно было понять из чего собственно складывается кредит или дебет.

Здравствуйте, MasterMind, Вы писали:

Какие ожидаются объемы и какая нагрузка?

Здравствуйте, MasterMind, Вы писали:

MM>1. Есть клиент которому на некий баланс кладутся деньги, а периодически могут и обратно сниматься.
MM>2. Этот клиентский баланс должен периодически по оказываемых услугам уменьшаться до нулевого.

MM>Собственно, как наиболее проше это можно реализовать архитектурно на таблицах MySQL, чтобы можно было в итоге потом отслеживать изменения балансов.


Счёт и проводки по счёту (приход/расход).

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, MasterMind, Вы писали:

W>Какие ожидаются объемы и какая нагрузка?


Минимальная, в районе 100 клиентов.

Здравствуйте, merlin88, Вы писали:

M>Здравствуйте, MasterMind, Вы писали:

MM>>Задача:

MM>>1. Есть клиент которому на некий баланс кладутся деньги, а периодически могут и обратно сниматься.
MM>>2. Этот клиентский баланс должен периодически по оказываемых услугам уменьшаться до нулевого.

MM>>Собственно, как наиболее проше это можно реализовать архитектурно на таблицах MySQL, чтобы можно было в итоге потом отслеживать изменения балансов.

M>Вы можете вести две отдельные таблицы. Одна таблица хранит кредиты (Credit), вторая долги клиента (Debt). В этом случае текущий баланс клиента, есть сумма актуальных значений по данным таблицам. В этих таблицах могут быть ссылки на операционные таблицы, к примеру платежей (Payments) и оказанных услуг (Charges), чтобы можно было понять из чего собственно складывается кредит или дебет.



А если, например, одна таблика по ткушему балансу клиента

1. client_balance
client_id
balance (меняется при внесении или выводе)

И история

2. client_balance_history
client_id
amount суииа денег
type_id (тип операции — внесение или вывод)


Но есть доп условие — период в течении которого можно вносить и выводить из балансе клиента.

Вот допустим будет

client_period
id — юник
start datetime
stop datetime
flag — (1 — завершен, 0 — в работе)

Если период завершается по дате, закрыт, открыть новый период и ввести на баланс клиента.

Вот в таком ввиде, что может быть проблемой в итоге? Нужно ли в таблице client_balance_history дополнительно в колонка хранить баланс, до после суммы amount, в таблице client_balance — он должен сменться автоматически сразу.

Здравствуйте, MasterMind, Вы писали:

MM> W>Какие ожидаются объемы и какая нагрузка?

MM> Минимальная, в районе 100 клиентов.

Нагрузка измеряется не в количестве клиентов. А в количестве одновременно работающих и количестве транзакций в секунду.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, MasterMind, Вы писали:

MM>> W>Какие ожидаются объемы и какая нагрузка?

MM>> Минимальная, в районе 100 клиентов.

W>Нагрузка измеряется не в количестве клиентов. А в количестве одновременно работающих и количестве транзакций в секунду.


Транзакций нет как таковых в условии задачи. Просто табличка на 100 клиентов.

Здравствуйте, MasterMind, Вы писали:

MM>Вот в таком ввиде, что может быть проблемой в итоге? Нужно ли в таблице client_balance_history дополнительно в колонка хранить баланс, до после суммы amount, в таблице client_balance — он должен сменться автоматически сразу.

Это ИМХО скорее не проблема, а вопрос избыточности данных. Конечно можно при желании задублировать сумму баланса в client_balance_history.
Здесь надо скорее руководствоваться именно соображениями нагрузки на бд. Иногда проще допустить избыточность и таким образом упростить ряд запросов.
Вы попробуйте представить в какой форме понадобиться выводить эти данные на формах, в отчетах и т.д. и решение придет само собой.
Иногда уже в стадии разработки понимаешь, что структура данных не айс и вносишь изменения в схему.

P.S. Могу порекомендовать ознакомиться с понятием "Нормализация баз данных", необходимо при проектировании реляционных БД. Тогда вы сможете посмотреть на создаваемую структуру несколько иными глазами =)

Здравствуйте, merlin88, Вы писали:

M>Здравствуйте, MasterMind, Вы писали:

MM>>Вот в таком ввиде, что может быть проблемой в итоге? Нужно ли в таблице client_balance_history дополнительно в колонка хранить баланс, до после суммы amount, в таблице client_balance — он должен сменться автоматически сразу.

M>Это ИМХО скорее не проблема, а вопрос избыточности данных. Конечно можно при желании задублировать сумму баланса в client_balance_history.
M>Здесь надо скорее руководствоваться именно соображениями нагрузки на бд. Иногда проще допустить избыточность и таким образом упростить ряд запросов.
M>Вы попробуйте представить в какой форме понадобиться выводить эти данные на формах, в отчетах и т.д. и решение придет само собой.
M>Иногда уже в стадии разработки понимаешь, что структура данных не айс и вносишь изменения в схему.

M>P.S. Могу порекомендовать ознакомиться с понятием "Нормализация баз данных", необходимо при проектировании реляционных БД. Тогда вы сможете посмотреть на создаваемую структуру несколько иными глазами =)


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

Здравствуйте, MasterMind, Вы писали:

MM>Про виды нормализации и денормализацию в средствии оптимизации (объединениям, покрывающим индексам) я знаю. Мне нужно просто быстро накидать решение, с минимальными трудозатрами по времени.

Не хотел обидеть, извините. Можете немного более подробно описать проблему про то доп условие, с которого все началось?

Здравствуйте, MasterMind, Вы писали:

MM> Транзакций нет как таковых в условии задачи. Просто табличка на 100 клиентов.

Я, если что, имел в виду бизнес транзакции, а не транзакции БД. Может, ты неверно понял. В данном случае это операции со счетом: пополнение счета, списание средств со счета, перевод с одного счета на другой.

В общем, если вопрос нагрузки и масштабируемости не волнует, то сгодится любая структура. Например две таблицы: таблица текущих балансов и таблица операций (дата, счет, сумма(+/-), вид операции).