Вот не могу определиться с выбором базы. И в MySQL и в MS Access есть свои плюсы и минусы.
Опишу ситуацию - поймете про какие минусы имею ввиду.
1. Сеть из 4 клиентов, 1 из клиентов, который постоянно в сети будет стоять еще и серверная часть.
2. Доступ одновременный к базе на чтение и запись (единственное каждый клиент заполнить может только свою часть данных, остальное только чтение).
3. По окончанию периода 1-2 месяца, требуеться возможность вывоза всей базы к заказчику с возможностью потом открыть эту базу у заказчика (желательно без установки дополнительных програм и сервер не разворачивать).
4. По итогам дня запрет на редактирование информации уже набранной вчера, позавчера и т.д.
5. Если 1 из клиентов переустанвит систему как можно проще настроить все заново на подключение.
6. Разграничить в базе доступ каждому клиенту на редактирование, остальное на чтение (т.е. что клиент 1 не мог изменить данные для заполнения клиента 2).

И вот на фоне этого у меня проблемма.
По простоте и тому, что будет проше вывезти отчет за период и потом открыть его у заказчика - MS Access.
По безопастности и разделению прав - MySQL.

Или есть еще варианты!?

p.s. В теме должно быть - MySQL вместо MS SQL Server


Это сообщение отредактировал(а) Rodeon - 28.11.2011, 22:28

ИМХО для четырёх юзеров сгодится и Access.

Так то да, уже в принципе база и есть в ацессе. Но вот тут про безопастность не учел. в 1 базе разве можно разделить права на доступ для разных клиентов. Т.е. клиент 1 чтобы мог заполнять только 1 таблицу в базе, клиент 2 только 2 таблицу и т.д. указываеться ведь общий логин и пароль на саму базу!? На этом этапе так как не увидел такого разделения каждый клиент заполняет свою базу, а уже по итогам дня вся инфа сливаеться в общий котел. т.е. получаеться как бы 4 базы по 1/4 и 1 общая с итогами за день.

Это сообщение отредактировал(а) Rodeon - 28.11.2011, 23:08

Что я не понял: а как тогда определить, какую таблицу кому заполнять, если логин всё равно один? Если только взять логин винды и идентифицировать пользователей по нему.

Это сообщение отредактировал(а) Данкинг - 28.11.2011, 23:12

изначально выглядит так, есть конфигуратор - в нем создаються клиенты, задаються им пароли, логины, разделяеться кто что будет заполнять.
Вот на этом этапе я подумал каждому клиенту прямо из конфигуратора создать свою базу, в которой будут только поля для заполнения им.
все таблицы и 1 общая будет лежать на сервере (пока он же один из клиентов).
на компе клиента запускаеться клиентская часть программы и каждый подключаеться к своей базе, со своим логином и паролем. как только данные были изменены, компьютер сервер забирает данные с базы клиента и вносит в общую базу. Общая база клиента на редактирование запрещена.

А база клиента где - на серваке или локально у каждого?

с этим пока не уверен, так как в случае пропадания сети как быть. В принципе можно и у каждого клиента база своя часть будет, по окончанию редактирования копировать все вновь внесенную информацию в общую на сервере (в общей базе имеються все таблицы и поля что и у каждой базы в отдельности), что бы другие могли видеть информацию, но не редактировать.
вот из-за вот этих манипуляций и думал про my sql, но надо будет настраивать каждый раз при установке на новом сервере. А с access все просто - указал файл, логин пароль и в путь.

Это сообщение отредактировал(а) Rodeon - 28.11.2011, 23:38

А сеть часто пропадает, что ли? Если да - тогда, конечно, лучше локально. И, соответственно, Access вполне подойдёт.  

Так правильно: к общей базе у клиентов доступа на запись и не будет, зачем он им.

т.е. получаеться правильно все таки сделал что в конфигураторе при создании клиента создаеться каждому еще и своя база с таблицей имеющей поля только для него (клиента) для редактирования?
всю остальную информацию на чтение он (клиент) будет получать с общей базы.
сама структура каждому клиенту по базе + 1 общая на чтение посредством access - единственный выход?

Ну, если связь часто падает - то, видимо, так наиболее логично будет.

Так в данном случае - вероятно, единственный.

Хорошо, спасибо! а то закрались сомнения. 

Ну, моё мнение, разумеется, не безусловно верное.  

При слитии с клиентских БД в общую id записей не попутайте, а то все труды будут на смарку.

А ID надо уникальным сделать в самой таблице, всё верно.

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