Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки.
Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
MS Access
если __обязательно__ хочется open source, то mySQL
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
MySQL для этого вполне подойдёт.
он бесплантый + Open Source + хорошая производительность и куча документации.
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Visual FoxPro. Все, что требуется для работы — это одна DLL размером 1,2 м VFP OLEDB провайдера, которую можно загрузить здесь. Движок базы встроен в провайдер. Компактней не бывает.
Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
D>MySQL для этого вполне подойдёт. D>он бесплантый + Open Source + хорошая производительность и куча документации.
А что, уже есть нативный порт этого эээ... сервера, под Win32 ?
К вопрошавшему, или бери MSJet или Yaffil Personal (клон Interbase). Если сильно хочется Open Source, то FireBird Embeded.
Здравствуйте, Alex.Che, Вы писали:
AC>Здравствуйте, Dimka, Вы писали:
AC>Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
D>>MySQL для этого вполне подойдёт. D>>он бесплантый + Open Source + хорошая производительность и куча документации.
AC>А что, уже есть нативный порт этого эээ... сервера, под Win32 ?
а что это значит ??
MySQL Server отлично работает под Win32. а вот нативный он или нет мне не известно ...
Здравствуйте, Alex.Che, Вы писали:
AC>Здравствуйте, Dimka, Вы писали:
AC>Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
D>>MySQL для этого вполне подойдёт. D>>он бесплантый + Open Source + хорошая производительность и куча документации.
AC>А что, уже есть нативный порт этого эээ... сервера, под Win32 ?
уже _очень_ давно (несколько лет).
сейчас в процессе сертификации (for Windows XP)
нубор "родных" гуёвых компонеет.
Здравствуйте, Dimka, Вы писали:
D>>>MySQL для этого вполне подойдёт. D>>>он бесплантый + Open Source + хорошая производительность и куча документации. AC>>А что, уже есть нативный порт этого эээ... сервера, под Win32 ? D>а что это значит ?? D>MySQL Server отлично работает под Win32. а вот нативный он или нет мне не известно ...
Люди имеют ввиду, работает ли он сам, или только с дополнительным компонентом — эмуляцией unix (cygwin)
(например так до последнего времени работал PostgreSQL)
mySQL сервер работает сам, без всяких примочек, т.е. native-но.. Как все норомальный native-ные серверные win-компоненты
может запускаться как сервис.
Вот стандартный текстовый клиент для него (в виде командной строки, с unix-подобной системой истории,
поиска и т.д. введённых команд) действительно нуждается в cygwin.
Хотя под виндой обычно используют не его, а соответствующие gui-компоненты.
Здравствуйте, algol, Вы писали:
A>Здравствуйте, vvaizh, Вы писали:
>> -1
A>Интересно было бы узнать, что именно вызвало Ваше несогласие. Я так понял, что на 10000 записей нужно что-то типа MS SQL или Oracle.
Вообще говоря, несогласие без аргументов тут можно с полным основанием рассматривать просто как "мне такое не нравится"
Но тут я могу и объяснить своё мнение:
ИМХО Foxpro устаревшая неразвивающаяся система, имеющая множество специфичный непереносимых на другие среды черт..
Тот же Access например в последствии можно легко и постепенно переносить на более серъёзный движок, а вот как это выглядит в случае FoxPro я затрудняюсь сказать, поэтому и не согласен..
Здравствуйте, Alex.Che, Вы писали:
AC>Здравствуйте, vvaizh, Вы писали:
AC>>>А что, уже есть нативный порт этого эээ... сервера, под Win32 ? V>>уже _очень_ давно (несколько лет).
AC>Да что вы говорите AC>А как же Cygwin ??
Читайте сообщение выше.. cygwin требуется только для unix-like текстового клиента
(для апологетов командной строки так сказать). то есть для одной из утилит,
которая не является обязательной частью системы..
Весь сервер (т.е. вся работа с сокетами, мутексами тредами и т.д. что есть ещё специфичного в ОС)
написан без всякой эмуляции unix на основе родных Win вызовов
(естественно исходники одни и для win и для unix с условной компиляцией и отдельными VS *.dsw файлами)
Надеюсь вы краснеете..
V>>сейчас в процессе сертификации (for Windows XP) V>>нубор "родных" гуёвых компонеет. AC>Наверное имелись в виду "гуёвые" инструменты. AC>Или таки компоненты?
Имелось ввиду именно то что сказалось.
Лекции по русскому языку здесь разводить не советую
D>MySQL для этого вполне подойдёт. D>он бесплантый + Open Source + хорошая производительность и куча документации.
Всем спасибо за советы.
Есть еще одно условие — легкость настройки, т.е. ПО будет с базой и надо чтоб его можно было поставить без особых проблем, в идеале одна кнопочка Install и все, ну или что-то в этом духе.
Здравствуйте, h256, Вы писали:
D>>MySQL для этого вполне подойдёт. D>>он бесплантый + Open Source + хорошая производительность и куча документации.
H>Всем спасибо за советы. H>Есть еще одно условие — легкость настройки, т.е. ПО будет с базой и надо чтоб его можно было поставить без особых проблем, в идеале одна кнопочка Install и все, ну или что-то в этом духе.
Все они по своему просты (MS Access, mySQL, Firebird)
Но в то же время со всеми возможны проблемы (включая "родной" MS Access )
Ещё кстати вопрос — а на чём клиент будет..
MS Access просто сам по себе неслабый клиент, особенно если опыта с CУБД мало..
c другой стороны mySQL и Yaffi доступны как embedded.. т.е. вообще в виде lib-ы
Но вот клиентские возможности у них гораздо скромнее..
с другой стороны у Access скромнее серверные возможности, но опять же вашим требованиям он вполне вроде удовдетворяет,
если же требования будут расти, то возможно постепенная миграция на что то более мощное..
Здравствуйте, vvaizh, Вы писали:
V>Вообще говоря, несогласие без аргументов тут можно с полным основанием рассматривать просто как "мне такое не нравится"
Конечно каждый имеет право на свое мнение, которое он не обязан объяснять. Но я и не настаивал. Просто меня очень удивило, что оказывается Fox для обработки 1000 записей не подходит, а MySQL — в самый раз. Зачем стрелять в воробьев из пушки? Давайте взрывать их водородной бомбой.
V>Но тут я могу и объяснить своё мнение: V>ИМХО Foxpro устаревшая неразвивающаяся система, имеющая множество специфичный непереносимых на другие среды черт..
Вот это ИМХО так ИМХО! Да будет Вам известно, что сейчас новые версии FoxPro выходят ежегодно. Вот в этом году вышел VFP8.0, в сентябре выйдет к нему service pack, готовится к выпуску VFP9 "Europe". А если бы Вы потрудились сходить по указанной ссылке и посмотреть на release date, то обнаружили бы, что не прошло еще и месяца. Кроме того, далеко не всем известно, что теперь использование VFP провайдера не требует лицензии на FoxPro. Его можно использовать без ограничений. В общем, полная халява.
Согласен, что Fox как среда разработки достаточно специфичен, но я предлагал лишь использовать движок БД. Что может быть специфичного в формате dbf, являющимся стандартом de-facto? Какая специфика в использовании ADO? Если потребуется переход на другую базу, потребуется лишь изменение строки подключения.
V>Тот же Access например в последствии можно легко и постепенно переносить на более серъёзный движок, а вот как это выглядит в случае FoxPro я затрудняюсь сказать, поэтому и не согласен..
Что касается Access (точнее — MS Jet), то в данном случае это конечно очень подходящий вариант, но по сравнению с FoxPro он более громоздкий, ресурсоемкий, требует более сложной исталляции. Jet, насколько я знаю, больше не входит в состав MDAC и его нужно ставить отдельно. Что касается перспектив развития и перехода на более мощный движок, то, во-первых, в данном случае это вряд ли потребуется. База используется локально, увеличение числа клиентов не ожидается, и если даже база вырастет в 100 или 1000 раз, то это тоже не проблема. Но даже если upsizing и потребуется, то в FoxPro для этого с давних времен существует Upsizing Wizard для MS SQL и Oracle.
А вот будущее Jet как раз под вопросом. Я слышал, что в будущем планируется отказ от Jet и переход на использование в Access движка MSDE. То есть свою линейку БД M$ видит как FoxPro->MSDE->MS SQL. Jet делит c FoxPro общую нишу и оказывается лишним.
Да что вы так расшумелись то.. сказал же что сугубое ИМХО, не спорю, что указанные цели fox вполне потянет..
Может даже он миниатюрнее Access, не знаю.
Но вот в плане перспективы — fortran он тоже до сих пор с новыми версиями выходит..
И даже очень неплохие и быстрые.. и даже за очень большие бабки..
но в основном это — для поддержки килотонн существующего кода..
Точно также ИМХО как Fox.. для него просто наработок много..
А по поводу отказов от Jet и смены движков, дык всё это сугубо в рамках SQL..
Т.е. не должно вызвать больших изменений.. Fox же (как я слышал ) использует какие то хитрые механизмы блокировки, отказаться от которых впоследствии будет наверно всё таки непросто..
Здравствуйте, Igor Trofimov, Вы писали:
V>>если __обязательно__ хочется open source, то mySQL
iT>Неужели других нет?
Я даю совет в форме "делай так"
а не расплывчатые фразы типа
"если то то так, но вот тут жопа, а если эдак то опять плохо.."
По крайней мере по mySQL я знаю, что советую, с остальными просто не работал,
если у тебя опыт есть, то дай свой совет, в чём проблема то..
Будешь потом человеку объяснять, что да как.. тут вот люди FireBird советуют..
дак наверно знают почему.. Я с ним не работал и советовать не могу
(типа мы в ответе за тех, кого приручили ).
Мы уже победили, просто это еще не так заметно...
)
) использует какие то хитрые механизмы блокировки, отказаться от которых впоследствии будет наверно всё таки непросто..
