Дано:
Гос. предприятие (академия повышения квалификации)
Требования начальства на данный момент - упорядоченное ведение данных о клиентах с возможностью выборки по разным параметрам, дальше процитирую: "Чтобы можно было печатать конверты с данными клиентов, извлекая из базы, а не набивая руками..." (На данный момент вся информация хранится в вордовских и экселевских файлах...)
Программистов в предприятии НЕТ! Есть пара сисадминов и вебмастер. Остальной состав конторы - преподаватели, организаторы, бухгалтерия и кадровики... Как вывод, точной технической задачи мне дать не могут.
Мой взгляд в будущее - как только они получат то, что хотят на данный момент, захотят еще чего-нибудь.

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

З.Ы. Простите, мудрые программисты, если этот вопрос покажется глупым, но это мой первый опыт работы (я еще студентка и реальную работу ручками до сих пор не щупала)...

Самый простой вариант, для развития базы это начать с Access. 
Плюсы: много wizards для создания форм, таблиц, query и .тд.
В будующем, легко преводится под MSSQL.
Минус: (или плюс, смотря с каой стороны смотреть) Access это файловая база данных, для работы в сети требуется положить файл в расшареную папку.

litle_bee, как я понимаю, в госпредприятии вопрос об использовании лицензионного ПО стоит. да? Тогда стоит посмотреть в сторону бесплатных СУБД(посмотри обзор в прикрепленной теме в этом же разделе). Что касается сетевого доступа, то лучше сразу браться за то, что разработано для работы с клиентами по сети.

Ну как тебе сказать...  зависит от того что за контора  

Хотя если есть необходимость интеграции с MS Office ("Чтобы можно было печатать конверты с данными клиентов, извлекая из базы, а не набивая руками..."), то самое оптимальное - это действительно Access.

или MSSQL

Я тоже за Access - если использовать не встроенный DAO, а ADO, то перевести на MS SQL будет в последствии совсем не сложно + можно при переходе будет оставить все формы - просто использовать файлы adp (всё как в обычном аксесс, но данные лежат в MS SQL - соответственно нормальная скорость работы, поддерживает многопользовательскую работу по сети - на личном опыте пробовала до 50 одновременных активных подключений, а для гос. организации больше наверное и не надо).

MySQL или PostgreSQL

Всем любителям Accessa:
Вы что? Это поделие предназначено для небольших по размерам баз ЛИЧНОГО пользования. Можно конечно к нему прикрутить 3-5 юзеров, но лучше ну его. Поскольку транзакций как таковых нет и база в любой момент может просто грохнуться напрочь. 
Удобство визардов - можно забыть, поскольку громоздить на клиентов Access только чтобы юзать базу на другой машине - это даже не смешно. А клиенты обязательно появятся, иначе нет и смысла заводить базу. 
Короче Access хорош как учебная база, но потом все равно переучиваться придется. Дешевле уж тогда сразу из Офиса MSDE (младшего брата MS SQL) поставить. Но и это не очень хорошо - инструментов нет.
Соответственно наиболее правильно выбрать что-либо из MySQL/PostgreSQL/FireBird. Они и бесплатны, и вполне надежны. Лично я на похожую задачку (очередь инвалидов, ветеранов и т.п. на транспорт, около 2000 чел. на сегодня + 1000 в архиве) в свое время выбрал MySQL + ADO + Delphi, поскольку MySQL уже стоял на серваке. И почти с нуля практических знаний о MySQL за месяц все слепил, а потом в качестве проверки за 2 дня перетащил на MS SQL и попробовал еще на нем. Получилось забавно - в зависимости от того, какой udl-файл подсунешь, клиент работает либо с одним, либо с другим сервером. Потом пришлось думать - на чем боевую базу оставить . Оставил на MySQL.

LSD, 

По-моему как раз для конвертов офис не нужен - чтобы не было соблазна ручками подправлять надписи для конверта, а приходилось исправлять первичные данные - в базе.

не вяжется 
имхо всетаки для начала аксесс , а потом на что то более мощное
PS а аксес хорош имхо, т.к. будет кучу пересылок данных из экселя и ворда, имхо аксесс как раз на это и расчитан

SergeBS, 
Я довольно плотно уже 3 года работаю с MS SQL Server 2000, доводилось разрабатывать и небольшую CRM-систему, и распределённую базу по регионам страны - в общем, знаю базы данных не по наслышке.
НО
Когда год назад передо мной стала задача разработать простейший курсач в универе с использованием MySQL, я мучалась с ним 2 недели и в результате напарила чёрти что.
Причина - отсутствие интуитивного интерфейса. Любой инсерт, апдейт, альтер - будь любезна из командной строки. Я-то написать его могу, и писала собственно, но как можно новичку, который плавает в этих вещах, начать с нуля - понимаю слабо.
К чему собственно всё это
У меня просьба
Подскажите, с какой стороны подходить к вот таким вот СУБД а-ля MySQL, PostgreSQL и т.д.
Они кажутся безумно трудозатратными по сравнению с MS SQL Server!!!

