В процессе разработки программного обеспечения оказались перед выбором: каждый из нас предлагает свой подход по поводу того, где будут храниться все данные всех пользователей. Поступили предложения хранить все на сервере (кстати количество пользователей заранее неизвестно), т.е. всю информацию всех пользователей которая появляется в процессе работы пользователя с разрабатываемым программным комплексом складывать на сервер. На этот счет появляются, честно говоря, сомнения — не лучше ли предоставить каждому пользователю свою БД и только актуальную для всех информацию закидывать на сервер, потому-что идея хранить всегда всю информацию всех пользователей на сервере (кстати, неопределенное время) кажется дикой. Интересно узнать мнение специалистов на этот счет.
Заранее благодарен всем откликнувшимся.
05.07.07 14:10: Перенесено модератором из 'Java' — Blazkowicz
F>В процессе разработки программного обеспечения оказались перед выбором: каждый из нас предлагает свой подход по поводу того, где будут храниться все данные всех пользователей. Поступили предложения хранить все на сервере (кстати количество пользователей заранее неизвестно), т.е. всю информацию всех пользователей которая появляется в процессе работы пользователя с разрабатываемым программным комплексом складывать на сервер. На этот счет появляются, честно говоря, сомнения — не лучше ли предоставить каждому пользователю свою БД и только актуальную для всех информацию закидывать на сервер, потому-что идея хранить всегда всю информацию всех пользователей на сервере (кстати, неопределенное время) кажется дикой. Интересно узнать мнение специалистов на этот счет.
F>Заранее благодарен всем откликнувшимся.
It depends,
1. Какова архитектура приложения, клиент толстый?
2. Вся ли информация о пользователе необходима вам (скажем для централизованного администрирования)? Какие-нибудь вопросы конфиденциальности актуальны?
3. Насколько большой объем информации получается при работе пользователя, придется ли ее постоянно передавать с клиента на сервер и обратно?
4. Всегда ли пользователь работает исключительно со своего рабочего места?
5. Еще надо оценить +/- администрирования и поддержки в каждом случае.
Я б попробовал себе ответить на данные вопросы сначала.
Здравствуйте, Trean, Вы писали:
T>Я б попробовал себе ответить на данные вопросы сначала.
+1
Вопрос навроде: хочу автоматизировать работу отдела, но вот думаю, а оно мне надо — подскажите пожалуйста!
F>В процессе разработки программного обеспечения оказались перед выбором: каждый из нас предлагает свой подход по поводу того, где будут храниться все данные всех пользователей. Поступили предложения хранить все на сервере (кстати количество пользователей заранее неизвестно), т.е. всю информацию всех пользователей которая появляется в процессе работы пользователя с разрабатываемым программным комплексом складывать на сервер. На этот счет появляются, честно говоря, сомнения — не лучше ли предоставить каждому пользователю свою БД и только актуальную для всех информацию закидывать на сервер, потому-что идея хранить всегда всю информацию всех пользователей на сервере (кстати, неопределенное время) кажется дикой. Интересно узнать мнение специалистов на этот счет.
F>Заранее благодарен всем откликнувшимся.
Если данные будут хранитсься на сервере, то возможна реализация сценария, при котором пользователь зайдя под своим логином с чужого компьютера будет получать свои настройки и работать как за своим.
V>Если данные будут хранитсься на сервере, то возможна реализация сценария, при котором пользователь зайдя под своим логином с чужого компьютера будет получать свои настройки и работать как за своим.
Есть другие опасения (повторю, но кол-во пользователей сейчас предсказать нельзя)==> На этапе эксплуатации вопрос производительности считается одним из главных, поскольку, если не обеспечивается требуемое время реакции системы, то система не выполняет возложенных на нее функций.
Здравствуйте, Flier, Вы писали:
F>Здравствуйте, vladpol, Вы писали:
V>>Если данные будут хранитсься на сервере, то возможна реализация сценария, при котором пользователь зайдя под своим логином с чужого компьютера будет получать свои настройки и работать как за своим.
F>Есть другие опасения (повторю, но кол-во пользователей сейчас предсказать нельзя)==> На этапе эксплуатации вопрос производительности считается одним из главных, поскольку, если не обеспечивается требуемое время реакции системы, то система не выполняет возложенных на нее функций.
А вы прототип делали? Тесты какие-нибудь? Или только теоретические догадки? Вполне вероятно, что проблемы с производительностью можно решить с помощью распределенной базы и load balance. Всегда можно оценить верхнюю границу, порядок числа пользователей исходя хотя бы из здравого смысла.
Мне кажется, что решать проблемы надо по мере их появления. Это конечно не значит, что риски оценивать не надо. Просто прикиньте, какие изменения потребуется внести в архитектуру, чтобы, скажем, перейти от централизованного хранилища к рапределенному. Спроектируйте так, чтобы сделать процесс миграции максимально простым.
Здравствуйте, Flier, Вы писали:
F>Здравствуйте, vladpol, Вы писали:
V>>Если данные будут хранитсься на сервере, то возможна реализация сценария, при котором пользователь зайдя под своим логином с чужого компьютера будет получать свои настройки и работать как за своим.
F>Есть другие опасения (повторю, но кол-во пользователей сейчас предсказать нельзя)==> На этапе эксплуатации вопрос производительности считается одним из главных, поскольку, если не обеспечивается требуемое время реакции системы, то система не выполняет возложенных на нее функций.
Извините, но скоолько будет пользователей если даже 1000 — то нормальный сервер БД должен без напряга справиться. Сделайте, так, чтоб при запуске все данные единым пакетом получались на клиент и храните их локальной копией. Тогда на сервере воообще в Quake играть можно
Двигайтесь от простого к сложному. Чем меньше правил нужно соблюдать для реализациии некоторого аспекта проекта — тем проще. Ваш аспект — хранение информации пользователя. Сравните правила двух подходов:
1. Вся информация пользователя храниться на сервере.
и
1. Информация пользователя бывает двух видов: актуальная для других пользователей и неактуальная для других пользователей.
2. Актуальная информация храниться на сервере.
3. Неактуальная информация храниться на клиенте.
С случае второго подхода нужно будет искать ответы на следующие вопросы:
1. Что делать, если информация которая была неактуальной вдруг станет актуальной и наоборот?
2. Что делать, если появиться новая неактуальная информация, которая должна храниться на сервере.
3. Что делать, если пользователь может работать на различных компьютерах?
4. Что делать, если пользователь одновременно откроет свои сессии на различных компьютерах?
5. Что делать, если на одном компьютере будут могут работать несколько пользователей?
Видишь, одно маленькое на первый взгляд усложнение ведет к достаточно серьезным последствиям. Поэтому, чтобы оправдать второй подход нужны крайне весомые аргументы. Если таких аргументов привести не удается — используй первый вариант. Более того, судя по твоему вопросу, можно с большой долей уверенности предположить, что опыт у тебя небольшой. Если опыт твоей команды соизмерим с твоим — используйте первый вариант без каких либо сомнений.
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, Flier, Вы писали:
MVK>Двигайтесь от простого к сложному. Чем меньше правил нужно соблюдать для реализациии некоторого аспекта проекта — тем проще. Ваш аспект — хранение информации пользователя. Сравните правила двух подходов: MVK>
1. Вся информация пользователя храниться на сервере.
и
1. Информация пользователя бывает двух видов: актуальная для других пользователей и неактуальная для других пользователей.
MVK>2. Актуальная информация храниться на сервере.
MVK>3. Неактуальная информация храниться на клиенте.
MVK>С случае второго подхода нужно будет искать ответы на следующие вопросы: MVK>1. Что делать, если информация которая была неактуальной вдруг станет актуальной и наоборот? MVK>2. Что делать, если появиться новая неактуальная информация, которая должна храниться на сервере. MVK>3. Что делать, если пользователь может работать на различных компьютерах? MVK>4. Что делать, если пользователь одновременно откроет свои сессии на различных компьютерах? MVK>5. Что делать, если на одном компьютере будут могут работать несколько пользователей?
MVK>Видишь, одно маленькое на первый взгляд усложнение ведет к достаточно серьезным последствиям. Поэтому, чтобы оправдать второй подход нужны крайне весомые аргументы. Если таких аргументов привести не удается — используй первый вариант. Более того, судя по твоему вопросу, можно с большой долей уверенности предположить, что опыт у тебя небольшой. Если опыт твоей команды соизмерим с твоим — используйте первый вариант без каких либо сомнений.
Дело даже не только в том, что пользователей много, просто разрабатываемая система предполагает, что у каждого пользователя будет еще по 10-12 других Баз Данных, с которыми каждый из них будет активно взаимодействовать через нашу разрабатываемую систему (стыковки с другими БД). И базы данных неоднородны — разные СУБД.
Кстати, если информация стала актуальной, то ее нужно закидывать
на сервер (пользователь сам управляет этим процессом, когда считает нужным опубликовать эту информацию для всех), а новая неактуальная информация (ведь первично она храниться у пользователя локально и только по его желанию становится актуальной) просто остается у пользователя (т.е. другими словами он не дает распоряжение отправить на сервер и она остается в его БД).
