Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > На чем писать базу?

Автор: litle_bee 15.10.2006, 18:20

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

Автор: boevik 15.10.2006, 18:26

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

Автор: skyboy 15.10.2006, 19:00

litle_bee, как я понимаю, в госпредприятии вопрос об использовании лицензионного ПО стоит. да? Тогда стоит посмотреть в сторону бесплатных СУБД(посмотри обзор в http://forum.vingrad.ru/index.php?showtopic=30912 в этом же разделе). Что касается сетевого доступа, то лучше сразу браться за то, что разработано для работы с клиентами по сети.

Автор: LSD 15.10.2006, 22:51

Цитата(skyboy @  15.10.2006,  20:00 ) как я понимаю, в госпредприятии вопрос об использовании лицензионного ПО стоит. да? Ну как тебе сказать...  зависит от того что за контора   Хотя если есть необходимость интеграции с MS Office ("Чтобы можно было печатать конверты с данными клиентов, извлекая из базы, а не набивая руками..."), то самое оптимальное - это действительно Access.

Автор: Paradox 16.10.2006, 07:06

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

Автор: Shiny 16.10.2006, 14:35

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

Автор: pythonwin 16.10.2006, 16:10

MySQL или PostgreSQL

Автор: SergeBS 17.10.2006, 13:00

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

Автор: Romikgy 17.10.2006, 13:13

Цитата(litle_bee @  15.10.2006,  17:20 ) как пример, сейчас они готовы на реляционную базу на моей машине, а самим бегать ко мне за всеми данными... ) Цитата(SergeBS @  17.10.2006,  12:00 ) Вы что? Это поделие предназначено для небольших по размерам баз ЛИЧНОГО пользования. Можно конечно к нему прикрутить 3-5 юзеров, но лучше ну его.  не вяжется  имхо всетаки для начала аксесс , а потом на что то более мощное PS а аксес хорош имхо, т.к. будет кучу пересылок данных из экселя и ворда, имхо аксесс как раз на это и расчитан

Автор: Shiny 17.10.2006, 13:53

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

Автор: Romikgy 17.10.2006, 13:59

Цитата(Shiny @  17.10.2006,  12:53 ) Они кажутся безумно трудозатратными по сравнению с MS SQL Server!!! имхо все зависит от того чем юзаешься допутим ты  Цитата(Shiny @  17.10.2006,  12:53 ) уже 3 года работаю с MS SQL Server 2000 и  Цитата(Shiny @  17.10.2006,  12:53 ) разработать простейший курсач в универе с использованием MySQL, я мучалась с ним 2 недели и в результате напарила чёрти что. разницу видишь? а кто то 3 года в мускуле и будет говорить обратное

Автор: skyboy 17.10.2006, 14:08

Цитата(Shiny @  17.10.2006,  12:53 ) Подскажите, с какой стороны подходить к вот таким вот СУБД а-ля MySQL, PostgreSQL и т.д. просто в Access и Front-end и само СУБД - в одном флаконе. А в MySQL: мухи - отдельно, котлеты - отдельно. Но это уже вне этой темы. Заведи темку в разделе "MySQL".

Автор: pythonwin 17.10.2006, 15:38

Цитата(Shiny @  17.10.2006,  20:53 ) Подскажите, с какой стороны подходить к вот таким вот СУБД а-ля MySQL, PostgreSQL и т.д. Они кажутся безумно трудозатратными по сравнению с MS SQL Server!!! не согласен! Предлагаю тебе создать тему в религиозных войнах и обосновать свою позицию!

Автор: litle_bee 17.10.2006, 15:46

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

Автор: sergejzr 17.10.2006, 15:52

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

Автор: LSD 17.10.2006, 16:14

Цитата(SergeBS @  17.10.2006,  14:00 ) По-моему как раз для конвертов офис не нужен - чтобы не было соблазна ручками подправлять надписи для конверта, а приходилось исправлять первичные данные - в базе. Интеграция это же не только конверты. Мало ли что им может понадобится. С одной стороны мы имеем решение широкого профиля: выгрузил данные в Excel или Word и пусть ваяют какой хотят отчет. С другой стороны: мы отчеты делаем сами, нужен новый отчет они бегут к нам. Если за каждый отчет они будут платить, то это конечно хорошо. А если нет, то плохо, надо будет думать, что делать, чтобы ничего не делать. Цитата(pythonwin @  17.10.2006,  16:38 ) Предлагаю тебе создать тему в религиозных войнах и обосновать свою позицию! http://forum.vingrad.ru/index.php?showtopic=116892. А здесь религиозные войны предлагаю закончить.