Думаю, информация будет полезна и автору топика для определённости.

имхо все зависит от того чем юзаешься допутим ты 

и 

разницу видишь?
а кто то 3 года в мускуле и будет говорить обратное   

  

просто в Access и Front-end и само СУБД - в одном флаконе. А в MySQL: мухи - отдельно, котлеты - отдельно. Но это уже вне этой темы. Заведи темку в разделе "MySQL". 

не согласен!
Предлагаю тебе создать тему в религиозных войнах и обосновать свою позицию! 

Спасибо всем огроменное за советы!   
Скоро должны привести сервак, на нем уже стоит MySQL и крутиться отдельная база...
Полагаю, что нет смысла писать на Access, если уж имеется нечто более серьезное.
Буду познавать MySQL, PHP, HTML... Во всяком случае для дальнейшей серьезной работы (а не студенческой подработки как сейчас)
мне это точно больше пригодится, нежели Access.

Там правда еще проблем вагон и маленькая тележка - они мне до сих пор машину найти не могут, например...
Посмотрим... 

С Аccess'a начинай. Легко будет как новичку и для твоих задач - оптимально подойдёт. Когда встанет вопрос о распределении, базу можно смело переводить на сервер MySQL. К тому времени, возможно и теории и практики будет у тебя побольше. При этом ты сможешь продолжать работу на Access, используя его как Front-end (он с любым ODBC может работать). то есть изменения минимальные, переход "мягкий", без затрат.
С моей софтиной человек 50 секретарш так трудятся через Access-MySQL. Всем хорошо и админу сервера и секретаршам. 

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


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

Shiny, 

Из моего опыта - наоборот. Мне самым простым в освоении показался именно MySQL. Правда до того я "проломился" через InterBase/FireBird и MS SQL. Может это сказалось.
Сейчас не могу - спешу, а завтра - перечислю полезняшки для mySQL/FireBird. Они дома в основном.

гы а я что говорил 

Shiny, 
Сразу - у меня чаще всего Delphi(клиент)+ADO(связь)+MS SQL(сервер). Это чтобы сильно не пинали.

InterBase/FireBird:
IB Expert -Interbase Administration Tool - must have! В одном флаконе - все инструменты вплоть до автоматизации создания генераторов. Для ex-USSR - бесплатно, авторы - русскоязычные. www.ibexpert.com
Delphi - наиболее популярный набор - FIBPlus. Коммерческий. Автор - русскоязычный (С.Бузаджи, вроде одессит). Есть куча других.
Самый полезный ресурс - www.ibase.ru. Там авторы Жар-птицы и прочего (русские), ссылки на всякие полезняшки, FAQи и т.п.

MySQL:
Пакет Джентльменский набор Web-разработчика Денвер-2 - - must have! В одном флаконе - все инструменты.© 2001-2004 Дмитрий Котеров.  Домашняя страница: http://web.dklab.ru
Контакты: http://forum.dklab.ru/denwer. Apache+PHP+Perl+MySQL имеет размер всего около 1.9Мб  и  при  этом  полностью  функционален. Рулится из браузера.
Пробовал MySQLGui - кое-где удобнее, но в целом - хуже.
Delphi: SirectSQL(Ю.Шейно). Коммерческий. Есть куча другого. 
Ресурс: www.mysql.ru - легко запоминается .

Ну www.sql.ru - все знают. 
http://www.linuxshare.ru/postgresql - ясно что. В этом я совсем 0.

Насчет освоения: у MySQL по сравнению с MS SQL сам SQL - в разы скромнее по возможностям. НО! Очень удобная и понятная (для меня) русская документация. Если бы я начинал  изучать SQL  - читал бы следующей после Грабера. Поэтому освоить легко. Есть хитрость - несколько форматов хранения данных (с поддержкой транзакций и без), но за 1-2 дня разобраться - не проблема.

Опечатался, конечно же
Delphi: DirectSQL(Ю.Шейно). Коммерческий. Есть куча другого. 

Т.е. ты хочешь сказать что к консоли можно привыкнуть и воспринимать её как должное?




Ну я не с Аксесс 3 года работала, это совсем уж элементарно, а с MSSQL... 
Прости лопуха за незнание - что имеется в виду под "Front-end"? Конечный пользователь? Или администратор БД?




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

