ByKiSДайте совет с чего начать делать базу.

Бизнесс - изготовление жалюзей, роллетов, маркиз и т.д. Нужна база для регистрации договоров-заказов, с подсчётом цен, расчётом технологий (чего и сколько отрезать для изготовления кокого-либо изделия), учётом остатков сырья и деталей, ведение оплат-задолжностей клиентов, рассчётом заработной платы, анализом данных для отдела статистики и т.д.

Рабочие места - центральный оффис с сервером, удалённые офисы и филиалы с подключением через VPN (~70-150bps)

Рассматриваемый вариант -
Рабочая база и пользоватильские формы на MS Access 2003 (реплика у каждого филиала);
Архив данных на SQL2005 (ежедневное копирование из базы Access на SQL) и пользоватильские формы на adp или asp.

Сразу оправдываюсь - я новичёк и опыта в создании баз нету, потому буду благодарен за любой дельный совет, который поможет избежать глупых ошибок. На форме искал, читал, но хотелось бы услышать мнение специалистов именно про рассматриваемый вариант и опредилиться с платформой и принципом работы удалённых оффисов перед проэктирование структуры.
Работу надо начинать с составления бизнес-процессов предприятия (минимум 2-3 месяца), затем надо составить теническое задание на разработку. И ТОЛЬКО ПОСЛЕ ЭТОГО уже выбирать платформу для разработки...
Насчет Акцесса скажу, что вряд ли он такую рабочую базу потянет (особенно расчет заработной платы). Вот SQL Server - это уже деловой разговор...

ByKiS Станислав СРаботу надо начинать с составления бизнес-процессов предприятия (минимум 2-3 месяца)
Ну бизнес-процессы я представляю себе хорошо... А что здесь конкретно описать и как, что бы услышать дельный совет?

Здесь Вам никто не поможет, ибо это специфическая область. "Штучное изделие", так сказать...
Можно лишь указать на необходимость подробно расписать все информационные потоки (от гендиректора вплоть до бухгалтера-кассира), определиться с тем, какие типовые задачи (возможно, это будут хранимые процедуры в вашей системе) каждый из сотрудников выполняет, какие задачи подлежат автоматизации (а какие нет), определиться с набором отчетных форм (может быть часть отчетов копирует друг друга, а другая часть - вообще устарела и больше не нужна) и т.д.

ByKiS
Станислав Сзатем надо составить теническое задание на разработку
А это с чем едят?

Определить состав вашей системы: какие модули в системе вы хотите видеть, как будете передавать информацию между модулями, какие таблицы, отчеты, процедуры должны быть в таблице, сроки разработки, какие параметры системы надо оптимизировать и т.д. Но на этот счет существуют ГОСТы

