MS Access - хорошая вещь?

Всем привет!
Есть необходимость сделать базу данных (информация о людях) своего рода "сетевую версию" (пользоваться и пополнять будут 10 человек), положить её на сервер, к которому открыт общий доступ внутри локалки? Наивный, наверное, вопрос (но не судите строго) - можно это сделать в MS Access? Вроде для этого ж она и предназначена? Может это сделать человек "с нуля" (купить книжку, разобраться...) Или необходимо прибегать помощи SQL-щиков, писать ТЗ, устраивать тендер среди студий... нанимать на работу программиста, который будет её потом поддерживать...
Что думаете?

Можно самому разобраться, причем без всяких книжек, только с использованием встроенной помощи. У нас такая на работе, проблем не знаем.

: Sеlena , можно и самому... только терпение надо...
попробуй...

Простенькие базы в инете валяются. Ничего сложного если не углубляться в тонкости. Купите вариант "для чайников" и пользуйте :-)

НЕ ДЕЛАЙ этого в ACCESS!!!! ОН _НЕ_ПРЕДНАЗНАЧЕН_ для этого!!!!!!!!! ACCESS _НЕ_ЯВЛЯЕТСЯ_ сервером БД в человечьем значении этого слова!!!!!!!

1) Нет поддержки многопользовательского режима. ТО ЕСТЬ ВООБЩЕ НЕТ!!!! Если к базе подключено более одного человека, то работает база ТОЛЬКО НА ПРОСМОТР!!!! Потому что реально база, выложенная на "сервере"(на самом деле просто удаленной машине), это система архитектуры ФАЙЛ-СЕРВЕР!!!! С таким же успехом туда можно кучу документов Лексикона положить. А что, тоже "база данных". Естественнно, для первого, кто открыл, она работает и на запись. Но остальные бреются, и вы будете названивать друг другу с просьбой "закрыть базу".

2) Нет поддержки транзакций. "ТО ЕСТЬ ВООБЩЕ НЕТ!!!!"(С) ! Если в базе чета слетит, то слетит оно навсегда, НИКАКОЙ ЗАЩИТЫ ОТ СБОЕВ ПРАКТИЧЕСКИ НЕ СУЩЕСТВУЕТ!!!! И вы, если админ у вас с башкой, будете откатываться на в лучшем случае вчерашнюю холодную копию. А если админ дурак - будете брить ноги.

3) Нет триггеров, хранимых процедур/функций/пакетов, последовательностей - да нихера там вообще нет!!!

3) Убогий пользовательский интерфейс. Можно клиента писать руками в нормальной среде разработки (у промышленных серверов ведь интерфейса нет вообще :-) ), но возникает вопрос - а нах тада ACCESS???

4) Убогая система отчетов. ИМХО ее лучче вообще не использовать. Можно, канешна, использовать CRYSTAL REPORTS и подключаться к базе ACCESS через ODBC, но возникает уже заданный вопрос: а зачем в этой цепочке ACCESS??? К тому же авторитетно заявляю, что ODBC - это геморрой, и CR с ним работает криво.

5) За все это гавно - дикая цена. Если фирма пользуется лицензионным ПО, то сервер INTERBASE на 10 пользователей стоит примерно $500 при том, что это полновесный промышленный сервер. Наскока я знаю, в америкосских абрамсах стоит - гдета точно читал, может, и вру :-) . MySQL - бесплатный, правда, он от ACCESS недалеко ушел (уточняю - бесплатным является тока тот MySQL, который "от ACCESS недалеко ушел"(С) ). А если на лицензирование ПО чихать - то вообще разворачивайте ORACLE 8i или MS SQL Server и не знайте горя :-D. Простенького клиента вам студент может слепить, правда, будет ли оно приемлимо работать - вот вопрос. "Не гонялся бы ты, поп, за дешевизной"(С) А. С. Пушкин

В общем, как человек, занимающийся разработкой подобных систем профессионально, советую - наймите специалиста! Чтобы не плакать потом кровавыми слезами :-) . Денег с вас возьмут не очень много. Лично я бы назвал цену $50 за рабочее место (при условии наличия ТЗ, закрытого исходного кода и никаких обязательств по дальнейшей поддержке, иначе мы бы поговорили), но, возможно, вы сможете найти и дешевле. Писать подобные системы самостоятельно... Я видел, как это работает. Меня в этом случае всегда мучает вопрос - а нахрена люди придумали разделение труда? Если базы пишут секретари, мучается вся контора, но у всех на лицах щастье?

2 PSH:

Сильно аргументировано! :-)

2 Selena:
ТЗ все равно писать, в противном случае это может растянуться на вечность :-)

Полностью согласен с PSH:

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

PSH
1) не верно
2) не совсем верно
3) все зависит от старания и рук
4) см пункт 3.
5) пиратство еще никто не запрещал.

про триггеры с PSH согласен. Но они не всегда нужны :-)

MS SQL на 10 юзеров? Смешно.....

MS Access до 30 пользователей работает на ура с базами на десятки- пару сотен мегабайт. Просто руки нужны :-)


>>> 50$ за рабочее место.

Сделаю за 100$ независимо от кол-ва рабочих мест.