Автор: SergeBS 17.10.2006, 16:52

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

Автор: Romikgy 17.10.2006, 16:56

Цитата(SergeBS @  17.10.2006,  15:52 ) Из моего опыта - наоборот. Мне самым простым в освоении показался именно MySQL. гы а я что говорил

Автор: SergeBS 18.10.2006, 13:11

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 дня разобраться - не проблема.

Автор: SergeBS 18.10.2006, 14:32

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

Автор: Shiny 18.10.2006, 18:01

Цитата(Romikgy @  17.10.2006,  13:59 ) имхо все зависит от того чем юзаешься допутим ты  Т.е. ты хочешь сказать что к консоли можно привыкнуть и воспринимать её как должное? Цитата(skyboy @  17.10.2006,  14:08 ) просто в Access и Front-end и само СУБД - в одном флаконе Ну я не с Аксесс 3 года работала, это совсем уж элементарно, а с MSSQL...  Прости лопуха за незнание - что имеется в виду под "Front-end"? Конечный пользователь? Или администратор БД? Цитата(SergeBS @  17.10.2006,  16:52 ) Мне самым простым в освоении показался именно MySQL. Как консоль, где всё руками пишется, может быть проще чем нормальный интерфейс администрирования, где часть задач оболочка "подсказывает" и не нужно бояться в каждой букве сделать ошибку??? SergeBS, за ссылки большое спасибо! Буду смотреть, пробовать, от чего вы все так балдеете  Предлагаю тему продолжить http://forum.vingrad.ru/index.php?showtopic=116892&unread=1&st=0&#entry893198 чтоб не ругались модераторы

Автор: Romikgy 18.10.2006, 20:12

Цитата(Shiny @  18.10.2006,  17:01 ) ты хочешь сказать что к консоли можно привыкнуть и воспринимать её как должное? я имел ввиду , что кто то начал работать с одной БД и через время он уже что то знает по ней , при переходе на другую БД возникают сложности и кажется , что БД которая известна, намного проще в использовании чем новая, через опред. промежуток времени , смошешь оценить , что лучше и кого какие недостатки, да и в консоле многие умеют многое сделать, имхо особенно те кто работает в никсовых системах, они более приспособлены к консоле , нежели к гуи

Автор: SergeBS 19.10.2006, 07:35

Shiny,  Цитата Как консоль, где всё руками пишется, может быть проще чем нормальный интерфейс администрирования, где часть задач оболочка "подсказывает" и не нужно бояться в каждой букве сделать ошибку??? Смотри ссылки. Я не настолько фанат командной строки, чтобы имея нормальный GUI-инструмент ковыряться в консоли. Особенно если инструментов несколько. В отличие от MS SQL.

Автор: pythonwin 20.10.2006, 09:14

Цитата(Shiny @  19.10.2006,  01:01 ) Как консоль, где всё руками пишется, может быть проще чем нормальный интерфейс администрирования, где часть задач оболочка "подсказывает" и не нужно бояться в каждой букве сделать ошибку??? я работаю в pg через командную строку, хотя есть pgAdminIII  Добавлено @ 09:15  и не боюсь делать ошибки - главное снять BackUp, если так уж сильно важная инфа в базах.

Автор: chief39 24.10.2006, 10:32