ByKiS
Станислав СНасчет Акцесса скажу, что вряд ли он такую рабочую базу потянет (особенно расчет заработной платы). Вот SQL Server - это уже деловой разговор...
Да, но как с SQL насчёт филиалов? Акцес решил бы этот вопрос репликацией.
Никто репликаций не отменяет. Вроде бы в SQL server эта возможность тоже есть. Просто Акцесс плохо переносит увеличение числа пользователей (масштабирование). Кроме того, у него все "свалено в кучу" - в одном файле лежат и формы, и отчеты, и таблицы, и программный код...
Для маленькой базы (на одного человека) это будет нормально. Но когда речь идет об одновременной работе хотя бы 5 пользователей - я бы разделил данные (SQL Server) и формы для их ввода (пусть будет тот же Акцесс, или Делфи, или С#, или...)

ByKiS
это как я думал и есть проэктировка? Тогда почему это до выбора платформы?

Да, это часть проектировки. Почему ДО выбора платформы? Потому, что в этом случае Вы уже определитесь со структурой и объемом данных, необходимыми процедурами, сроками их запуска (может быть что-то можно делать по расписанию - job'ы на SQL Server) и т.д. И сможете осознанно делать свой выбор. Кроме того, после выбора платформы Вы "на нее подсядете" и, в дальнейшем, менять платформу будет очень сложно для Вас и болезненно (как в смысле денег, так и необходимости переучиваться сотрудникам) для фирмы

ByKiS
4 - Устанавливать всем менеджерам SQL на их старенькие нотебуки? Вот здесь на данном этапе мне и нужен совет какую выбрать платформу и как обмениваться информацией.
У MS SQL Server есть бесплатный вариант - Desktoр Edition (MSDE). Вроде бы он не такой требовательный к ресурсам...

P.S. По Вашим постам создается впечатление, что с бизнес-процессами компании Вы все-таки знакомы не очень хорошо...
Например, один менеджер может продать остатки со склада и там останется товаров 0 шт. В то же время другой менеджер (с другой репликой базы) продает те же остатки и у него остается на складе 10 шт.
Потом на склад приезжают покупатели и обнаруживается коллизия... Это, как минимум, ударит по репутации фирмы...
Это, конечно, ситуация гипотетическая. Но вполне возможная... Так что, репликация - не панацея, а источник больших проблем... Может быть лучше технику обновить и установить надежный канал связи с центральным офисом?

ByKiSСтанислав С:

По поводу первого - понятно, согласен. Но остался вопрос - можно ли рассматривать SQL+Акцесс как вполне приемлимый вариант и для более сложных задач, а уж для моей и подавно? Таким образом выбор платформы уже как бы был бы и решён, или Вы пртив кокой-либо из этих состовляющих и не советуете так сразу остаравливаться на них? Дело в том что с акцесом месяц как знаком, а с остальным програмами вообще ни-ни...

По поводу второго - несоглашусь, что не знаком, хотя описанная Вами ситуация не то что не гипотетическая, а более того - практическая... Вопрос о модернизации: я-то новичёк и даже до очевидного могу не сразу додуматься, но хотелось бы узнать Ваше мнение по поводу терминала, почему о нём никто не упомянул как альтернативу репликациям? Есть минусы?
Ничего определенного советовать я Вам не буду, ибо это чревато... Тут уж Вы как нибудь сами на фирме решайте...
Скажу только, что современная тенденция развития языков программирования такова, что практически любую задачу можно решить при помощи любого из них....

Насчет работы с удаленной базой данных. Есть две основные возможности работы: on-line (данные сразу попадают в базу данных и пользователи сразу видят их изменения) и off-line (пользователи сначала вводят данные, затем некая процедура данные переносит в центральную базу данных/согласует данные между филиалами).

Любая попытка работать с реальными данными в режиме on-line требует обеспечения стабильной работы всех составляющих соединения: сети, серверов, локальных рабочих мест. Как этого добиться - вопрос возникает уже в начале разработки и обостряется при эксплуатации программы. Решается, как правило, обновлением всей или части техники и грамотным администрированием.

При работе с данными off-line требования к стабильности работы сети менее жесткие. Но есть один глобальный недостаток: могут случиться коллизии, описанные выше (типа повторной продажи проданного товара). Это, конечно, можно решить, если постоянно иметь значительный резерв на складе. Но это - замороженные средста фирмы, на что руководство будет смотреть "криво"....

Если под "терминалом" Вы понимаете терминальный доступ, то здесь тоже достаточно жесткие требования к работе сети, как и при обычном (нетерминальном) подключении.

ByKiSИ всё же - с чего мне начать? С подробного описания бизнесс процесса и технических задач (что должна выполнять программа и что на ней будет делать каждый конкретный пользователь), я правильно понял? И ещё вопрос - сколько времени можно на это выделить, если на всё про всё дано 7 месяцев? Я понимаю что ответить невозможно, но может из практики дадите совет сколько времени и на что отвести процентально? Чтобы потом мне неожиданно не узнать, что то на что я отвёл неделю есть самое основное.
1. Да, это Вы поняли правильно. По результатам будете строить необходимые таблицы, связи между таблицами, типовые процедуры обработки данных, создадите роли пользователей и т.д.
С этим не надо спешить. Но и затягивать не стоит. ИМХО, месяца 2 должно хватить...
2. 7 месяцев - достаточный срок для создания работающего прототипа ГРУППОЙ разработчиков (4-5 человек). Одному - мало будет, я думаю, и года... Был в такой ситуации - с начальником пробовали написать расчет себестоимости... За полтора года дошли только до загрузки оборудования подготовительного цеха... И это при том, что я пахал "как папа Карло"...

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