2 EvgenS
При чем здесь MS SQL на 10 юзеров???
MS Access по определению не может прилично работать с БД. Просто потому, что он не является сервером БД.
Мерять тяжесть базы мегабайтами ... Ню-ню...
По поводу 50$ - если кто-то не совсем меня понял, я не собираюсь делать эту работу. Мне хватает проблем на работе, чтобы тащить еще и домой... 100$ за подобное - стока дворники получают :-)

2 Aleksey
1) Я десятки раз наблюдал, как организовываются подобные системы. Файл БД Access открывается двойным щелчком с удаленной машины. И приплыли. А если писать человечьего клиента, то "зачем Access" я уже спрашивал
2) Не смешите мои тапочки про "не совсем верно". Механизм транзакций - он либо есть, либо его нет. Всякие временные таблицы отката, организуемые лично программистом или самой ситемой и прочую криворучную лабудень позвольте за поддержку транзакций не считать. Слетит это все вместе с остальной базой, как вы не крутитесь.
3) Я понимаю, что сервер БД можно и на основе тетриса организовать. Также я знаком с бессмертным языком висуалбасик, который, кроме нервного хохота, лично у меня ничего не вызывает, но это лично мое мнение и вы вправе считать иначе. Хотя я очень смутно представляю себе, как организовать пакетирование процедур (да хрен с ним, с пакетированием, хотя бы просто пущай кучей лежат) в ACCESS, так что поверю вам на слово.
Можно и без функций/процедур обойтись. И даже ключи первичные не создавать - а нах они? Всю бизнес-логику вытащили в клиента - и алилуйя! Да и бизнес-логику не нада - авось сами разберуца...
4) Вы вообще сравнивали CRYSTALL REPORTS и ACCESS??? Даже если у вас 10 прямых и умных рук и 5 ACCESSов (по 0.5 Access'а в руку :-) ), вам отродясь не поднять на ACCESSе более-менее приличную систему отчетности. Ну не та порода!!! Понимаете, когда в одном приложении пытаются совместить отчетность, сервер БД и игрушку для скучающих домохозяек, профессиональной системы не получится, при всем моем уважениии к продукции компании Microsoft.

Мне сложно судить о возможности разворачивания серьезных КС - систем под управлением программы (можно, я не буду называть ее "сервер БД"?) Access. То, что я никогда не видел их прилично работающими, не доказывает, что их не существует. Но весь мой субъективный опыт говорит мне, что серьезные организации разворачивают совсем другие сервера для поддержки подобных систем. Его основные недостатки - отсутствие механизма транзакций, абсолютная незащищенность данных (я не имею в виду от взлома злобными кулхацкерами, я имею в виду полное несоответствие требованиям безопасности данных, предъявляемым к промышленным серверам) и абсолютное отсутствие большинства механизмов, присущих серверам БД.

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

to PSH
Если хотите перенести спор в сферу применимости MS Accessa для простейших приложений - можно потрепаться, но мне лениво. На прения отвечу, но тормозя :-)
По всем остальным крикам и лозунгам см ТЗ. Там по русски сказано о простой информационной базе. Конечно можно реализовать ее на супер-пупер платформе, написав клиента на ассемблере (а чем черт не шутит), но "стоит ли овчинка выделки"? Все будет нормально работать на MS Accesse.
смотри тз - зачем городить огород, когда надо простую информационную базу.

PSH!!! Круто!!! Такой креатифф!!! А ради чего? Чтоб доказать, что в джакузи купаться лучше, чем в тазике.
Имхо, аксесса вполне хватит для элементарной базы. Есть куча примеров, где оно работает и все довольны работой. Спорить нет смысла. Кто креатиффней тот и выиграл что ли? :-)
Селена, гляньте на http://www.relib.com/forums/forum.asp?pg=9&tp=20 Там можно если что даже вопросы позадавать и получить ответы специалистов.
PSH, может напишете там свой креатифф? :-) Ничего личного :-)

>>>100$ за подобное - стока дворники получают
За месяц. Тут работы на пару часов. Не кто же не просит пром.программы, речь шла о простой информационной базе на 10 человек. Так что, как сказали выше, зачем огород городить.

>>>можно, я не буду называть ее "сервер БД"?) Access

Никто и не называл это сервером БД.

"написав клиента на ассемблере"(С) :cool:

Да ну их, прения эти :-) ... В конце концов, у каждого додика своя методика... Мне претит поднимать что-либо на Access'е. Но, если организация действительно хочет иметь напоминатель дней рождения сотрудников :-) , разворачивать Oracle 8i излишне... Другое дело, остается проблема сопровождения, дальнейшей доработки и расширения функциональности... А миграция данных из Access'а куда-либо - геморрой... Правда, если в MS SQL Server - проблем немного..

Ну и, конечно, Access'овский диалект SQL - это что-то с чем-то :-)

2 EvgenS "Тут работы на пару часов"(C) - :cool: Вы, наверно, очень крутой программист... Исходя из того, что отладка и доводка продукта занимает не менее 80% времени разработки, то на написание первоначального варианта (клиент + сервер, т. е. интерфейс, структура данных, отчетность и т. п.) вам требуется что-то около 20 мин. Очень круто. Жаль, что таких, как вы, очень мало.

Вот и перемирие :-)

2PSH Просто много разработок на все случаи жизни :-)

Спасибо всем за аргументы! Чуть более подробно суть проекта я описала на форуме Web-дизайн и программирование, можно продолжить обсуждение там! ;-)