Цитата(Shiny @  17.10.2006,  13:53 ) SergeBS,  Я довольно плотно уже 3 года работаю с MS SQL Server 2000, доводилось разрабатывать и небольшую CRM-систему, и распределённую базу по регионам страны - в общем, знаю базы данных не по наслышке. НО Когда год назад передо мной стала задача разработать простейший курсач в универе с использованием MySQL, я мучалась с ним 2 недели и в результате напарила чёрти что. Причина - отсутствие интуитивного интерфейса. Любой инсерт, апдейт, альтер - будь любезна из командной строки. Я-то написать его могу, и писала собственно, но как можно новичку, который плавает в этих вещах, начать с нуля - понимаю слабо. К чему собственно всё это У меня просьба Подскажите, с какой стороны подходить к вот таким вот СУБД а-ля MySQL, PostgreSQL и т.д. Они кажутся безумно трудозатратными по сравнению с MS SQL Server!!! Ну.... три года с МССКЛсервером предполагают более близкое ознакомление с СКЛ  А интуитивный интерфейс - это интуитивный интерфейс... У каждой СУБД свой и не один. В то время как та самая нелюбимая "командная строка" - это стандарт СКЛ, благодаря которому мы так спокойно и можем обсуждать выбор СУБД для простейших задач.  Ибо, за исключением мелочей, различий нет. Для быстрого кропания таблиц для курсача, безусловно, лучше ГУЙ. Но я не встречал компании, где есть план "даёшь не меньше десяти новых таблиц в день!!!". И при создании новой надо бы проверить как она встыковывается в систему и в скрипты правильно вписать.  А вот  Цитата(Shiny @  17.10.2006,  13:53 ) Я-то написать его могу, и писала собственно, но как можно новичку, который плавает в этих вещах, начать с нуля - понимаю слабо. - совсем плохо. Потому как перетянуть кнопку или ответить "Да" на вопрос "вы хотите создать таблицу по шаблону?" - это отлично.... Но понимать что происходит, когда нажимаешь "Да" - ещё лучше. Цитата(Shiny @  18.10.2006,  18:01 ) Т.е. ты хочешь сказать что к консоли можно привыкнуть и воспринимать её как должное? Нужно... не обязательно ей всегда пользоваться, но знать и ПОНИМАТЬ - надо. А в ГУИ можно напортачить ничуть не хуже, лихо кликая "крысой". И потом сказать "упс!" Кстати, для ознакомления очень пойдёт скриптовый скл: Написал скрипт с одной табличкой - запустил, написал ещё один с дропом - запустил. Следующую дописал... инсерты добавил... ключи... Вместо пулемётной очереди кликов по образцу скриншотов из "книги по базам данных и прочим вордам в акцесссе". Потом появляются люди, которые думают что таблица "живёт в программе" на подобие Экселя. Видел такое )) Так что лучше изучать язык с алфавита, чем потом с удивлением узнавать о "каких-то там буквах..."

Автор: Shiny 24.10.2006, 11:29

Цитата(chief39 @  24.10.2006,  10:32 ) Так что лучше изучать язык с алфавита, чем потом с удивлением узнавать о "каких-то там буквах..." в целом ты прав. Вообще изучение баз данных я начала именно с этого. Я могу уверенно сказать, что транзакт СКЛ знаю хорошо, и могу написать руками любой запрос, НО! ЗАЧЕМ? Тратить на создание таблицы 15-20 минут, тщательно проверяя все синтаксисы и запятые, если можно это сделать в ГУИ на порядки быстрее? Цитата(chief39 @  24.10.2006,  10:32 ) А в ГУИ можно напортачить ничуть не хуже, лихо кликая "крысой". И потом сказать "упс!" Такие команды как UPDATE и DELETE любой сложности я всегда пишу руками - тут нужна предельная внимательность, но зачем извращаться создавая таблицы, меняя название колонки или тип поля?? Это лишнее (ИМХО) Цитата(chief39 @  24.10.2006,  10:32 ) И при создании новой надо бы проверить как она встыковывается в систему и в скрипты правильно вписать.  А сначала всё-всё продумать, а потом написать, чтоб проверять лишний раз не надо было - не получается? Цитата(chief39 @  24.10.2006,  10:32 ) Потому как перетянуть кнопку или ответить "Да" на вопрос "вы хотите создать таблицу по шаблону?" - это отлично.... Но понимать что происходит, когда нажимаешь "Да" - ещё лучше. Повеселило  Так талантливо перемешать грешное с праведным надо уметь. ГУИ - это обязательно шаблоны? Не думаю! Цитата(chief39 @  24.10.2006,  10:32 ) выбор СУБД для простейших задач К сожалению, этап простейших задач для меня уже давно пройден...  Полтора года назад я разрабатывала CRM-систему, на момент моего увольнения в ней было полторы сотни таблиц - половина справочного характера, половина - сами данные. Поверь, если бы я её делала из консоли, "алфавитом" + админила это всё счастье + писала для него оболочки + объясняла сотне юзверей что с этим всем делать, мне бы в сутках и сотни часов не хватило.... Я говорила не о использовании консоли для обучения, а о создании и администрировании больших, возможно даже распределённых систем через консоль. Цитата(chief39 @  24.10.2006,  10:32 ) знать и ПОНИМАТЬ - надо Это и школьнику понятно Цитата(chief39 @  24.10.2006,  10:32 ) не обязательно ей всегда пользоваться Цитата(chief39 @  24.10.2006,  10:32 ) У каждой СУБД свой и не один. Это я и хотела знать. Спасибо

