Планирую разрабатывать сервис с большим количеством пользователей. Сервис представляет собой некую личную бухгалтерию, которая будут вести учет доходных и расходных операций. При этом каждый этот тип операции будет делиться на свои категории (еда, машина, жильё и тд). Все операции должны заноситься в таблицу, с указанием даты, суммы, типа операции, категории операции. Все это хорошо работает, когда пользователь только один. Но, если у нас пользователей становится несколько, то таблица операций раздувается значительных масштабах. В итоге работа с этой таблицей может стать крайне затруднительной, а в последствии и не возможной. Т.к. каждый пользователь будет создавать несколько операций в день. при этом планируется, что количество пользователей будет расти. На сколько будет эффективно, создавать для каждого пользователя отдельную. таблицу операций, с уникальным обозначением и дальнейшим ведением учета операций в этой таблице? Не приведет ли это к большому объему самой БД и не затруднит ли в дальнейшем получение информации из базы?
Главный вопрос: лучше для чего именно? Определитесь сначала с конкретными критериями, а уже после проектируйте вашу БД. При отсутствии опыта почитайте статьи, рекомендации и просто следуйте им. Когда вылезут проблемы - тогда и решайте их. Вопрос производительности решения решается нагрузочным тестированием.
если у нас пользователей становится несколько, то таблица операций раздувается значительных масштабах.
Для СУБД значительные масштабы начинаются где-то с сотни миллионов записей. Миллион - это средненько... Так что у твоих пользователей, даже всех вместе, нет практически никаких шансов добраться даже до средних объёмов. В общем, не засоряй себе мозг.
На сколько будет эффективно, создавать для каждого пользователя отдельную. таблицу операций, с уникальным обозначением и дальнейшим ведением учета операций в этой таблице?
С точки зрения архитектора/разработчика БД отдельная БД для каждого пользователя - это невменяемый бред.
Прочитайте книжку - "Программирование баз данных SQL. Типичные ошибки и их устранение"
Вам ещё рано проектировать БД, пока не прочтёте, даже не прикасайтесь к БД.
Che_boo, Я не помню, было ли в книге детально расписана 3 нормальная форма, если нет, то вот любая БД, должна соответствовать минимум 3 нормально форме (можно и выше, но минимум 3). Понижать форму можно, но когда, вы поймёте уже после освоения базовых знаний. Для начала ваша цель 3 нормальная форма и база знаний.
Ну и конечно почитать про реляционную алгебру, чтобы понимать как строить запросы.
В итоге работа с этой таблицей может стать крайне затруднительной, а в последствии и не возможной.
это ты придумал
На сколько будет эффективно, создавать для каждого пользователя отдельную. таблицу операций, с уникальным обозначением и дальнейшим ведением учета операций в этой таблице?
типичная ошибка новичка.
Короче, у тебя нет опыта, ты подобную базы не способен самостоятельно спроектировать. Начни делать правильно, как написано в книгах, оптимизаций займешься потом, с 99% у тебя не будет столько пользователей, чтобы возникли проблемы.
Дополню Everything_is_bad.
Базы данных спокойно переваривают миллионы записей. Вопрос только хранилища самого (всмысле места) и все.
Я бы советовал вам не заморачиваться и сделать сначала "как сделается" - т.е. 1 таблица на всех юзеров. Когда появится "несколько юзеров" и "работа станет крайне затруднительной" - тогда и будете заниматься оптимизацией. При правильно спроектированном интерфейсе доступа к данным это будет не сильно сложно.
Алан Гибизов, через ошибки и проблемы как раз и возьмет )))
(в данном случае я просто имел ввиду что стоит заморочиться больше над интерфейсом, а не надо структурой БД, которая может поменяться и это нормально)
Просто добавь в таблицу колонку, в которой будет храниться автор записи.
Если конечному пользователю действительно будет не удобно - он просто включить фильтр, чтобы ему показывались только его записи.
не затруднит ли в дальнейшем получение информации из базы?
Затруднит. Причём не "в дальнейшем", а вот уже прямо сейчас.
С нормальной таблицей получить данные пользователя и его баланс можно одним простым запросом. А с зоопарком из таблиц надо что-то колупать с именами таблиц.
С нормальной таблицей получить аналитику по финансам в целом можно одним простым запросом. А с зоопарком из таблиц каждый раз придётся собирать запрос вручную в цикле и уродовать свой жесткий диск поскольку сразу БД не сможет получить все данные, а её придётся сначала слить все данные всё равно в одну таблицу, а потом уже по ней искать.
Средний
