Если база большая то MySQL + ADO. Мощьная, не увесистая (в отличие от DB2 и Oracle), нормально работает как в сети так и локально.
ЗЫЖ всеголиш скромное ИМХО.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Базы данных и репортинг > Выбор СУБД |
| Автор: Olimpic21 17.5.2006, 10:36 |
| нужно спроектировать БД если вместе со всеми справочниками то таблиц там может быть 20-30 и более .... записей в основных таблицах тоже порядочно будет ... она будет локальная ... и соответственно приложение для работы с ней на дельфи ... посоветуйте какую СУБД выбрать для этих целей??? ... просто я не со всеми еще знаком и не все положительные/отрицательные стороны каждой из них знаю ... |
| Автор: drkot 17.5.2006, 11:00 |
| Если количество записей в одной таблице примерно до 10000 то можно использовать Paradox (можно и Access но это на любителя). Если база большая то MySQL + ADO. Мощьная, не увесистая (в отличие от DB2 и Oracle), нормально работает как в сети так и локально. ЗЫЖ всеголиш скромное ИМХО. |
| Автор: Kesh 17.5.2006, 11:26 |
| Olimpic21, можешь Interbase использовать... |
| Автор: Snowy 17.5.2006, 11:30 |
| http://forum.vingrad.ru/index.php?showtopic=30912&view=all !!! Добавлено @ 11:32 Уже обсуждалось 154 раза. По этому линку все подробно расписано. |
| Автор: Olimpic21 17.5.2006, 12:18 |
| а Firebird подойдет для моих целей? база не такая и большая но записей скорее всего более 10000 то будет ...на вариант MySQL + ADO наверно упадет мой выбор |
| Автор: drkot 17.5.2006, 12:31 | ||||
Это тотже интербейс тока альтернативный (бесплатный и чуть чуть более глючный чем фирменный ИМХО)
решение хорошее. Теперь совет: не бери последнюю версию - глючная. Ищи примочку которая соединяет MySQL c ADO (мелкие об этом не позаботились). Ну и форумы с мануалами почитывай не брезгуй. |
| Автор: Olimpic21 17.5.2006, 12:44 |
| можно поподробнее про примочку для соединения MySQL c ADO? времени на чтение мало ... диплом делаю и на работе задачу надо начать решать ... а работал пока только с ораклом акцессом и парадоксом которые ... скорее всего здесь не подойдут Добавлено @ 12:45 про Firebird ...я с интербейсом не работал ... но я так понимаю он на большую бд не расчитан? |
| Автор: Kesh 17.5.2006, 13:40 |
| Olimpic21, расчитан-расчитан... Но сам я предпочитаю MySQL |
| Автор: drkot 17.5.2006, 14:14 | ||||
если диплом то лучше парадокс + известен он тебе.
усе дома. надеюсь до завтра потерпишь. Если нет то рекомендации в привате. |
| Автор: Alex 18.5.2006, 00:29 | ||
Информация по одной системе: * InterBase 7.5.1 * 40-50 одновременных пользователей * размер базы данных 65 гигабайт * ~450 тысяч транзакций в сутки * 800 таблиц (50 гигабайт данных), 1200 индексов (11.5 гигабайт)  |
| Автор: Петрович 18.5.2006, 00:42 | ||
Скорее наоборот Да и с чего было взято что "на большую БД он не расчитан". Если большая БД это с гиг и более, то возможно это и не лучший выбор. Но в этом случае, думаю и MySQL не лучший выбор. А для твоего случая, FB/IB, вполне нормальный выбор. Кстати, у FB есть такой вариант как "встроенный" сервер. Он позволяет построить однопользовательское приложение с минималоьным использованием внешних файлов. Т.е. в этом варианте сам SQL-сервер представляет собой просто DLL, не требующую какой-либо предварительной инсталяции. Но, если у тебя речь не идет об обязательном использовании SQL-сервера, нет многопользовательской работы, то, максимальную скорость разработки ты получишь на любой знакомой тебе СУБД. Даже Paradox и Access вполне подойдут. |
| Автор: drkot 18.5.2006, 17:02 | ||
Тебе понадобится: mysql-connector-odbc-3.51.12-win32.zip (ado) mysql-workbench-1.0.6-beta-win32.msi (проектировка базы) mysql-administrator-1.1.9-win.msi это все метров 30 + сам MySQL 40. если хочеш могу бросить на почту  |
| Автор: Alex 18.5.2006, 22:16 | ||
Мама... и это для маленькой БД  |
| Автор: Palladin 18.5.2006, 23:36 |
| Если ты только начал используй вкладку ADO и БД Access, ADO проще всех остальных и его более просто освоить |
| Автор: blur 19.5.2006, 01:55 | ||||
Если работать с MySql, то лучше использовать компоненты ZEOS и не надо никаких BDE, ODBC. Добавлено @ 01:57
У MySql это тоже есть. |
| Автор: drkot 19.5.2006, 15:13 | ||||
Есть еще урезаный вариант MySQL в составе пакета Denver (около 5 метров) но неуверен в полноте комплектации.
а поподробнее в чем превосходство и насколько легко адаптировать проги работающие через ODBC. |
| Автор: blur 19.5.2006, 22:38 | ||
Преимущество в том, что при переносе приложения не нужно устанавливать ODBC на другом компе. |
| Автор: skyboy 19.5.2006, 23:11 |
| drkot, не совсем понятно. Если изначально не планируется переход на другую СУБД - есть ли смысл обеспечивать универсальность и адаптируемость? |
| Автор: drkot 20.5.2006, 11:54 |
| Принципиально перейти от одной базы данных на дурую не сложно. Необходимо составить таблицу совместимости типов и принять решение о том, какие типы в старой базе будут заменены в новой. Редко когда эта операция требует радикально переписывать код. По вопросу универсальности и адаптируемость. Это правило для комерческих продуктов (иначе техподдержка повесится  ) и рекомендация для своботного по (некто взяв программу надеется что она заработает и никак не расчитывает на на долгие часы долбания и тчетные попытки понять почемы не работает)В общем процесс творческий и носит исключительно рекомендательный характер. |
| Автор: Alex 20.5.2006, 12:58 | ||
Ребят заранее прошу извинения, если кого-то обижу, но читаю я ваши доводы, умозаключения и понимаю, что люди не имеют никакого представления о современной БД, не писали ни одного серьезного проекта. Вы подходите к БД с точки зрения тупого хранилища данных для таких целей вам хватит обычного Access или даже dbf-файлов. Для любого современного мало мальски значимого проекта таких возможностей БД уже не достаточно. При современной разработке БД вам обязательно захочется использовать расширения SQL языка (кто же откажется на этапе выборки, к примеру, в зависимости от значения какого-то булевского поля вернуть при истина один результат, при ложь другой?), триггеру при добавлении, изменении и удалении данных, хранимые процедуры, представления, пользовательские функции. И все активно этим пользуются, но вот не задача каждый SQL сервер имеет свой внутренний синтаксис и как только вы начинаете использовать, к примеру, хранимые процедуры вы уже привязываете свою БД к конкретному серверу. Перенести хорошую БД с одного SQL сервера на другой долгий, кропотливый труд, а иногда и не осуществимый без серьезной переделки структуры БД. |
| Автор: drkot 20.5.2006, 13:22 |
| А здесь и не идет речь о корпоративных базах данных Тема больше сползла в сторону культуры кода, как такового. И даже не внешней красоты оформления как самого алгоритма. А по поводу "несерьезности" обсуждаемого проекта спорить не буду, но курсокой (или диплом) и не должен быть сверх серьезным это просто опыт обучение. Главное чтоб человек стремился познать новое и совершенствовался, а не тупо просил: "дайте код. времени нет" и тому подобное. Каждый проект на своем (личном) этапе развития самый серьезный. Когда я смотрю на исходники написаные мной в 96 году хочется плакать, думаю спустя некоторое время буду также относится к сегодняшним проектам. |
| Автор: Akella 20.5.2006, 13:30 |
| На своём опыте хочу посоветовать не использовать Paradox. Хотябы потому что проблемы с индексами, особено с первичными. Простой пользователь (которому ты отдашь свое приложение) не сможет пересоздать/отремонтировать первичный индекс. И средствами Delphi у меня так и не получилось пересоздание/ремонт первичных индексов. можно, конечно создать новое поле, а старое поле ID удалить. А если это связка Master-Detail то у мастер таблицы при удалении ID-поля потеряется связь с детальной. Короче геморно. Я даже использовать парочку программ для ремонт Paradox`а. Первичные индексы эти программы так и не смогли восстановить. |
| Автор: Alex 20.5.2006, 13:41 | ||||
Заявленные 20-30 таблиц на уж очень простую БД тоже не тянет
96 это в обще другое программирование и скорей всего начала вашего изучения программирования (хотя могу ошибаться). Лично у меня от исходников написанных года 4 назад конечно веет неграмотностью в полную силу, но те, которые писались года два назад уже по большей части нормально и желания все переписать не возникает, хотя знаний понятное дело сейчас больше и сейчас что-то писалось бы по другому. |
| Автор: Alex 20.5.2006, 13:58 |
| Olimpic21, 20-30 таблиц это конечно не большая БД, но все же уже полноценная БД. Какую БД выбрать для хранения этих таблиц решать вам. Но сядьте и подумайте такие моменты т.к. это курсовик, то возникает вопрос, нужно ли будет эту программу запускать перед преподавателем или что еще хуже отдавать ему домой для проверки. Узнайте, может на тех компьютерах где предстоит запускать уже стоит какой-то SQL сервер, если да, то удобней наверно будет писать под него, т.к. вы знаете. что вам не нужно тащить и устанавливать, настраивать еще его для запуска программы если преподаватель хочет забрать программу для проверки дома, то тут сложнее, т.к. преподавателю самому придется установить сервер и его настроить (не каждый на это способен )Идеальный вариант, что какой-то сервер все же стоит, т.к. заставить что-то поставить на компьютеры в учебных заведениях это бывает практически не реальная задача, а сами вы не можете поставить, т.к. обычно прав администратора вам ни кто не дает .Самым наверно универсальным решением как это не прискорбно заявлять является хранить в БД Access, а в качестве технологии доступа использовать ADO, т.к. драйвер для доступа к Access имеется практически на всех машинах (где офис установлен, а его редко кто в нашей стране не ставит) |
| Автор: skyboy 20.5.2006, 15:17 |
| В зависимости от того, как используются таблицы(количество их ещё ничего не говорит о структуре) я бы мог предложить не один компонент, который поддерживает работу с каким-то собственным форматом БД. Скорость будет низкая(большинство форматов баз - это CVS), но зато гарантирована абсолютная переносимость Так что может посмотреть структуру? Alex, не обидел Я сам виноват, перепутал тему  Подумал про Парадокс.. http://forum.vingrad.ru/index.php?showtopic=96875 А триггеры могут и не понадобиться, хотя без stored routines и правда очень сложно бывает... |
