Суть такова! я работаю в организации в которой для ведения реестра учреждений используется Access, в БД предполагается хранить большое количество данных, примерно от 10000 тыс. строк, 26 таблиц, и самое главное что требуется от СУБД это ее использование по сети несколькими пользователями для получения данных, и для добавление данных будут одновременно работать несколько операторов. Я сам преподаватель информатики (по совместительству) и знаю Access, как мало производительную БД, постоянно "виснущую", и т.д.
Сейчас я предложил руководству перейти на Mysql, и написать прогу работающую исключительно в клиент/серверной архитектуре в локальной сети. Но вот беда руководство требует аргументировать шаг перехода на новую СУБД.
Так вот обращаюсь с просьбой помочь, в оценки этих двух СУБД. Если есть возможность дайте ссылки на сайты где уже подымались эти темы. На основе Ваших ответов, я выстрою политику защиты моего проекта. Желательно дать ответ как можно скорее. Заранее благодарен.

А как с аксесом могут работать несколько пользователей сразу?

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

В этом и есть вся загвоздка, прогу надо сделать полностью сетевой, но аксесс для этого слабо подходит, на мой взгляд. Поэтому я и хочу убедить начальство что необходимо сменить прогу на ту которую я предлагаю.

Цитата

знаю Access, как мало производительную БД, постоянно "виснущую", и т.д.

А это вина скорее преподавателя, чем Аксесса.

Цитата

Если есть возможность дайте ссылки на сайты где уже подымались эти темы.

Не дождетесь. Это вопрос из разряда "а если слон на кита - кто кого сборет?". Сама попытка их сравнения на всю жизнь заклеймит автора как непроходимого ламера - и больше ему публикаций в прессе или в Инете не видать...

По сабжу: обосновывай переход на клиент-серверную технологию. обосновывай простоту использования браузера в качестве клиента. Обосновывай легкость обновления и поддержания... а пхп(перл)+мускул уже тебе обосновывать после принятия стратегического решения о переходе.

Я бы перешёл на php+mySQL.
Сам работаю на такой связке. Есть возможность работать с любой машины подключёной к сети вплоть до КПК.Для работы с такой системой не требуется освоение аксеса - в форму забивать значение может даже школьник, второй раз работающий за ПК. Высокая производительность, автоматическое создание бекапов.

А вот зачем нужен аксес я не знаю Видел его только на лабах и то издалека.

Цитата

требуется от СУБД это ее использование по сети несколькими пользователями для получения данных, и для добавление данных будут одновременно работать несколько операторов

Как только речь идет об одновременной сетевой работе, да еще с функциями одновременного редактирования данных разными пользователями - это однозначный аргумент в пользу полноценного сервера БД.

Цитата

знаю Access, как мало производительную БД, постоянно "виснущую", и т.д.

Это не совсем точное определение. Access - это скорее персональная база данных - т.е. один человек на своей машине работает с этой БД. Есть проблемы с блокировками и транзакциями, иногда, если код закрытия соединения через OLE DB написан с ошибками, возникают ситуации, когда после закрытия приложения монопольный доступ к файлу остается за несуществующим процессом.

Цитата

Сейчас я предложил руководству перейти на Mysql, и написать прогу работающую исключительно в клиент/серверной архитектуре в локальной сети.

Насчет клиент/серверной - это беспорно верное утверждение. Насчет mySQL - я бы несколько раз подумал и попытался заглянуть в будущее. Это конечно БД хорошая, только для серьезных проектов она все же не годиться. Например: когда необходимо делать сложные выборки из нескольких таблиц одновременно, то очень удобно использовать вложенные выборки - mySQL эту функцию не поддерживает, приходиться искать компромисы в сложных конструкциях после оператора where. Сюда же можно добавить недостаточно развитый механизм хранимых процедур, и прочее.
Если вопрос стоит о хорошей БД, но при этом бесплатной, то я бы рекомендовал PostgreSQL - это полноценный, производительный СУБД, имеющий те же фунции, что и известные Oracle, MSSQL, DB2. Единственное препятствие, которое может возникнуть - он работает на UNIX, под виндой надо ставить библиотеку эмуляции. Ну конечно, чем серьезней сервер, тем острей будет необходимость взять на работу администратора БД.

Добавлено @ 10:12
Ну вот, как только написал, так наткнулся на ссылку

Цитата(DENNN @ 28.10.2004, 11:02)

когда необходимо делать сложные выборки из нескольких таблиц одновременно, то очень удобно использовать вложенные выборки - mySQL эту функцию не поддерживает, приходиться искать компромисы в сложных конструкциях после оператора where. Сюда же можно добавить недостаточно развитый механизм хранимых процедур, и прочее.

