|  | 
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ Есть такая задача: Человек заполняет бумажную анкету, и затем эта анкета попадает в базу данных. В последствии из-этой базы нужно получать какую-то статистику по этим людям, группе людей и т.д. Основные условия: - База лежит где-то в инете. - Люди, которые заносят эти анкеты в базу ("кадровики"), находятся в разных городах на территории России. - Кадровики в большей своей массе будут сидеть на dial-up - Запросы, выборки из базы тоже делают кадровики - Объем базы допустим 5 млн. записей. - Заполнение базы периодическое, скажем раз в неделю из каждого города. Самое пожалуй сложное и непонятное: очень бы хотелось, чтобы человек, дважы заполнивший анкету, был бы одной записью в базе, иначе статистические данные будут иметь гораздо более расплывчатый характер. Хотелось бы услышать ваши мнения и по общей структуре базы (какую архитектуру - любые мнения, намеки, или конкретные решения сильно приветствуются - выбрать с учетом dial-up), и по решению последнего вопроса (все "кадровики" имеют на своих машинах таблицу всех проанкетированных и из них "руками" выбирают нужную личность и уже в эту запись добавляют данные ?). ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 08.07.2003, 09:37 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ Обыкновенную, нормализованную. Все, что может вводится из справочников, должно вводится из них. Главная проблема - отсечение дубликатов. Более-менее нормальный критерий - место и дата рождения, пол, Имя, Отчество. При вводе данных, если эти параметры совпадают, юзеру должно выкидываться окошечко, что такой уже есть. И пусть он принимает решение, заносить данные или редактировать имеющиеся. Правильным выходом из неодназначности, является ведение журнала изменений. У человека может менятся Фамилия Имя Отчество Паспорт Пол Табельный номер Гражданство И эти изменения должны быть отражены в базе. Если этя инфа будет своевременно заносится в базу, то проблема двоиников будет сильно ослаблена. Про двойников см. Топик Двойники на форуме MS SQL. 2002 год. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 08.07.2003, 20:37 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ Sorry. Топик назывался "Убей двойника" ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 09.07.2003, 07:35 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ С двойниками разберемся, спасибо за ссылку. Один вопрос по прежнему волнует: - Отличается ли принципиально работа на dial-up от работы в сетке. Т.е. нужно ли будет городить какие-то дополнительные уровни, или можно использовать обычную клиент - серверную архитектуру? Т.е. как я себе представляюю работу на клиенте: - Человек в оффлайне набивает 10-20-50 анкет. Затем входит в онлайн и отправляет данные серверу. (Как тут правда решить проблему двойников, я не знаю). Сработает ли здесь клиент-серверная архитектура с включенным кешированием, или не все так просто? Или делать без всякой архитектуры :) - Юзер набил анкеты (они при этом как-нибудь сохранились). Зашел в онлайн и отправил на определенный адрес почтой эти данные в каком-нибудь формате. Сервер посматривает этот ящик регулярно, парсит отправленный файл и добаляет данные в базу. Что скажете? ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 10.07.2003, 06:00 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ В принципе варианта 2: 1. Онлайн вариант: Пишите на ASP (PHP, Perl) несколько скриптов по заполнению базы и выводу отчетов. Юзеры работают через браузер. Преимущества: Немедленная валидация данных, нет необходимости в синхронизации данных, любые отчеты. Недостатки: Для ввода данных необходимо подключение к Инету. 2. Оффлайн: Как Вы уже сказали: Человек в оффлайне набивает 10-20-50 анкет. Затем входит в онлайн и отправляет данные серверу. Сервер обрабатывает и возвращает результат. Транспорт не суть важно (http, мыло, ftp). Премущества: Подключение к Инету только для отправки данных. Недостатки: Необходимо синхронизировать данные на клиенте. Отчеты недоступны или доступны только по запросу. Возможно и совмещение 2 вариантов: Серверная часть работает на веб-сервере, данные выдаются и принимаются в xml. Для передачи данных клиенту работающему через браузер xml преобразуется в html. Работа с оффлайн клиентом - через xml (SOAP) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 10.07.2003, 09:52 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ Если начальство не жлобствует, а дает безлимитный допук в инет, то лучше не городить, а оптимизировать код. Что бы запросы и ответы были минимальны по килобайтам. Если жлобствует - то надо переубеждать. Аргумент - "во сколько может обойтись потеря инфы? Вас же по судам затаскают." Я так думаю, что на диал-апе, 100 руб в день (примерно 3 часа) не сумма для приличной конторы. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 11.07.2003, 22:11 |  | ||
| 
Подскажите, какую архитектуру использовать | |||
|---|---|---|---|
| #18+ 2 Cat2: \r Если начальство не жлобствует, а дает безлимитный допук в инет, то лучше не городить, а оптимизировать код. Что бы запросы и ответы были минимальны по килобайтам. Если жлобствует - то надо переубеждать. Аргумент - "во сколько может обойтись потеря инфы? Вас же по судам затаскают." Я так думаю, что на диал-апе, 100 руб в день (примерно 3 часа) не сумма для приличной конторы. \r \r Alexey Kuzminich может потерять заказчика. Заказчик может оказаться не дурак и найти других ребят, к-рые исполнят ему офф-лайн вариант. Вообще это напоминает топик подскажите о выборе архитектуры для корпоративной информационной системы, т.е нет существенной информации: нефункциональные требования к системе (перформанс, надежность, удобство, расходы на систему..), бюджет и т.д. Только общая функциональность и все. Неизвестно, например, 10-50 анкет вводятся 1 человеком или 5, и сколько времени занимает анкета? Сколько их предполагается в будущем анкет/людей? Вопрос по оплате он-лайн времени пользователями, исходя из качества (скорости, доступности) их диалапных соединений и кол-ва анкет. IMHO лучше подсчитать хотя бы грубо затраты на диалап\r \r 2 Гость2: \r 1. Онлайн вариант: Пишите на ASP (PHP, Perl) несколько скриптов по заполнению базы и выводу отчетов. Юзеры работают через браузер. \r Преимущества: Немедленная валидация данных, нет необходимости в синхронизации данных, любые отчеты. \r Недостатки: Для ввода данных необходимо подключение к Инету \r \r Самый простой, в смысле традиционного архитектурного шаблона, а также пожалуй и в исполнении вариант для разработчиков\r \r 2. Оффлайн: Как Вы уже сказали: Человек в оффлайне набивает 10-20-50 анкет. Затем входит в онлайн и отправляет данные серверу. Сервер обрабатывает и возвращает результат. \r Транспорт не суть важно (http, мыло, ftp). \r Премущества: Подключение к Инету только для отправки данных. \r Недостатки: Необходимо синхронизировать данные на клиенте. Отчеты недоступны или доступны только по запросу. \r \r Интересна прогр.архитектура этого вар.2, т.е возможно какое-то приложение формирует txt/csv/xml.. файл отправляет его по smtp/ftp/http/.. и уже центральный сервер его "складирует" в БД. Отчеты? Самое простое: он-лайн запрос к Web-серверу\r \r Возможно и совмещение 2 вариантов: Серверная часть работает на веб-сервере, данные выдаются и принимаются в xml. Для передачи данных клиенту работающему через браузер xml преобразуется в html. Работа с оффлайн клиентом - через xml (SOAP) \r \r Это само по себе не вар.1 или 2 или их совмещение. xml как форма представления/хранения данных, soap как протокол могут использоваться и в вар.1 и в вар.2 ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 12.07.2003, 23:45 |  | ||
|  | 

| start [/forum/search_topic.php?author=Alisher+H.+Abdurahmanov&author_mode=last_posts&do_search=1]: | 0ms | 
| get settings: | 11ms | 
| get forum list: | 15ms | 
| get settings: | 11ms | 
| get forum list: | 13ms | 
| check forum access: | 3ms | 
| check topic access: | 3ms | 
| track hit: | 34ms | 
| get topic data: | 11ms | 
| get forum data: | 3ms | 
| get page messages: | 45ms | 
| get tp. blocked users: | 2ms | 
| others: | 485ms | 
| total: | 636ms | 

| 0 / 0 | 
