Как лучше организовать базу данных веб сервиса типа «домашняя бухгалтерия»?

Question

[Silm]

Захотелось реализовать, что называется из интереса и для опыта, web-сервис для ведения домашней бухгалтерии.

Таких приложений не мало, функционал для пользователей выглядит, как правило, в общих чертах так:

• возможность создать несколько счетов/кошельков
  
• возможность создавать операции: приход/расход/перевод(с одного счета на другой) для каждого кошелька
  
• возможность редактировать совершенные операции
  
• отчеты и графики за выбранные периоды
  

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

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

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

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

Так как лучше спроектировать базу (или базы) данных в таком проекте?

Answer 1

[xmoonlight]

префиксы в именах таблиц с данными такого типа:
user1_operations
user2_operations

Comments

[Silm]

Имеете в виду отдельная таблица операций на каждого юзера?

[xmoonlight]

Silm: да

[Silm]

если честно немного озадачен вашим ответом и ответом Василий = )

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

И как же быть с миграциями и тп..

У меня была похожая мысль, я подумал можно операции для пользователей хранить отдельно, но не в MySQL, а вынести это на NoSQL предположительно MongoDB. Но опыта тут у меня совсем нет, так что просто идея..

[xmoonlight]

Silm:
1. добавление и удаление полей - делается скриптом.
2. несколько серверов и нужна таблица, которая будет указывать кто и где хранится: какой юзер к какому серверу mysql привязан.
3. можно делать пакетные таблицы по ID пользователей и так же по п.2:
users1_10000_operations
users10001_20000_operations

можно использовать noSQL. все имеет право на жизнь.
в любом случае: производительность - нужно тестировать и быть заранее готовым к миграции на другой тип базы данных.

Answer 2

[Vitaly Vitaly]

Приветствую, я сделал бы таким образом, который вы описали, потому-что варианты созданий отдельный таблиц или БД не подходит. Представьте потом какие будут мучения с миграцией.
В вашем случае необходимо стартовать именно с Вашей архитектурой, в добавок вы можете всегда использовать кэш и сделать репликацию mysql, для начала master-slave.

Тем самым, запросы будут выполняться так же к бд, но заносится в кэш, к примеру (на сутки, а если изменение произошло сбросить кэш по этому ключу).