Автор: chief39 24.10.2006, 14:20

Цитата(Shiny @  24.10.2006,  11:29 )  Так талантливо перемешать грешное с праведным надо уметь. ГУИ - это обязательно шаблоны? Не думаю! Я немного утрировал. Под впечатлением от идеального интерфейса: "сделать чтоб было хорошо? - да! - уже сделано хорошо!". Но суть остаётся - стараясь минимизировать усилия, приходится многое возлагать на "умность" "умного" клиента. Цитата(Shiny @  24.10.2006,  11:29 ) Такие команды как UPDATE и DELETE любой сложности я всегда пишу руками - тут нужна предельная внимательность, но зачем извращаться создавая таблицы, меняя название колонки или тип поля?? Это лишнее (ИМХО) Мммм... изменение колонки или типа поля на "боевой" БД не менее важны. У меня(и не только) часто встречались ситуации, когда надо было тонкими манёврами изменить табличку, аккуратно перестроив другие и так же аккуратно сманипулировать данными на "живой" БД. По-моему, ничего лучше, чем написать последовательность команд, прогнать на тестовом и запустить, нету. И если работает хорошо - то на боевом уже не запорешь, как правило - просто запускаешь скрипт без изменений Цитата(Shiny @  24.10.2006,  11:29 ) Тратить на создание таблицы 15-20 минут,    Для таблиц с количеством столбцов, измеряемым в десятках. Обычно это одна минутка. Цитата(Shiny @  24.10.2006,  11:29 ) Поверь, если бы я её делала из консоли, "алфавитом" + админила это всё счастье + писала для него оболочки + объясняла сотне юзверей что с этим всем делать, мне бы в сутках и сотни часов не хватило.... Ммм... не верю. (Отметаем юзверей и оболочки - для сравнения путей эскьюэлирования они абсолютно лишние. так же как и дорога домой/на работу.) Работал как-то в компании, количество таблиц было ~600-700. Всё прекрасно успевалось. Причём скрипты прекрасно ложились на ЦВС и структурой можно было манипулировать просто таки превосходно. Несколькими запусками скриптов. Цитата(Shiny @  24.10.2006,  11:29 ) А сначала всё-всё продумать, а потом написать, чтоб проверять лишний раз не надо было - не получается? Не получается. Не знаю таких людей. Ошибки свойственны людям. Даже если "всё-всё продумать". Вот и перепроверяют люди. А если делать по очереди knock out для десятки табличек - можно случайно мышкой попасть не на ту и через пару секунд уже сказать "@#$#!"... То есть "УПС!" В общем... Для начинания стоит брать консоль и понимать как это работает. И если уж очень припрёт, с большим мешком опыта... Тогда плиз..  ЗЫ: А вообще это дело привычки.  Но пока механизмы не понятны досконально - к гуи лучше не привыкать... ;)

Автор: Shiny 24.10.2006, 15:09