SergeBS, за ссылки большое спасибо!
Буду смотреть, пробовать, от чего вы все так балдеете 

Предлагаю тему продолжить здесь чтоб не ругались модераторы   

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

Shiny, 

Смотри ссылки. Я не настолько фанат командной строки, чтобы имея нормальный GUI-инструмент ковыряться в консоли. Особенно если инструментов несколько. В отличие от MS SQL.

я работаю в pg через командную строку, хотя есть pgAdminIII 

Добавлено @ 09:15 
и не боюсь делать ошибки - главное снять BackUp, если так уж сильно важная инфа в базах. 

Ну.... три года с МССКЛсервером предполагают более близкое ознакомление с СКЛ 
А интуитивный интерфейс - это интуитивный интерфейс...
У каждой СУБД свой и не один.
В то время как та самая нелюбимая "командная строка" - это стандарт СКЛ, благодаря которому мы так спокойно и можем обсуждать выбор СУБД для простейших задач. 
Ибо, за исключением мелочей, различий нет.

Для быстрого кропания таблиц для курсача, безусловно, лучше ГУЙ. Но я не встречал компании, где есть план "даёшь не меньше десяти новых таблиц в день!!!". И при создании новой надо бы проверить как она встыковывается в систему и в скрипты правильно вписать. 

А вот 

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


Нужно... не обязательно ей всегда пользоваться, но знать и ПОНИМАТЬ - надо.
А в ГУИ можно напортачить ничуть не хуже, лихо кликая "крысой". И потом сказать "упс!"

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

Так что лучше изучать язык с алфавита, чем потом с удивлением узнавать о "каких-то там буквах..."

в целом ты прав.
Вообще изучение баз данных я начала именно с этого.
Я могу уверенно сказать, что транзакт СКЛ знаю хорошо, и могу написать руками любой запрос, НО! ЗАЧЕМ? Тратить на создание таблицы 15-20 минут, тщательно проверяя все синтаксисы и запятые, если можно это сделать в ГУИ на порядки быстрее?


Такие команды как UPDATE и DELETE любой сложности я всегда пишу руками - тут нужна предельная внимательность, но зачем извращаться создавая таблицы, меняя название колонки или тип поля?? Это лишнее (ИМХО)


А сначала всё-всё продумать, а потом написать, чтоб проверять лишний раз не надо было - не получается?


Повеселило  Так талантливо перемешать грешное с праведным надо уметь. ГУИ - это обязательно шаблоны? Не думаю!


К сожалению, этап простейших задач для меня уже давно пройден... 
Полтора года назад я разрабатывала CRM-систему, на момент моего увольнения в ней было полторы сотни таблиц - половина справочного характера, половина - сами данные. Поверь, если бы я её делала из консоли, "алфавитом" + админила это всё счастье + писала для него оболочки + объясняла сотне юзверей что с этим всем делать, мне бы в сутках и сотни часов не хватило....

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


Это и школьнику понятно



Это я и хотела знать. Спасибо

Я немного утрировал. Под впечатлением от идеального интерфейса: "сделать чтоб было хорошо? - да! - уже сделано хорошо!". Но суть остаётся - стараясь минимизировать усилия, приходится многое возлагать на "умность" "умного" клиента.


Мммм... изменение колонки или типа поля на "боевой" БД не менее важны. У меня(и не только) часто встречались ситуации, когда надо было тонкими манёврами изменить табличку, аккуратно перестроив другие и так же аккуратно сманипулировать данными на "живой" БД.
По-моему, ничего лучше, чем написать последовательность команд, прогнать на тестовом и запустить, нету. И если работает хорошо - то на боевом уже не запорешь, как правило - просто запускаешь скрипт без изменений


  
Для таблиц с количеством столбцов, измеряемым в десятках. Обычно это одна минутка.


Ммм... не верю.
(Отметаем юзверей и оболочки - для сравнения путей эскьюэлирования они абсолютно лишние. так же как и дорога домой/на работу.)
Работал как-то в компании, количество таблиц было ~600-700.
Всё прекрасно успевалось. Причём скрипты прекрасно ложились на ЦВС и структурой можно было манипулировать просто таки превосходно. Несколькими запусками скриптов.


Не получается. Не знаю таких людей. Ошибки свойственны людям. Даже если "всё-всё продумать".
Вот и перепроверяют люди. А если делать по очереди knock out для десятки табличек - можно случайно мышкой попасть не на ту и через пару секунд уже сказать "@#$#!"... То есть "УПС!"

В общем... Для начинания стоит брать консоль и понимать как это работает.
И если уж очень припрёт, с большим мешком опыта... Тогда плиз.. 

