Есть еще урезаный вариант MySQL в составе пакета Denver (около 5 метров)
но неуверен в полноте комплектации.


а поподробнее в чем превосходство и насколько легко адаптировать проги работающие через ODBC. 

Преимущество в том, что при переносе приложения не нужно устанавливать ODBC на другом компе.
 

drkot, не совсем понятно. Если изначально не планируется переход на другую СУБД - есть ли смысл обеспечивать универсальность и адаптируемость?  

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

По вопросу универсальности и адаптируемость.
Это правило для комерческих продуктов (иначе техподдержка повесится   ) и рекомендация для своботного по (некто взяв программу надеется что она заработает и никак не расчитывает на на долгие часы долбания и тчетные попытки понять почемы не работает)

В общем процесс творческий и носит исключительно рекомендательный характер. 

Ребят заранее прошу извинения, если кого-то обижу, но читаю я ваши доводы, умозаключения и понимаю, что люди не имеют никакого представления о современной БД, не писали ни одного серьезного проекта. Вы подходите к БД с точки зрения тупого хранилища данных для таких целей вам хватит обычного Access или даже dbf-файлов. Для любого современного мало мальски значимого проекта таких возможностей БД уже не достаточно. При современной разработке БД вам обязательно захочется использовать расширения SQL языка (кто же откажется на этапе выборки, к примеру, в зависимости от значения какого-то булевского поля вернуть при истина один результат, при ложь другой?), триггеру при добавлении, изменении и удалении данных, хранимые процедуры, представления, пользовательские функции. И все активно этим пользуются, но вот не задача каждый SQL сервер имеет свой внутренний синтаксис и как только вы начинаете использовать, к примеру, хранимые процедуры вы уже привязываете свою БД к конкретному серверу. Перенести хорошую БД с одного SQL сервера на другой долгий, кропотливый труд, а иногда и не осуществимый без серьезной переделки структуры БД.  

Это сообщение отредактировал(а) Alex - 20.5.2006, 12:59

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

А по поводу "несерьезности" обсуждаемого проекта спорить не буду, но курсокой (или диплом) и не должен быть сверх серьезным это просто опыт обучение. Главное чтоб человек стремился познать новое и совершенствовался, а не тупо просил: "дайте код. времени нет" и тому подобное.

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

 

На своём опыте хочу посоветовать не использовать Paradox. Хотябы потому что проблемы с индексами, особено с первичными. Простой пользователь (которому ты отдашь свое приложение) не сможет пересоздать/отремонтировать первичный индекс. И средствами Delphi у меня так и не получилось пересоздание/ремонт первичных индексов. можно, конечно создать новое поле, а старое поле ID удалить.
А если это связка Master-Detail то у мастер таблицы при удалении ID-поля потеряется связь с детальной. Короче геморно.
Я даже использовать парочку программ для ремонт Paradox`а. Первичные индексы эти программы так и не смогли восстановить. 

  

Заявленные 20-30 таблиц на уж очень простую БД тоже не тянет  


96 это в обще другое программирование и скорей всего начала вашего изучения программирования (хотя могу ошибаться).

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

Это сообщение отредактировал(а) Alex - 20.5.2006, 13:42

Olimpic21, 20-30 таблиц это конечно не большая БД, но все же уже полноценная БД. Какую БД выбрать для хранения этих таблиц решать вам. Но сядьте и подумайте такие моменты т.к. это курсовик, то возникает вопрос, нужно ли будет эту программу запускать перед преподавателем или что еще хуже отдавать ему домой для проверки.
Узнайте, может на тех компьютерах где предстоит запускать уже стоит какой-то SQL сервер, если да, то удобней наверно будет писать под него, т.к. вы знаете. что вам не нужно тащить и устанавливать, настраивать еще его для запуска программы если преподаватель хочет забрать программу для проверки дома, то тут сложнее, т.к. преподавателю самому придется установить сервер и его настроить (не каждый на это способен  )
Идеальный вариант, что какой-то сервер все же стоит, т.к. заставить что-то поставить на компьютеры в учебных заведениях это бывает практически не реальная задача, а сами вы не можете поставить, т.к. обычно прав администратора вам ни кто не дает  .

Самым наверно универсальным решением как это не прискорбно заявлять является хранить в БД Access, а в качестве технологии доступа использовать ADO, т.к. драйвер для доступа к Access имеется практически на всех машинах (где офис установлен, а его редко кто в нашей стране не ставит)  

Это сообщение отредактировал(а) Alex - 20.5.2006, 23:39

В зависимости от того, как используются таблицы(количество их ещё ничего не говорит о структуре) я бы мог предложить не один компонент, который поддерживает работу с каким-то собственным форматом БД. Скорость будет низкая(большинство форматов баз - это CVS), но зато гарантирована абсолютная переносимость  Так что может посмотреть структуру? 
Alex, не обидел  Я сам виноват, перепутал тему   Подумал про Парадокс.. 
http://forum.vingrad.ru/index.php?showtopic=96875
А триггеры могут и не понадобиться, хотя без stored routines и правда очень сложно бывает...