Цитата(chief39 @  24.10.2006,  14:20 ) У меня(и не только) часто встречались ситуации, когда надо было тонкими манёврами изменить табличку, аккуратно перестроив другие и так же аккуратно сманипулировать данными на "живой" БД. В моей работе это - единичные случаи, я не приняла их во внимание... Но полностью согласна - при такой задаче скрипты и только скрипты... Цитата(chief39 @  24.10.2006,  14:20 ) Для таблиц с количеством столбцов, измеряемым в десятках. Нну... У меня было в большинстве дата-таблиц действительно больше 10-ти полей... А в некоторых намного больше... Цитата(chief39 @  24.10.2006,  14:20 ) Отметаем юзверей и оболочки - для сравнения путей эскьюэлирования они абсолютно лишние.  Я имела ввиду что делала это всё одна. И так еле справлялась, а если б ещё руками таблички писала и меняла - померла бы. (мы же говорим в целом о работе, а не о тепличных условиях - хорошо, если тебе такие создали и можно отстранённо сравнивать ту или иную производительностьь отдельной СУБД, а если нет и приходится оптимизировать скорость работы как только можно, и ни в коем случае не во вред качеству?) Цитата(chief39 @  24.10.2006,  14:20 ) А если делать по очереди knock out для десятки табличек - можно случайно мышкой попасть не на ту и через пару секунд уже сказать "@#$#!"... Ну для этого и нужны глаза чтоб смотреть куда кликать...  Честно сказать не знаю что такое knock out, но в любом случае из-за случайного клика у меня не было ни одного случая чтоб сказать "@#$#!". В основном такие фразы вылетают именно когда скрипт пишу руками и что-то забываю или лишнее пишу... Цитата(chief39 @  24.10.2006,  14:20 ) Причём скрипты прекрасно ложились на ЦВС и структурой можно было манипулировать просто таки превосходно. Несколькими запусками скриптов. Это совсем другая структура работы, не знакомая мне.... Может, она и лучше чем ГУИ, если доведётся когда-нибудь так работать - смогу сравнить...

Автор: chief39 24.10.2006, 16:13

Цитата(Shiny @  24.10.2006,  15:09 ) knock out,  - ничего специфического  просто дословно перевести типпа... "вынести" таблицу нафик  Цитата(Shiny @  24.10.2006,  15:09 ) Я имела ввиду что делала это всё одна. Цитата(Shiny @  24.10.2006,  15:09 ) мы же говорим в целом о работе, а не о тепличных условиях Это как раз плохо :-/ Этим должны заниматься разные люди. Не для тепличности условий а для большей эффективности. Хотя "единовластие" в нашем зачаточном айти-бизнесе ещё распространено. И ето плохо :-/ Цитата(Shiny @  24.10.2006,  15:09 ) Ну для этого и нужны глаза чтоб смотреть куда кликать...  Не ответ. В момент любого действия возможна ошибка. Я о том говорил, что в скрипте, совершив её, ещё не раз можешь перепроверить перед его запуском. Цитата(Shiny @  24.10.2006,  15:09 ) Это совсем другая структура работы, не знакомая мне.... Может, она и лучше чем ГУИ, если доведётся когда-нибудь так работать - смогу сравнить... Ок  В любом случае... litle_bee, начинай с консоли. И... начинай с mysql. Почему? Потому что он лёгкий, бесплатный, распространённый, отлаженный. И на этом же форуме чрезвычайно много майэскьюэльщиков. Да и почти любой пхпист его немного да трогал  Можно, конечно, бегать, сравнивать в мелочах с другими... Но сейчас это почти стандарт де-факто для мелких задач. Как автомат калашникова - прост, надёжен, всегда под рукой, патронов под него - хоть залейся и всегда есть спецы по нему.

Автор: boevik 24.10.2006, 17:18

Цитата(Shiny @  24.10.2006,  15:09 ) Ну для этого и нужны глаза чтоб смотреть куда кликать...  Честно сказать не знаю что такое knock out, но в любом случае из-за случайного клика у меня не было ни одного случая чтоб сказать "@#$#!". В основном такие фразы вылетают именно когда скрипт пишу руками и что-то забываю или лишнее пишу... Цитата(chief39 @  24.10.2006,  16:13 ) Не ответ. В момент любого действия возможна ошибка. Я о том говорил, что в скрипте, совершив её, ещё не раз можешь перепроверить перед его запуском. Полностью согласен с chief39, сделать ошибку в скрипте да так что бы , что либо испортилось намного сложнее чем кликая по менюшкам. Обычные ошибки в скрипте, это запятую забыл, скобку не закрыл и т.п. Эти ошибки, падают на синтаксисе и не выполняются. А о том, как стирал базы/таблицы кликая по менюшкам у меня имеется свой реальный прискорбный опыт.