ЗЫ: А вообще это дело привычки.  Но пока механизмы не понятны досконально - к гуи лучше не привыкать... ;)

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


Нну... У меня было в большинстве дата-таблиц действительно больше 10-ти полей... А в некоторых намного больше...

 Я имела ввиду что делала это всё одна. И так еле справлялась, а если б ещё руками таблички писала и меняла - померла бы. (мы же говорим в целом о работе, а не о тепличных условиях - хорошо, если тебе такие создали и можно отстранённо сравнивать ту или иную производительностьь отдельной СУБД, а если нет и приходится оптимизировать скорость работы как только можно, и ни в коем случае не во вред качеству?)


Ну для этого и нужны глаза чтоб смотреть куда кликать... 
Честно сказать не знаю что такое knock out, но в любом случае из-за случайного клика у меня не было ни одного случая чтоб сказать "@#$#!". В основном такие фразы вылетают именно когда скрипт пишу руками и что-то забываю или лишнее пишу...


Это совсем другая структура работы, не знакомая мне....
Может, она и лучше чем ГУИ, если доведётся когда-нибудь так работать - смогу сравнить...

 - ничего специфического  просто дословно перевести типпа... "вынести" таблицу нафик 



Это как раз плохо :-/ Этим должны заниматься разные люди. Не для тепличности условий а для большей эффективности. Хотя "единовластие" в нашем зачаточном айти-бизнесе ещё распространено. И ето плохо :-/


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



Ок 

В любом случае... litle_bee, начинай с консоли.

И... начинай с mysql.
Почему?
Потому что он лёгкий, бесплатный, распространённый, отлаженный.
И на этом же форуме чрезвычайно много майэскьюэльщиков. Да и почти любой пхпист его немного да трогал 

Можно, конечно, бегать, сравнивать в мелочах с другими...
Но сейчас это почти стандарт де-факто для мелких задач.
Как автомат калашникова - прост, надёжен, всегда под рукой, патронов под него - хоть залейся и всегда есть спецы по нему.

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

А о том, как стирал базы/таблицы кликая по менюшкам у меня имеется свой реальный прискорбный опыт.

Уговорил 
С этим согласна
И, если бы у меня было 100 постов, накатала бы тебе + за упорство в споре 
НО! Я всё равно считаю, что скриптами создавать и модифицировать таблицы, настраивать репликации и т.п. намного дольше и сложнее.
Из-за того что действие не разделено явно на шаги, а является большим текстом ошибку можно и пропустить (особенно касается репликации - там коды просто огромные, и куда проще поправить если нужно цифру или две в ГУИ, там не промахнёшься, чем долго искать её поиском в тексте и в результате найти не то, что надо)

Это решаемо! 
chief39, ++1

pythonwin, Спасибо!
Собственно, аргументацию плюсика я бы поставила в противоположном порядке - очень редко встречаю людей, которые могут аргументированно защищать своё мнение до победного конца 

Это сообщение отредактировал(а) Shiny - 24.10.2006, 18:10

Зато человеческий фактор меньше   

2All
Вы конечно молодцы, что обсуждаете чем лучше структуры править. В этом вопросе согласия никогда не будет. Только вот насчет ошибок и т.п. главным пунктом является не чем править, а где: на тестовой базе. В большинстве случаев - просто копии рабочей базы, но не на боевом сервере, а на рабочей станции. А когда на ней все стало нормально, перетащил готовые скрипты и все. Опять же с бэкапом-восстановлением тестовой базы никаких проблем, а значит можно заниматься любыми экспериментами. А ежели кто сразу на рабочей базе начинает править - руки отрывать. И приделывать их куда надо, но не туда где были. Поскольку риск - совершенно неразумный.
А еще главнее регулярный бэкап, но это уже совсем не по теме. Кстати тема: на чем делать а не чем править . И не где править (это у меня самокритика   ).

Мы ещё изменим это мнение   



Нууу... как это?  "Ищите да обрящете"  Если знаешь что искать - почему бы это и не найти? Кроме того, никто не отменял подробные толковые комментарии. Если их нет - плоххххо.... очень плохо.


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

А вот в случае нормального использования тестовой БД и последующего переноса скриптов - ключевое всё-таки 


Ну это мы отклонились всё-таки.... Интересно поглядеть как там дела у Маленькой Пчелы с выбором и употреблением СУБД....

Согласен - для начало не мешало бы изучить локальную Access

Предлагаю рассмотреть альтернативный вариант -- пойти по пути установки и кастомизации готовой OpenSource CRM-системы, например TinyERP или ERP5.