Поддерживаю.
Правда до постгреса руки никак не дойдут

Цитата(DENNN @ 28.10.2004, 11:02)

Это конечно БД хорошая, только для серьезных проектов она все же не годиться. Например: когда необходимо делать сложные выборки из нескольких таблиц одновременно, то очень удобно использовать вложенные выборки - mySQL эту функцию не поддерживает, приходиться искать компромисы в сложных конструкциях после оператора where.

Не совсем, последняя релизовая версия поддерживает вложенные селекты - сходите на mysql.com , однако реализация хранимок будет только в пятой версии.

К слову, для мускуля не обязательно писать клиент на PHP/Perl.

ИМХО типично непрофессиональный подход. Здесь под непрофессионализмом я имею в виду не то, что вы не знаете возможностей конкретных продуктов или имеете о них очень туманное представление, а, скорее то, что вы не можете оценить насколько ваши решения применимы для конкретных задач. Те требования, которые заданы в условиях, не есть проблема для Акцесса.
(Кстати, несколько пользователей - это сколько?...и что значит малопроизводительная?....и когда это она постоянно висла? ) Конечно, можно заморочиться чем-то модным и крутым, но именно Акцесс очень часто становиться оптимальным решением при минимальных затратах. Поверьте, он очень много может - и как самостоятельная СУБД, и как клиент для SQL сервера, и даже как среда разработки клиент-серверных приложений (АDP).
Как тут правильно заметили, сама попытка сравнения MySQL и Access подобно попытки сравнения слона с китом.

Цитата

А как с аксесом могут работать несколько пользователей сразу?

Еще раз о незнании продукта....это возможно с первых версий.

Цитата

прогу надо сделать полностью сетевой, но аксесс для этого слабо подходит,

Пример. В сети на акцессе сидит до 20-и пользователей и это далеко не предел. Деятельность связана с товарами, прайсами, складом, заказами, продажами. В общем все, за исключением бухгалтерии, так или иначе работают с данной системой.

Цитата

Как только речь идет об одновременной сетевой работе, да еще с функциями одновременного редактирования данных разными пользователями - это однозначный аргумент в пользу полноценного сервера БД.

Да ну? Ай-яй, на знал, простите.... Например, есть такая программа - ТурбоБухгалтер. Или появилась такая крутая система Navision Attain. Все они используют SQL сервер. Но как они его используют! Я плачу. Совершенно тупо. На сервере храняться исключительно только таблицы. Вся обработка ведется на клиенте. Данные болтаються по сети точно также как это было бы у Акцесса. Чем такое использование "полноценного сервера БД" лучше чем использование Акцесса? Акцесс блокирует записи, точно так же как это сделал бы сервер. У Акцесса реализован абсолютно рабочий механизм транзакций. Про запросы я не говорю. Триггеров нет, но и у MySQL, насколько я знаю, их тоже нет (но мои знания могут устареть).

Цитата

Для работы с такой системой не требуется освоение аксеса

Для работы с готовым приложением на Акцессе его не надо осваивать. Точно такие же формы, точно такой же дружественный (то есть как у разработчика получиться интерфейс

Цитата

Access - это скорее персональная база данных - т.е. один человек на своей машине работает с этой БД...

Смотри сказанное ранее

Цитата

Есть проблемы с блокировками и транзакциями

Какие?

Цитата

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

Это точно! Иногда, любая программа, если написана с ошибкой, то не работает.... Может, стоит писать без ошибок?

Меня, как практичного разработчика просто прикалывают фразы типа

Цитата

Единственное препятствие, которое может возникнуть - он работает на UNIX, под виндой надо ставить библиотеку эмуляции

....Ага - рейс Москва-Киев с пролетом на Сингапуром....

Только поймите меня прально. Я вовсе не против клиент-серверных приложений! Очень часто без них - никак. Но, ей богу, не SQL серверами затыкать все дырки... хотя если время и средства позволят расслабиться- почему бы и нет?

В заключении... сходили бы Вы на sql.ru. Там очень много информации по сравнению СУБД.Например, этот топик....и множество других

Гость_U-gene, у меня 5 SQL серверов под юниксом, на каждом поднят mySQL или PostgeSQL, так что мне проще написать веб интерфейс, чем продукт на аксесе.

Не было бы серверов, учил бы аксес

Дык и у меня .... ну не 5, конечно.... и не MySQL, а MSSQL... но все равно ACCESS очень часто полезен бывает.