Автор: Shiny 24.10.2006, 17:43

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

Автор: pythonwin 24.10.2006, 17:56

Цитата(Shiny @  25.10.2006,  00:43 ) Уговорил smile С этим согласна И, если бы у меня было 100 постов, накатала бы тебе + за упорство в споре smile Это решаемо!  chief39, ++1

Автор: Shiny 24.10.2006, 18:05

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

Автор: batigoal 24.10.2006, 21:08

Цитата(Shiny @  24.10.2006,  18:43 ) Из-за того что действие не разделено явно на шаги, а является большим текстом ошибку можно и пропустить Зато человеческий фактор меньше

Автор: SergeBS 25.10.2006, 08:39

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

Автор: chief39 25.10.2006, 09:17

Цитата(Shiny @  24.10.2006,  17:43 ) И, если бы у меня было 100 постов, накатала бы тебе + за упорство в споре Цитата(Shiny @  24.10.2006,  17:43 ) НО! Я всё равно считаю, что скриптами создавать и модифицировать таблицы, настраивать репликации и т.п. намного дольше и сложнее. Мы ещё изменим это мнение    Цитата(Shiny @  24.10.2006,  17:43 ) чем долго искать её поиском в тексте и в результате найти не то, что надо Нууу... как это?  "Ищите да обрящете"  Если знаешь что искать - почему бы это и не найти? Кроме того, никто не отменял подробные толковые комментарии. Если их нет - плоххххо.... очень плохо. Цитата(SergeBS @  25.10.2006,  08:39 ) Только вот насчет ошибок и т.п. главным пунктом является не чем править, а где: на тестовой базе. В большинстве случаев - просто копии рабочей базы, но не на боевом сервере, а на рабочей станции. А когда на ней все стало нормально, перетащил готовые скрипты и все. Я упоминал это  ГУЙ может быть неплох, когда случилось огромное горе, рабочая уже пошла вразнос и надо срочно исправлять по живому. Но тут и консолью можно справиться хорошо  А вот в случае нормального использования тестовой БД и последующего переноса скриптов - ключевое всё-таки  Цитата(SergeBS @  25.10.2006,  08:39 ) перетащил готовые скрипты и все Ну это мы отклонились всё-таки.... Интересно поглядеть как там дела у Маленькой Пчелы с выбором и употреблением СУБД....

Автор: TaNK 11.11.2006, 13:33

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

Автор: dvska 14.11.2006, 22:04

Цитата(litle_bee @ 15.10.2006,  18:20) Дано: Гос. предприятие (академия повышения квалификации) Требования начальства на данный момент - упорядоченное ведение данных о клиентах с возможностью выборки по разным параметрам, дальше процитирую: "Чтобы можно было печатать конверты с данными клиентов, извлекая из базы, а не набивая руками..." (На данный момент вся информация хранится в вордовских и экселевских файлах...) Программистов в предприятии НЕТ! Есть пара сисадминов и вебмастер. Остальной состав конторы - преподаватели, организаторы, бухгалтерия и кадровики... Как вывод, точной технической задачи мне дать не могут. Мой взгляд в будущее - как только они получат то, что хотят на данный момент, захотят еще чего-нибудь. Так вот: Мне надо выбрать, на чем делать им базу. Она должна делаться оперативно, но с последующим развитием. (как пример, сейчас они готовы на реляционную базу на моей машине, а самим бегать ко мне за всеми данными... ) Но с постепенно надо развивать и саму базу и переводить ее в разряд распределенных... З.Ы. Простите, мудрые программисты, если этот вопрос покажется глупым, но это мой первый опыт работы (я еще студентка и реальную работу ручками до сих пор не щупала)... Предлагаю рассмотреть альтернативный вариант -- пойти по пути установки и кастомизации готовой OpenSource CRM-системы, например http://tinyerp.com или http://erp5.org.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)