Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
MS Access
если __обязательно__ хочется open source, то mySQL
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Visual FoxPro. Все, что требуется для работы — это одна DLL размером 1,2 м VFP OLEDB провайдера, которую можно загрузить здесь. Движок базы встроен в провайдер. Компактней не бывает.
Да что вы так расшумелись то.. сказал же что сугубое ИМХО, не спорю, что указанные цели fox вполне потянет..
Может даже он миниатюрнее Access, не знаю.
Но вот в плане перспективы — fortran он тоже до сих пор с новыми версиями выходит..
И даже очень неплохие и быстрые.. и даже за очень большие бабки..
но в основном это — для поддержки килотонн существующего кода..
Точно также ИМХО как Fox.. для него просто наработок много..
А по поводу отказов от Jet и смены движков, дык всё это сугубо в рамках SQL..
Т.е. не должно вызвать больших изменений.. Fox же (как я слышал ) использует какие то хитрые механизмы блокировки, отказаться от которых впоследствии будет наверно всё таки непросто..
Здравствуйте, h256, Вы писали:
D>>MySQL для этого вполне подойдёт. D>>он бесплантый + Open Source + хорошая производительность и куча документации.
H>Всем спасибо за советы. H>Есть еще одно условие — легкость настройки, т.е. ПО будет с базой и надо чтоб его можно было поставить без особых проблем, в идеале одна кнопочка Install и все, ну или что-то в этом духе.
Тогда я советую Access — Элементарно устанавливается (MS Office — MS Access), можно использовать просто один файл без всяких установок. Легко настраивается. Хорошее описание всех функций и возможностей. Для небольшой базы (до 100 таблиц и до 50000 записей) идеальный вариант.
Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки.
Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
MySQL для этого вполне подойдёт.
он бесплантый + Open Source + хорошая производительность и куча документации.
Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из 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 общую нишу и оказывается лишним.
Здравствуйте, Igor Trofimov, Вы писали:
V>>если __обязательно__ хочется open source, то mySQL
iT>Неужели других нет?
Я даю совет в форме "делай так"
а не расплывчатые фразы типа
"если то то так, но вот тут жопа, а если эдак то опять плохо.."
По крайней мере по mySQL я знаю, что советую, с остальными просто не работал,
если у тебя опыт есть, то дай свой совет, в чём проблема то..
Будешь потом человеку объяснять, что да как.. тут вот люди FireBird советуют..
дак наверно знают почему.. Я с ним не работал и советовать не могу
(типа мы в ответе за тех, кого приручили ).
Здравствуйте, Igor Trofimov, Вы писали:
V>>Я даю совет в форме "делай так"
iT>Ты даешь совет в форме, исключающей другие варианты. ЕСЛИ openSource ТО mySQL.
Совершенно верно, совет я даю __от_своего_имени__
это значит, что если человек меня послушает, то __я__ смогу помочь при случае, а значит отвечать за свои слова..
ни с какой другой open-source системой я просто не работал..
люди советуют FireBird и я им не мешаю.. просто если человек выберет её то и помогуть будут
они, вот и вся разница..
(вот из обычных я работал с Oracle, MSSQL, Access и знаю, что лучше человеку начать с Access)
Здравствуйте, Foror, Вы писали:
F>Здравствуйте, vvaizh, Вы писали:
V>>c другой стороны mySQL и Yaffi доступны как embedded.. т.е. вообще в виде lib-ы
F>А какие именно либы? Мож где подробнее про это можно почитать?
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Я бы на вашем месте посмотрел на Microsoft Desktop Engine (MSDE). Это — почти полный эквивалент MS SQL Server 2000, с той разницей, что покупать его не надо. Для его использования достаточно, например, лицензии на MS Office 2000 Professional. По производительности и функциям он далеко впереди Jet (Access). Кроме того, если в будущем надо будет масштабировать систему, вы безболезнено сможете перейти на SQL Server, т.к. Transact SQL у них одинаковый.
Здравствуйте, h256, Вы писали:
H>Не очень знаком с базами данных. Посоветуйте что подойдет для моей задачки. H>Задача такая — база будет не очень большая(10-15 таблиц), записей тоже не слишком густо, но хотябы так на 1000 надо рассчитывать. В базе будут использоваться blob'ы. Нужно чтоб СУБД было поменьше размером, ну и стоило не слишком много. Может что из Open Source? Все будет распологаться на локальной машине.
Чистая база — MySQL. С клиентом — MS Access (но хорошего в нем — только клиент, для чайников в самый раз).
Можно вместе. Хранить в MySQL, приложение на Access.
Почему MySQL: маленький, быстрый, ставится тривиально (распаковал, пустил...), нативные клиенты под все платформы, чертовски быстрый с InnoDB (с Oracle соревнуется из реляционных, остальные все где-то позади..), переносимость данных на высшем уровне, масштабируемость тоже.
Работал с: Clipper, FoxBase, потом FoxPro, MySQL плотно, Аccess много, MS SQL немного, сейчас ориентируюсь на MySQL с WEB-клиентами (php в основном) и объектную надстройку oodb.
Но вообще для твоей задачи база навряд ли нужна, достаточно нескольких сериализуемых контейнеров с произвольным доступом и поиском.
Re[5]: Помогите выбрать базу данных.
От:
Аноним
Дата:
26.08.03 16:06
Оценка:
Здравствуйте, algol, Вы писали:
A>Вот это ИМХО так ИМХО! Да будет Вам известно, что сейчас новые версии FoxPro выходят ежегодно. Вот в этом году вышел VFP8.0, в сентябре выйдет к нему service pack, готовится Я работал с 6. Когда грохнул почти месяц на отлов ошибок...
На свалку...
Может пофиксили его, незнаю...
Глючныя среда...
При зависании приложения куча глюков.
Постоянно вылеьающие сообщения об несуществующих ошибках вызванные ошибками совсем в другом месте...
Необьяснимое поведение приложение етс.
Я был рад когда отдал эту базу...
Здравствуйте, Аноним, Вы писали:
A>Я работал с 6. Когда грохнул почти месяц на отлов ошибок... А>На свалку... А>Может пофиксили его, незнаю... А>Глючныя среда... А>При зависании приложения куча глюков. А>Постоянно вылеьающие сообщения об несуществующих ошибках вызванные ошибками совсем в другом месте... А>Необьяснимое поведение приложение етс.
Непонятливым повторяю еще раз: "Радиостанция работает на бронетранспортере".
Я не предлагаю писать программу на FoxPro. Действительно, чтобы на нем писать, нужно иметь некоторый опыт. Кроме этого, как я понял, база данных это не главное в обсуждаемой программе.
Я предлагал писать программу на чем угодно (VB, VC++, Дельфи и т.д.) и использовать для работы с БД ADO плюс VFP OLEDB провайдер. Если нужен компактный движок и простота инсталляции, то это ИМХО лучший вариант. Движок БД и OLEDB провайдер в одном флаконе (т.е. DLL) размером 1 метр, абсолютно бесплатный и требующий для инсталляции только скопировать и зарегистрировать DLL — что может быть проще? Поскольку для доступа предлагается использовать ADO, то нет никаких проблем при переходе на использование другой БД при необходимости.
Я вижу только два небольших минуса в предложенном решении — язык SQL в FoxPro довольно ограниченный (например не поддерживаются вложенные запросы); и строковые поля возвращаются дополненные пробелами до длины поля и их приходится постоянно Trim'ить.
Другой реальной альтернативой для данного случая ИМХО является только Access (MS Jet). Ставить сервер БД типа MySQL, MSDE и т.д. + клиента + ODBC драйвер/OLEDB провайдер для обработки 1000 записей на локальной машине мне кажется _абсолютно_ бессмысленным.
) использует какие то хитрые механизмы блокировки, отказаться от которых впоследствии будет наверно всё таки непросто..
Мы уже победили, просто это еще не так заметно...
)
