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

1)Размер базы данных - параметер весьма критичен!
- несколько мегабайт: MS Access, XML, CSV, MS Excel, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL
- до сотни мегабайт: MS Access, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL, Interbase
- гигабайты: MySQL, PostgreSQL, Interbase, Informix, MS SQL Server, Oracle, SyBase, DB/2
- сотни гигабайт и больше: MS SQL Server, Oracle, SyBase, DB/2

2) Количество одновременных пользователей - пожалуй это самый критичный параметер!
- эксклюзивный доступ одного пользователя: MS Excel, XML, CSV, Парадокс, Dbase, Foxpro/VFP, MS Access, MySQL, PostgreSQL
- до десятка пользователей: Парадокс, Dbase, Foxpro/VFP, MS Access, MySQL, PostgreSQL
- несколько десятков пользователей: MySQL, PostgreSQL, Interbase, Informix
- сотни пользователей: PostgreSQL, Interbase, MS SQL Server, Oracle, SyBase, DB/2
- тысячи пользователей: MS SQL Server, Oracle, SyBase, DB/2

3) Цена базы данных - параметер весьма критичен!
- полностью бесплатно: XML, CSV, MySQL, PostgreSQL, Interbase (некоторые клоны)
- формат бесплатен, для разработки желательно купить дешёвую всего одну систему:MS Excel, Парадокс, Dbase, Foxpro/VFP, MS Access
- дешёвые сервера: Interbase (некоторые клоны), Informix, старые версии SyBase
- дорогие сервера: MS SQL Server, Oracle, SyBase
- сверхдорогие сервера: DB/2

4) Платформа - параметер весьма критичен!
- любая: XML, CSV
- Windows only: MS SQL Server, SyBase, Парадокс, Dbase, Foxpro/VFP, MS Access, MS Excel
- Unix/Linux only:PostgreSQL
- Windows+Linux:Oracle, DB/2, Interbase, MySQL, SyBase
- Мейнфреймы: DB/2
- Кластеры:MS SQL Server, Oracle, SyBase, DB/2

5) язык программирования - рекомендательный параметер:
- Языки от Microsoft: MS SQL Server, SyBase, Foxpro/VFP, MS Access, MS Excel
- Языки от Борланда: MS SQL Server, Interbase, Парадокс, MS Access
- Системы под Linux: Oracle, DB/2, Interbase, MySQL, PostgreSQL, XML

6) Тип программы - рекомендательный параметер:
- маленький web сервер: MySQL
- мощный web сервер: MS SQL Server, Oracle, SyBase, DB/2
- локальная утилита: Парадокс, Dbase, Foxpro/VFP, MS Access, MS Excel, XML, CSV
- сложная система:MS SQL Server, Oracle, SyBase, DB/2, Interbase, Informix

7) Защита данных - параметер весьма критичен!
- никакая: MS Excel, XML, CSV
- очень слабая: Парадокс, Dbase, Foxpro/VFP, MS Access
- сильная:MS SQL Server, Oracle, SyBase, DB/2, Interbase, Informix, MySQL, PostgreSQL

8) Мощность языка SQL, возможности базы данных (View, Stored procedures, agents, backup, репликации и т.п.) - параметер весьма критичен!
- очень слабые: MS Excel, XML, CSV
- слабые: Парадокс, Dbase, Foxpro/VFP, MS Access, MySQL
- развитые:Interbase, Informix, PostgreSQL
- мощные:MS SQL Server, Oracle, SyBase, DB/2

9) Требования к железу - параметер весьма критичен!:
- неприхотливые:MySQL, PostgreSQL, Парадокс, Dbase, Foxpro/VFP, MS Access,MS Excel, XML, CSV
- чуствительные: Interbase, Informix, SyBase
- требуют отдельных мощных серверов с большой RAM, желательно на нескольких процессорах: MS SQL Server, Oracle, DB/2

10) Способ доступа - рекомендательны параметер:
- ODBC: CSV
- OLE DB/ADO: MS Excel,MS Access,MS SQL Server, SyBase
- DAO:MS Excel,MS Access,Foxpro/VFP
- BDE:Парадокс, Dbase,Foxpro/VFP
- DBExpress:MySQL, Interbase, Oracle, DB/2
- Собственные:XML,MySQL,Interbase, Informix, PostgreSQL, Oracle, SyBase, DB/2

11) Сложность настройки, установки, администрирования, желательность специально обученного персонала для администрирования - параметер весьма критичен!:
- никаких сложностей, администрирование не требуется: MS Excel, XML, CSV
- минимальные либо небольшие сложности: Парадокс, Dbase, Foxpro/VFP, MS Access
- первоначальная настройка плюс минимальная поддержка: PostgreSQL, MySQL
- требуются специальные знания в достаточно большом объёме: Interbase, Informix
- желательно наличие специалиста по базам данных: MS SQL Server, Oracle, SyBase, DB/2

12) Стоимость программистов и администраторов - параметер весьма критичен!:
- небольшая: MS Excel, XML, CSV, Парадокс, Dbase, Foxpro/VFP, MS Access, PostgreSQL, MySQL
- значительная: Interbase, Informix, SyBase
- высокая и очень высокая: MS SQL Server, Oracle, DB/2

13) Перспективы развития базы данных, стабильность фирм-хозяев, выпуск новых релизов и т.п-рекомендательный параметер.
- "мёртвые" или почти мёртвые базы: Парадокс, Dbase, Foxpro/VFP, CSV
- медленно развивающиеся, сомнительные перспективы, фирмы производители не устойчиво стоящие на ногах: Interbase, Informix, PostgreSQL, SyBase
- Гарантированно продолжение, только развивать дальше некуда: MS Excel, MS Access, DB/2
- Бурно развивающиеся базы, частые релизы и апдейты: MS SQL Server, Oracle, XML, MySQL

14) Трудоёмкость и возможность перевода программы от одной базы к другой - рекомендательный параметер:

Лёгкие переходы:
Парадокс<->Dbase<->Foxpro/VFP
CSV->MS Excel
SyBase -> MS SQL Server
MS Excel->MS Access

В остальных случаях обычно можно перевести более лёгкие базы в более навороченные, но не наоборот. Особняком стоит XML который обычно вообще трудно куда дибо перевести.

Замечание насчет XML, этот формат достаточно широко поддерживается производителями СУБД и особых проблем с конвертацией быть не должно. Так в FoxPro есть готовые процедуры которые позволяют из таблицы получить XML и наоборот. Так же в Oracle есть очень развитые средства по работе с XML, в частности к XML документам можно даже выполнять SQL-подобные запросы.

Маленькое замечание, от себя лично: совсем не давно столкнулся с фоксовской базой на 5 гигов! как оно работает сам не пойму, но факт остаеться фактом. И во вторый на фоксе делают программы и для доступа неск. десятков пользователей, хотя это и не характерно для него. это все-таки локальная база данных, хотя в последние время Майкрософт делает шаги в улучшение сетевых технологий фокса!

Цитата(LSD @ 3.10.2004, 01:52)

Замечание насчет XML, этот формат достаточно широко поддерживается производителями СУБД и особых проблем с конвертацией быть не должно. Так в FoxPro есть готовые процедуры которые позволяют из таблицы получить XML и наоборот. Так же в Oracle есть очень развитые средства по работе с XML, в частности к XML документам можно даже выполнять SQL-подобные запросы.

Имеется ввиду не это, если я сделал систему которая основана на формате XML то переделать её на тот же Oracle может оказаться весьма сложным делом, и дело не в поддержке формата, а в том, что XML совсем не реляционная база данных, и структуры описанные в XML могут оказаться весьма сложно реализуемыми или их реализация будет весьма трудоёмка... Например в Oracle можно в простейшем случае заменить на MS SQL без существенных переработок кода, простые запросы типа "Select * From Table" - будут работать одинаково, т.е. прийдётся только сменить драйвер, для XML даже в таком простейшем случае вовсе не факт что всё можно будет поменять так легко. За исключением редких случаев переход с или на XML всегда ведёт к существенной переработке кода. А в целом, для того чтобы перевести с одного формата на другой - практически всегда требуется существенная переработка, даже переход с 7го SQL Server на 2000 привела у меня к почти полному переписыванию продукта, и дело было не в форматах, а в разнице производительности разных запросов.

Цитата(Cashey @ 3.10.2004, 02:19)

Маленькое замечание, от себя лично: совсем не давно столкнулся с фоксовской базой на 5 гигов! как оно работает сам не пойму, но факт остаеться фактом. И во вторый на фоксе делают программы и для доступа неск. десятков пользователей, хотя это и не характерно для него. это все-таки локальная база данных, хотя в последние время Майкрософт делает шаги в улучшение сетевых технологий фокса!

Естественно такое возможно. Другое дело уверен на 100% что применение самого дохлого сервера баз данных даст существенное увеличение производительности. Я не задавался целью давать пределы возможностей баз данных - они написаны в документации, для того же Access можно создать тоже гигабайтную базу данных и подключить однговременно 1000 пользователей, только результатов работы не дождуться и наши внуки... А можно создать базу данных из одной таблицы на 10 записей и 2 поля в Oracle и работать с ней в однопользовательском режиме, наплевать что потребуется мощный сервак и несколько тыс. зелёных на покупку железа и софта, а работать это будет раз в 20 медленнее чем парадокс... Эти рекомендации направлены именно на оптимальный выбор базы данных, а не вообще о возможности выбора.

И я добавлю:
1)Размер базы данных - параметер весьма критичен!
У InterBase размер пустой БД 251 Kb, т.е. можно отнести к "- несколько мегабайт:"
Потом, что такое размер БД?
Десять записей с blob'ами MP3 попадают в раздел "до сотни Мб"?
Надо учитывать кол-во записей, хотя бы.

2) Количество одновременных пользователей - пожалуй это самый критичный параметер!
Тоже не совсем правильно, надо определять что делают пользователи? Если большинство пользователей занимаются вставкой/изменением/удалением информации это одна нагрузка, а если простые/сложные select'ы то другая, а вот если сложный анализ данных, то тут я думаю на 10 пользователях могут загнуться некоторые из категории <100.

4) Платформа - параметер весьма критичен!
Почти все правильно, только не понятно почему Парадокс, Dbase(мы же рассматриваем форматы файла) только для Windows? Ведь например DBF это практически текстовый файл(сильно сказано, но если знать структуру), а написать что-то для работы с простым файлом можно на любой платформе. Но если вопрос про систему управления БД, то называть DBase, да и MySQL, СУБД по большому счету трудно.

5) язык программирования - рекомендательный параметер:
А это как?
Т.е. если мне надо писать под Oracle, то мне не рекомендуется использовать Delphi? Или имелось ввиду написание программ только как tools для БД, который будет работать исключительно на сервере?
И почему XML только в "- Системы под Linux:", т.е. для обработки не подходит ни один компилятор ни от Borland ни от M$?

9) Требования к железу - параметер весьма критичен!:
InterBase стоит перенести в "- неприхотливые:"

10) Способ доступа - рекомендательны параметер:
"- DBExpress:" вроде умер не родившись, если бы Borland ввел DBE в версии так 4 Delphi, то я думаю сейчас бы это была хорошая альтернатива, но ... IMHO, многие выбирают компоненты с прямым доступом из раздела "- Собственные:"

11) Сложность настройки, установки, администрирования, желательность специально обученного персонала для администрирования - параметер весьма критичен!:
Interbase нужно перенести в "- первоначальная настройка плюс минимальная поддержка:" или даже "- минимальные либо небольшие сложности:"

13) Перспективы развития базы данных, стабильность фирм-хозяев, выпуск новых релизов и т.п-рекомендательный параметер.
Вообще не понятно, зачем это. Т.е. у M$ самая развивающаяся БД? только потому что очень часто выходят заплатки? И опять же где у нас MySQL и XML? В бурных? Это от чего же? А почему тогда InterBase не там? И как вообще можно оценить варианты развития фирмы? Пока у многих стоит M$ в качестве сервера, то и M$ SQL Server'у есть дорога, но уже сообщество *nix'ов объединяется http://www.cnews.ru/newtop/index.shtml?2004/09/14/163434 то в скором времени ситуация может и поменяться коренным образом, и как следствие вперед смогут выйти многоплатформенные СУБД(вон Oracle даже под нетварь есть :-\ )

По переводу программы, это вообще отдельная песня.
Если мы говорим о сурьЁзном проекте предприятия, который стоит много американских рублей, то врядли кто-то разрешит изменить СУБД и заплатить еще кучу за сервер и за каждое соединение. У нас очень большая система(не хочу делать рекламу) на Oracle. Она поддерживает изменение СУБД(из-за этого есть ограничения в написании SQL-запросов), но на практике никто еще не видел, что бы предприятие после внедрения сменило СУБД.

PS: Может показаться что я сильно трепетно отношусь к InterBase'у, так оно и есть, но только уже давно FireBird(такназываемый бесплатный клон).
И еще вопрос к автору: Для чего и для кого все это было опубликовано?

Guest'у Наверное будет проще, если я начну с конца и отвечу на вопрос:

Для чего и для кого все это было опубликовано?

Точно не для Вас! Почему? Да просто потому что это очень краткий обзор, не претендующий ни на полноту изложения, ни на глубину. Он нужен новичку который только вчера услышал "базы данных", а сегодня у него стоит задача выбрать свою первую базу данных для своего проекта. Я на форуме, и не только на этом, не первый год - вопросы по выбору базы данных задаются с завидной регулярностью, если мне или Вам нужно будет выбрать между Ораклом или Интербейзом мы полезем не в FAQ а в документацию, будем основываться на собственном опыте, исходя из многочисленных граблей, на которые наступали, будем искать оптимальное решение... Но если для человека слово DB/2 и Paradox звучат совершенно одинаково непонятно, а любая документация по тому же самому MS SQL Server представляется полной абракадаброй - то надо ему немного помочь, просто показать направление в котором копать, от чего отталкиваться... и ничего более. Тем более не надо заводить бодягу с доказательством что Interbase самая лучшая база данных - это именно то чего я пытался избежать, и не надо меня толкать на очередной спор что круче или лучше.

Теперь попорядку:

Цитата(Guest @ 15.10.2004, 05:07)

1)Размер базы данных - параметер весьма критичен! У InterBase размер пустой БД 251 Kb, т.е. можно отнести к "- несколько мегабайт:" Потом, что такое размер БД? Десять записей с blob'ами MP3 попадают в раздел "до сотни Мб"? Надо учитывать кол-во записей, хотя бы.

Имеется ввиду СРЕДНИЕ объёмы данных которыми оперирует УСРЕДНЁННАЯ база данных. Не предирайтесь к словам, и не надо мне говорить что да мы можем засунуть в базу данных 10 гигабайтныйх файлов или миллиард записей по байту в каждой.... Это крайние случаи, Речь идёт о самой обычной базе данных - складе или телефонном справочнике... и пункт приведен только для того чтобы показать ПОРЯДОК, а не дать точную характеристику. И уж конечно я говорил здесь не о размере пустой базы данных - это вообще на фиг никому не нужный показатель...

Цитата(Guest @ 15.10.2004, 05:07)

) Количество одновременных пользователей - пожалуй это самый критичный параметер! Тоже не совсем правильно, надо определять что делают пользователи? Если большинство пользователей занимаются вставкой/изменением/удалением информации это одна нагрузка, а если простые/сложные select'ы то другая, а вот если сложный анализ данных, то тут я думаю на 10 пользователях могут загнуться некоторые из категории <100.

Вы наверное килобайтный FAQ с диссертацией спутали? Я вам и одним запросом любую базу данных могу довести до полной остановки, понятно что разные запросы дают разную нагрузку, здесь Вы америку не открыли, спорить не буду... Только я хочу дать ПОРЯДОК, а вовсе не 100% правильную рекомендацию для конкретного случая жизни.

Цитата(Guest @ 15.10.2004, 05:07)

4) Платформа - параметер весьма критичен! Почти все правильно, только не понятно почему Парадокс, Dbase(мы же рассматриваем форматы файла) только для Windows? Ведь например DBF это практически текстовый файл(сильно сказано, но если знать структуру), а написать что-то для работы с простым файлом можно на любой платформе.

DBF - это конечно не текстовый файл, но написать можно. И тем ни менее сами СУБД использующие DBF работают в среде Windows. Я лично не знаю ни одного (!) аналога Dbase или Paradox в среде Linux... А если самому городить поддержку DBF под Linux - то на фиг это надо? Проще свой собственный формат взять или использовать что-нибудь готовое для Linux...

Цитата(Guest @ 15.10.2004, 05:07)

Но если вопрос про систему управления БД, то называть DBase, да и MySQL, СУБД по большому счету трудно.

Неймётся поспорить? Если по существу не о чём, так хотя бы прицепится к терминологии? Я не буду заводить пустопорожний спор о значении термина СУБД - всем достойным последователям Фомы Аквинского в спорах по поводу сколько ангелов уместится на конце иглы - у нас во флейме специально открыт раздел для этого... вот там можно и поспорить!

Цитата(Guest @ 15.10.2004, 05:07)

5) язык программирования - рекомендательный параметер: А это как? Т.е. если мне надо писать под Oracle, то мне не рекомендуется использовать Delphi? Или имелось ввиду написание программ только как tools для БД, который будет работать исключительно на сервере? И почему XML только в "- Системы под Linux:", т.е. для обработки не подходит ни один компилятор ни от Borland ни от M$?

Естественно что базы данных на то и базы данных, что могут работать с любыми платформами и любыми языками... Да и параметер я этот обозначил как "рекомендательный", т.е. не существенный. Здесь я пытался сказать всего лишь что обычно (но не всегда) фирмы выпускающие базы данных и языки облегчают пользователю работу с ними... В Дельфи очень легко работать с Парадоксом - там всё под него подогнано. Да я ЗНАЮ что на Дельфи можно работать с ЛЮБОЙ базаой данных, да я ЗНАЮ что что с парадоксом можно работать тоже из любого языка, но тем ни менее именно в связке Парадокс-Дельфи всё делается ОЧЕНЬ просто, гораздо проще чем в связке "Дельфи+любая другая база данных" и в связке "Парадокс+Любой другой язык"...

XML - разговор вообще отдельный... Не стоит здесь это заводить, это не для маленлкой странички обсуждение...

Цитата(Guest @ 15.10.2004, 05:07)

11) Сложность настройки, установки, администрирования, желательность специально обученного персонала для администрирования - параметер весьма критичен!: Interbase нужно перенести в "- первоначальная настройка плюс минимальная поддержка:" или даже "- минимальные либо небольшие сложности:"

У меня очень маленький опыт работы с Interbase, и он мне говорит что база данных такого уровня обычно требует более или менее сложной оптимизации, речь идёт уже о стыке с промышленными базами данных и встают вопросы о бэкапах, синхронизации данных на разных серверах, административных сообщениях о неполадках, настройках пользовательских прав, профилизация запросов с их оптимизацией и т.д. и т.п.... Возможно я не прав, но Ваше мнение я принять во внимание не могу - оно предвзятое, я пытаюсь от такого мнения дистанцироваться, причём мне всё равно будете ли Вы нахваливать Interbase или Clarion - как только я вижу подобный образ мышления - я становлюсь глух к такому мнению в вопросах исправлений этого документа. Хотелось бы слышать более взвешенное мнение, желательно в сравнении с другими системами.

Цитата(Guest @ 15.10.2004, 05:07)

10) Способ доступа - рекомендательны параметер: "- DBExpress:" вроде умер не родившись, если бы Borland ввел DBE в версии так 4 Delphi, то я думаю сейчас бы это была хорошая альтернатива, но ... IMHO, многие выбирают компоненты с прямым доступом из раздела "- Собственные:"

Так в чём проблема? Ваш любимый Interbase есть и там и там? Я в чём то здесь не прав?

Цитата(Guest @ 15.10.2004, 05:07)

13) Перспективы развития базы данных, стабильность фирм-хозяев, выпуск новых релизов и т.п-рекомендательный параметер. Вообще не понятно, зачем это. Т.е. у M$ самая развивающаяся БД? только потому что очень часто выходят заплатки? И опять же где у нас MySQL и XML? В бурных? Это от чего же? А почему тогда InterBase не там? И как вообще можно оценить варианты развития фирмы? Пока у многих стоит M$ в качестве сервера, то и M$ SQL Server'у есть дорога, но уже сообщество *nix'ов объединяется http://www.cnews.ru/newtop/index.shtml?2004/09/14/163434 то в скором времени ситуация может и поменяться коренным образом, и как следствие вперед смогут выйти многоплатформенные СУБД(вон Oracle даже под нетварь есть :-\ )

Всё здесь понятно. MS SQL Server - поддерживается MS - самой стабильной, мощной и перспективной софтоверной корпорацией в мире. Это не значит что надо любить MS - но я знаю точно, что MS SQL Server будет развиваться, и с MS ничего не случится в ближайшие годы...

MySQL - сейчас чуть ли не стандарт de facto для мелких интернет проектов, на нём чуть ли не половина интернета стоит, а если не брать промышленных гигантов и порталов, так почитай 90% интернета... А это значит что эта база данных в ближайшие годы не станет устаревшей, или заброшенной...

XML - тут даже спорить не буду... очень продвигаемый формат чуть ли не всеми софтоверными гигантами в мире совместно...

InterBase - а чего ей быть в стабильных? Борланд, как бы мы к ней не относились стоит на ногах хило, то она чуть ли не продаётся, саму InterBase то объявляет вообще более не развиваемой и выкладывает исходники, то решает её всё же делать... Извините, но у меня вовсе нет уверенности что Борланд будет жить через год или пять, если завтра перестанет продаваться JBuilder - единственный их продукт приносящий достаточно денег и накроется Борланд медным тазиком, или не накроется но решит что тянуть InterBase ей больше не под силу... Диких клонов опять-таки не счесть и есть и вполне удачные... Но опять-таки трудно уповать на неизвестно кого в развитии, тем более что если нет конкретного производителя, то нет и технической поддержки - а ведь InterBase не MySQL - это гораздо более серьёзная база данных, и если корпорация ставит такую базу то хочет иметь тех. поддержку...

Цитата(Guest @ 15.10.2004, 05:07)

Если мы говорим о сурьЁзном проекте предприятия, который стоит много американских рублей, то врядли кто-то разрешит изменить СУБД и заплатить еще кучу за сервер и за каждое соединение. У нас очень большая система(не хочу делать рекламу) на Oracle. Она поддерживает изменение СУБД(из-за этого есть ограничения в написании SQL-запросов), но на практике никто еще не видел, что бы предприятие после внедрения сменило СУБД.

Увы, вашему покорному слуге приходилось это делать и не раз! Простейший пример, купила корпорация другую корпорацию с потрохами, а теперь прикручивает их базы данных к своей системе... и понеслась родимая... аж уши закладывает на поворотах... А ещё какой-нибудь дегенерат топ-менеджер, для которого слова "база данных" и "драйвер диска" звучат одинаково читает в журнале, что оказывается вот это круто! а то что есть оно не очень... и даёт указивку переделать...тоже такое было... расхлёбываем не первый год....

И ещё на последок обращение к гостю: критиковать мы все горазды, особенно если придираться... А ну как самому составить что-то полезное? Тут наверное год висел линк по проекту- составить хороший FAQ по выбору баз данных - здесь http://forum.vingrad.ru/index.php?showforum=53 и что кто-то помог мне (за исключением пары человек)? Вы лично как специалист по Interbase помогли сделать её описание?

Цитата

Маленькое замечание, от себя лично: совсем не давно столкнулся с фоксовской базой на 5 гигов! как оно работает сам не пойму, но факт остаеться фактом

На счет foxpro(DOS) не в гигах счатье, а в количестве записей в одной таблице. У меня в офисе один *.DBF содержит около 1млн. записей.
Здесь проблемы начинаются с 2млн. записей (не поддерживаются).

И на последок, УВАЖАЕМЫЕ коллеги, хотел бы спросить на счет СУБД "Cache"(из теории: поддерживает могие платформы, работает быстрее ORACLE в 100 раз???, очень хорошо дружит с JAVA, ну и конечно имеет ODBC)

Сори в прошлый раз не подписался(только сейчас зарегистрировался на форуме).
на форум попал по какой-то ссылке на статью!
>Vit
>Точно не для Вас!
Это получается что я зря прочитал. Вот так приходит новый человек на форум и ...
Ладно я не обижаюсь.
Все что написано далее не для спора и не для флуда, а если не нравятся мои замечания, то это Ваше право. Только вот автор, который "глух" на обсуждение не способен слышать ничего, кроме себя и своих авторитетов.
Продолжим.
Про размер БД, может и погорячился, просто не люблю когда говорят: "У меня база 100Мб", обычно более понятно когда называют ~ко-во таблиц и записей в них. Это как-то более понятно. И для того же новичка будет более разумно в начале прикинуть кол-во хранимой информации. Просто легче посчитать ~кол-во записей в рабочих таблицах, чем "размер БД"
Про кол-во клиентов тоже вопрос серьёзный.

Цитата

Только я хочу дать ПОРЯДОК

порядок это в два раза? :-)
все зависит даже не от БД, а от того как написана программа работы с БД. Если все клиенты будут делать select * from table то и сетевой трафик и нагрузка на сервер сильно подрастет. Опять же работа зависит от объма информации, т.е. как от "размера БД". И от этого никуда не деться.
Языки программирования:

Цитата

В Дельфи очень легко работать с Парадоксом - там всё под него подогнано.

И что же позвольте поитерисоваться там подогнано? BDE? Так как раз через BDE практически без модификации приложения можно работать с DBF, Oracle, InterBase, и т.д. BDE как раз создавалось для универсальности, как ответ ODBC.
Не хочу говорить про другие языки программирования, но для Delphi эсть такая туча всяких компонент, практически под все вышеперечисленные БД(причем для каждой несколько), и легкость разработки зависит от качества этих самых компонентов.

Цитата

Так в чём проблема? Ваш любимый Interbase есть и там и там? Я в чём то здесь не прав?

Вы меня не поняли, я ни слова не сказал про InterBase, я пытался сказать, что DBExpress стоит выключить из обзора(тем более что статья расчитана для новичков), хотя до сих пор появляются все новые и новые драйвера к нему для доступа к разным СУБД.
Сложность настройки, ...

Цитата

Ваше мнение я принять во внимание не могу

и

Цитата

Вы лично как специалист по Interbase помогли сделать её описание?

как связать эти два выражения. И как же Вам помочь в таком случае?

Цитата

MySQL - сейчас чуть ли не стандарт de facto для мелких интернет проектов

Несомненно это так. MySQL берет скоростью обработки, и эта скорость действительно большая. Но в MySQL (на которой стоят по Вашим словам 90%) не поддерживает внешние ключи, транзакции, хранимые процедуры, триггеры и т.д. В новых версиях все это будут добавлять, в 4 уже добавили кое-что и MySQL4 уже есть, но вот скорость у нее от этого упала, а когда введут транзакции скорость еще упадет, следовательно стаднартом de facto может остаться та, старая MySQL без всех наворотов, а может вылезти что-то другое тоже бесплатное. И о каком развитии тогда мы говорим? Под развитием я понимаю новые возможности, улучшение существующих функций, если этого не нет то и развития НЕТ! Тоже самое к XML, это просто формат файла и все, а то что все СУБД пытаются поддерживать его, так это не развитие а популярность и не надо путать эти понятия. Для сравнения популярности Орпос: Какую СУБД вы используете в своей работе?
И в заключении:

Цитата

купила корпорация другую корпорацию с потрохами, а теперь прикручивает их базы данных к своей системе

Без вопросов, такое есть, но вот только они(купившая) пытаются их(продавшихся) информацию в свою систему определить, не знаю как там с перепиской всех приложений.
А вот про топ-менеджер я улыбнулся, бывают такие идиоты, но по большому счету они не смогут дать указивку при условии больших материальных затрат, генерал не пропустит, только если деньгу на этом поимеет, но такие случаи я рассматривать не хочу!
Удачи Вам в работе, надеюсь никого не обидел.
Добавлено @ 14:31
>fevdokimov
Сколько я слышал разговоров про Cache, практически все только о теории, реального подтверждения в инете не видел.
У нас на предприятии есть одна программка(кадры) написана как раз с использованием Cache, но кривовато, поэтому ничего говорить не хочу.

Цитата(Deniz @ 16.10.2004, 05:27)

И как же Вам помочь в таком случае?

Вы можете очень помочь, если как специалист по Interbase, а я вижу по постам, что вы на самом деле разбираетесь в вопросе сделаете краткое описание Interbase в разделе http://forum.vingrad.ru/index.php?showforum=53, следуя плану и структуре изложения указанными в прикреплённых топиках - это поможет всем участникам форума и мы будем очень благодарны за такую работу

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

Цитата(fevdokimov @ 16.10.2004, 05:06)

И на последок, УВАЖАЕМЫЕ коллеги, хотел бы спросить на счет СУБД "Cache"(из теории: поддерживает могие платформы, работает быстрее ORACLE в 100 раз???,

Знаешь, если взять описание ЛЮБОГО сервера баз данных, то производитель говорит о том что именно его сервер работает быстрее, приводит примеры в которых он работает быстрее, и главное - что он прав! Тот же Парадокс на таблицах в сотню записей при локальном многопользовательском доступе обгоняет MS SQL Server на 3-4 порядка по быстродействию! Для каждой базы данных есть операции и ситуации где она может обгонять другие на порядки. Тот же MySQL как заметил Deniz за счёт отсутствия реализации очень многих возможностей вполне может обгонять гораздо более серьёзные сервера... Относитесь к рекламной информации критично. Я не работал с Cache, но по отзывам это довольно серьёзнеый продукт, и наверняка есть задачи в которых он будет одной из самых предпочтительных баз данных.

Т.е. нужно сделать описание по пунктам в сообщении http://forum.vingrad.ru/index.php?act=ST&f=53&t=14013 (Дата 29.10.2003, 18:26 )?
Это можно, не так сразу, но можно (если это кого-то еще интерисует).
Можно связаться по асе и обсудить некоторые орг. вопросы.

Цитата(Deniz @ 16.10.2004, 22:22)

Это можно, не так сразу, но можно (если это кого-то еще интерисует).

Да

Цитата(Deniz @ 16.10.2004, 22:22)

Можно связаться по асе и обсудить некоторые орг. вопросы.

Да

Цитата(Deniz @ 16.10.2004, 22:22)

Т.е. нужно сделать описание по пунктам в сообщении http://forum.vingrad.ru/index.php?act=ST&f=53&t=14013 (Дата 29.10.2003, 18:26 )?

Да

Можно и я вставлю словечко?

Цитата(Vit @ 3.10.2004, 05:57)

10) Способ доступа - рекомендательны параметер: - ODBC: CSV - OLE DB/ADO: MS Excel,MS Access,MS SQL Server, SyBase - DAO:MS Excel,MS Access,Foxpro/VFP - BDE:Парадокс, Dbase,Foxpro/VFP - DBExpress:MySQL, Interbase, Oracle, DB/2 - Собственные:XML,MySQL,Interbase, Informix, PostgreSQL, Oracle, SyBase, DB/2

Вит, DBExpress с MySQL плохенько работает. У меня не получилось выборки более 10 полей. ADO-ODBC работает прекрасно.

Цитата(Vit @ 16.10.2004, 08:32)

InterBase - а чего ей быть в стабильных? Борланд, как бы мы к ней не относились стоит на ногах хило, то она чуть ли не продаётся, саму InterBase то объявляет вообще более не развиваемой и выкладывает исходники, то решает её всё же делать... Извините, но у меня вовсе нет уверенности что Борланд будет жить через год или пять, если завтра перестанет продаваться JBuilder - единственный их продукт приносящий достаточно денег и накроется Борланд медным тазиком, или не накроется но решит что тянуть InterBase ей больше не под силу... Диких клонов опять-таки не счесть и есть и вполне удачные... Но опять-таки трудно уповать на неизвестно кого в развитии, тем более что если нет конкретного производителя, то нет и технической поддержки - а ведь InterBase не MySQL - это гораздо более серьёзная база данных, и если корпорация ставит такую базу то хочет иметь тех. поддержку...

Все потихоньку уходят с Interbase на Firebird, который быстро развивается: уже сделал гораздо более развитый язык, в последних версиях снято множество ограничений, которые имелись в Interbase и мешали комфортной работе. Да и со службой поддержки у них все нормально. Так, что я не знаю как Interbase, но его клоны будут жить и развиваться.

Имеет ли значение при выдоре базы клиентская часть?
У нас была база на Аксессе. Мы перенесли таблицы на MS SQL Server.
Конечно все осталось на ODBC соединении таблиц.
Насколько удачно или неудачно такое решение.
Вы пишите, что ODBC медленно работает с MS SQL Server, но веть таблицы по умолчанию коннектятся через ODBC. И рекордсеты все осталиь DAO.
Имеет ли смысл осталять клиентскую часть в Аксессе или лучше переделать на Visual Basic или куда лучше? А если с нуля, то стоит ли начинать в Аксессе ( при базе MS SQL Server. ) или это совсем плохое решение ( там отчеты хорошие , этим Аксеес привлекателен ).

Цитата

Имеет ли смысл осталять клиентскую часть в Аксессе или лучше переделать на Visual Basic или куда лучше? А если с нуля, то стоит ли начинать в Аксессе ( при базе MS SQL Server. ) или это совсем плохое решение ( там отчеты хорошие , этим Аксеес привлекателен ).

На сколько я понимаю основное отличие файл-серверных БД от клиент-серверных заключается в том, что последние производят все вычесления на сервере и передают клиенту выборку. А локальные БД тянут всю таблицу. Поэтому имеет малое значение что является клиентской частью, она все-равно работает с минимальной выборкой и говорить о радикальном приросте производительности от смены одной на другую не приходится.

Цитата(Cashey @ 8.12.2004, 15:39)

На сколько я понимаю основное отличие файл-серверных БД от клиент-серверных заключается в том, что последние производят все вычесления на сервере и передают клиенту выборку. А локальные БД тянут всю таблицу. Поэтому имеет малое значение что является клиентской частью, она все-равно работает с минимальной выборкой и говорить о радикальном приросте производительности от смены одной на другую не приходится.

Не совсем так. Всё сложнее. Для эффективной работы клиент сервера от клиента нужно:

1) Правильные блокировки
2) Кэширование данных на клиентской части
3) Передача данных кусками а не целиком по запросу

Если клиентская система этого не поддерживает то производительность будет очень низкая, ODBC как раз с этим справляется не очень...

Цитата(Vit @ 9.12.2004, 15:16)

1) Правильные блокировки 2) Кэширование данных на клиентской части 3) Передача данных кусками а не целиком по запросу

Ну Vit, первый пункт решается программистом, по крайне мере в фоксе все блокировки прописываются программно, да и в других локальных БД то же.
Со вторым пунктом справляются все боле менее популярные драйвера (в том числе и ODBC). А передача данных кусками, это как раз особенность клиент-серверных БД.

Цитата(Cashey @ 9.12.2004, 23:42)

Ну Vit, первый пункт решается программистом, по крайне мере в фоксе все блокировки прописываются программно, да и в других локальных БД то же.

Это интересно как же. У тебя есть база данных, которая лежит на серваке твоя прога к ней подключается и начинает редактировать какой то набор данных, в этот момент запускается еще одна версия твоей программы и тоже хочет отредактировать те данные, которые редактирует 1 программа. И как в этом случае узнать, что данные уже кем-то редактируются?

Цитата(Alex @ 9.12.2004, 23:54)

Это интересно как же. У тебя есть база данных, которая лежит на серваке твоя прога к ней подключается и начинает редактировать какой то набор данных, в этот момент запускается еще одна версия твоей программы и тоже хочет отредактировать те данные, которые редактирует 1 программа. И как в этом случае узнать, что данные уже кем-то редактируются?

RLock и второй проге будет показана фига

Цитата(Cashey @ 9.12.2004, 15:03)

RLock  и второй проге будет показана фига

Вот в том то и дело... Что фига...

Цитата(Vit @ 10.12.2004, 00:12)

Вот в том то и дело... Что фига...

ну а что должно будет произойти?

Цитата(Cashey @ 9.12.2004, 14:42)

Ну Vit, первый пункт решается программистом, по крайне мере в фоксе все блокировки прописываются программно, да и в других локальных БД то же.

Нет. Блокировки фокса тут не причём, мы же говорим о клиент-сервере, следовательно говорим о серверных а не локальных базах данных.

Цитата(Cashey @ 9.12.2004, 14:42)

Со вторым пунктом справляются все боле менее популярные драйвера (в том числе и ODBC).

Очень-очень плохо справляются, драйвера не рассчитанные на клиент-серверные технологии типа DAO/ODBC/BDE неправильно распределяют загрузку сети, неправильно делают кэширование, что очень сильно тормозит.

Цитата(Cashey @ 9.12.2004, 14:42)

А передача данных кусками, это как раз особенность клиент-серверных БД.

Нет, база данных ничего никуда не передаёт. Передача данных от клиента к серверу - это прерогатива драйвера. А чтобы не быть голословным, проведи эксперимент:
1) Создай таблицу в MS SQL Server средних размеров, на десяток полей и десяток миллионов рекордов
2) напиши клиента который в цикле будет выполнять на таблице Select, Update и Insert запросы постоянно со случайными параметрами, причём напиши клиента в 2х ипостасях - один с коннектом через ODBC, другой через ADO.
3) Запусти по 10 экземпляров клиента с 10 разных компьютеров и посмотри как будет работать клиент через ADO и клиент через ODBC.

Я пробовал, на одних и тех же запросах и данных - на ADO клиент работать нормально, и сервак справляется. На ODBC - сервак умирает - загрузка процессора 100%, запросы длятся десятками минут, сеть лежит...

Цитата(Vit @ 10.12.2004, 00:23)

Нет. Блокировки фокса тут не причём, мы же говорим о клиент-сервере, следовательно говорим о серверных а не локальных базах данных.

Ну так серверный БД и так блокируют нормально, это их прямая обязанность.

С остальным я соглашусь, но вопрос звучал об использовании клиента, а не драйвера. А точнее, переходить ли с базы access на какую-то другую. С большинством баз можно коннектится как средствами ADO так и ODBC, а об их отличиях уже говорилось и не раз. И я говорил о том, что большой разницы в клиенте не будет.

Цитата(Cashey @ 9.12.2004, 15:33)

Цитата (Vit @ 10.12.2004, 00:23) Нет. Блокировки фокса тут не причём, мы же говорим о клиент-сервере, следовательно говорим о серверных а не локальных базах данных. Ну так серверный БД и так блокируют нормально, это их прямая обязанность.

В том то и дело, сервера имеют очень много различных видов блокировок. Например есть у меня таблица погоды в разных городах:

Город ---- Темепратура Воздуха --- Влажность --- Давление

Есть три клиента работающие одновременно:

1) Клиент А - обновляет таблицу данными по Магаданской области.
2) Клиент Б - обновляет таблицу данными по Московской области.
3) Клиент С - запрашивает таблицу о погоде в Москве

Они запустили запросы примерно одновременно. Кто кого должен блокировать? Да никто никого не должен! Они вообще не должны друг другу мешать... А не клиентсерверные системы этого обеспечить не могут, один из Update блокирует таблицу по записи, а если совсем не повезёт то и по чтению, второй Update при этом должен ждать результатов первого. Селект тоже может быть затребован очень хреново: допустим селект должен вернуть данные по всему Европейскому региону, начинает перекачивать на клиент данные, на пол пути клиент Б делает обновление, и клиент начинает тянуть данные опять с начала... и т.д. Когда таких одновременных запросов накапливается несколько десятков - сеть, сервак и клиенты сдыхают... Клиент-серверные технологии, например ADO дают очень хороший контроль над возможностью установить именно тот уровень блокировки который нужен, а другие - дают эту возможность лишь в очень урезанном виде....

Цитата(Vit @ 10.12.2004, 02:26)

А не клиентсерверные системы этого обеспечить не могут, один из Update блокирует таблицу по записи, а если совсем не повезёт то и по чтению, второй Update при этом должен ждать результатов первого.

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

Цитата(Cashey @ 10.12.2004, 10:10)

в клиент-серверных, по идеи, это должно работать автоматически.

Это не может работать автоматически, точнее это работает автоматически но пользователь обязан указать какую блокировку использовать. Например в приведенном выше примере блокировки не нужны, а если бы допустим у меня были финансовые транзакции, то нужна была бы блокировка чтобы пресечь 2 одновременные транзакции с одими и теми же деньгами... В каждом конкретном случае нужен свой тип блокировок, и этим можно управлять. Системы локальных баз не умеют по нормальному обеспечить установку блокировок и по умолчанию используют самые безопастные, а потому самые "сильные" блокировки, которые в 90% случаев излишни и сильно тормозят работу.

так я и говорю, в локальных это надо прописывать программисту в ручную.

Цитата(Cashey @ 11.12.2004, 05:45)

так я и говорю, в локальных это надо прописывать программисту в ручную.

Я не спорю, я утверждаю вещь лежащую АБСОЛЮТНО в другой плоскости. Я вообще не трогаю ЛОКАЛЬНЫЕ базы данных, не пытайся меня сбить на FOX в каждом своём топике... Попытайся понять то что я скажу: BDE или ODBC при работе с клиент-серверными базами данных НЕ В СОСТОЯНИИ обеспечить правильную установку блокировок, что приводит к наложению неоптимальных для данной задачи блокировок и сильному снижению производительности - это и является одной из причин того, что использование BDE или ODBC для серверов баз данных невыгодно и вызывает конкретную тормознутость системы. И это мой ответ на твою фразу: "Поэтому имеет малое значение что является клиентской частью, она все-равно работает с минимальной выборкой и говорить о радикальном приросте производительности от смены одной на другую не приходится." с которой я и спорю, утверждая, что при переходе на клиент сервер прийдётся менять клиентскую часть и весьма сильно, как минимум уход от BDE/ODBC. При чём тут fox к которому ты пытаешься аппелировать в каждом своём ответе я понять категорически не могу!

Вопрос был в том что Ассесс использует ODBC для связи с MS SQL. А здесь утверждается, что ODBC в сети медленна. Так может именно по этой причине не стоит использовать связку Ассесс - MS SQL при большом числе пользователей ( 30 )?

Кстати клиентская часть при MS SQL обычно тонкая, большая часть работы происходит на сервере. Так иммет ли смысл использовать С++ для клиентской части.
Программироваровать на VB намного легче. Или все-таки у С++ для клиентской части есть преимущества перед VB ( кроме личных предпочтений).

Хех, не могу сказать как Access соединяется с MS SQL Server... Увы не компетентен, если на VB проще писать, то используйте VB - он прекрасно поддерживает ADO

Vit спасибо Вам огромное!

С НП и огромным уважением к Вам

Vit помоему в Ваших рекомендациях мого неточностей.

1 Exсel - это не база данных
2- Языки от Microsoft: MS SQL Server, SyBase, Foxpro/VFP, MS Access, MS Excel --- Еще есть язык Визуал Бэйсик который используется в MS Access

Цитата(Guest @ 19.3.2005, 01:46)

Exсel - это не база данных

CSV, XML тоже не базы данных, но могут использоваться в качестве хранилища данных.

Цитата(Guest @ 19.3.2005, 01:46)

2- Языки от Microsoft: MS SQL Server, SyBase, Foxpro/VFP, MS Access, MS Excel --- Еще есть язык Визуал Бэйсик который используется в MS Access

Я перечислил не языки от MS, а базы данных "родные" для языков MS. Для VB - родной БД является MS Access - он в списке есть...

Цитата(Cashey @ 9.12.2004, 00:39)

На сколько я понимаю основное отличие файл-серверных БД от клиент-серверных заключается в том, что последние производят все вычесления на сервере и передают клиенту выборку. А локальные БД тянут всю таблицу.

Вообще-то локальные БД не тянут на себя всю таблицу, а берут именно ту часть, которая необходима (по крайней мере Фокс, используя заголовок таблицы, через файловый доступ вычленяет нужную ему часть), с помощью чего и достигается относительно высокая скорость работы.

Добавлю про PostgreeSql.

Его теперь можно перенести в Windows+Linux. 8.1 версия имеет инсталляцию под виндовс и это не портирование а нормальная версия.

По поводу dbExpress.
Из опыта: работа с DB2 очень удобна и проста а главное быстра!.
Сравнивали только с ОЛЕ ДБ => идентичные результаты.

Почему dbExpress умерло не родившись? сейчас как раз тенденция не столько к универсализации стколько к прямому доступу... Вот борланд и предложила общий интерфейс. Мне кажется данное направление будет развиваться.

LiMan - спасибо!

добрый день! по стоимости сколько, в сравнении стоит, дешево, дорого
интересует именно Oracle и MS SQL, как по финансовым затратам выглядит картина, сама БД сколкьо стоит примерно + железо,
спасибо!

Цитата

интересует именно Oracle и MS SQL, как по финансовым затратам выглядит картина, сама БД сколкьо стоит примерно + железо, спасибо!

Очень сложно ответить. Стоимость корпоративных БД зависит от
1. Количества пользователей
2. Количества процессоров
3. Количества оперативной памяти на серваке
4. Купленном пакете тех. поддержки
5. Купленном пакете (обычно есть несколько разных edition разнящихся по набору утилит и разных фишек)
Возможно ещё от каких-то железячных или софтовых факторов.

В зависимости от них цены могут очень сильно варьировать. У нас как-то был сервер для которого оказалось что дорогой MS SQL Server оказался дешевле вроде бы дешёвого Interbase, так как на тот момент MS SQL Server стоил дёшево для одного процессора и малой памяти и стоимость мало зависела от числа клиентов, а стоимость IB практически не зависела от железа, зато очень зависела от числа клиентов... Был бы сервак помощнее, а количество клиентов поменьше разница в ценах дыла бы на порядок но в другую сторону.

В целом Oracle несколько дороже MS SQL Server, но чтобы реально оценить надо обратится к сайту производителей и внимательно изучить документацию (для многих случаев соотношение может быть и обратным)

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

Видеокарта и т.п. - могут быть любыми, для сервака по фиг. Обычно цены серваков варьируют от 1000$ самые простые, до 20 тыс и больше...

спасибор за ответы, про серваки ясно, меня интересует стандартный пакет, про Oracle нашел, но вот про MySQL и MS SQL такого подробного нет, не смог найтй, если есть возможность дайте пожайлуста ссылки гдще можно почитать, можно на английском или немецком
спасибо!

Зашёл на yahoo, набрал фразу

buy ms sql server

выдало довольно много результатов, есть из чего выбрать

понят спасибо за помощь! всего лучшего и позитивного!

Наконец добрался до раздела баз данных. Vit, огромное, нечеловеческое спасибо за обзор.

У меня кратенький вопросик, решил задать его в этот топик, потому что он, наверняка, не только у меня возникает. Задача примитивна донельзя - нужно выбрать СУБД для совсем маленького проекта, для домашнего использования. Планируется одновременное подключение двух-трех пользователей, содержимое базы - каталоги книг, дисков и т.д. Раньше работал только с Oracle, но понимаю, что это не вариант. Из обзора сделал вывод, что стоит остановиться на MySQL, к тому же он бесплатный. Подойдет?
P.S. Клиент планируется делать в форме сервлетов Java, если это важно.
P.P.S. Очень важным моментом является нагрузка на оборудование. Не хочется завешивать сервером весь комп, как это было с Ораклом.

Это сообщение отредактировал(а) Lamer George - 10.5.2005, 16:16

Я, конечно, не Vit, но думаю в твоем случае MySQL подойдет.
В принципе, если объем данных небольшой - можно даже Access использовать.
Просто обрати внимание на такие мометы:
1) платформа, на к-й будет работать СУБД. Если это *.nix - Access сразу отпадает.
2) цена СУБД. Нужна ли тебе обязательно бесплатная СУБД? имхо, для домашнего использования лицензии не очень-то нужны. Однако, смотри сам. Учти, что MySQL тоже не совсем бесплатная. Если не ошибаюсь, она бесплатна только для некоммерческого использования.

Вобщем, я б на твоем месте выбрал Access. Java с ним нормально работает через JDBC-ODBC-мост. Пользователей мало, данных тоже.
По поводу загрузки машины при использовании MySQL vs Access - не знаю.
Кроме того, Access идет вместе с M$ Office - он наверняка есть почти на каждой машине, в то время как MySQL нужно ставить отдельно.

З.Ы. Если интересуют "совсем бесплатные" СУБД для любого (коммерческого/некоммерческого) использования - то это FireBird, PostgreSQL. (больше не знаю )

Цитата(Lamer @ 10.5.2005, 07:13)

Задача примитивна донельзя - нужно выбрать СУБД для совсем маленького проекта, для домашнего использования.

MS Access, IB Firebird

Большое спасибо за советы.

Access брать не хочу - просто как-то не ассоциируется он у меня с СУБД . Выбрал бы FireBird, но с ним я на работе работаю (извините за), поэтому хочу все-таки завязаться на MySQL - для разнообразия.

А может, и то, и другое попробую.

Цитата

как перевести базу из access в dbf ???

1. Вопросы задавать надо отдельно, так как эта тема к вашему вопросу отношения не имеет

2. По существу в MS Access есть возможность экспорта в dbase (*.dbf)

Цитата(Vit @ 19.3.2005, 15:28)

Цитата(Guest @ 19.3.2005, ) Exсel - это не база данных CSV, XML тоже не базы данных, но могут использоваться в качестве хранилища данных. Цитата(Guest @ 19.3.2005, 01:46) 2- Языки от Microsoft: MS SQL Server, SyBase, Foxpro/VFP, MS Access, MS Excel --- Еще есть язык Визуал Бэйсик который используется в MS Access Я перечислил не языки от MS, а базы данных "родные" для языков MS. Для VB - родной БД является MS Access - он в списке есть...

Еще раз поправлю:

Excel - это как раз база данных. Это не СУБД!

Цитаты, из энциклопедии (даже не заглядывая в книжку Кодда):

БАЗА ДАННЫХ, упорядоченная совокупность данных, предназначенных для хранения, накопления и обработки с помощью ЭВМ. Для создания и ведения Б. д. (обновления, обеспечения доступа к ним по запросам и выдачи их пользователю) используется набор языковых и программнух средств, наз. системой управления Б. д. (СУБД).

Не путать с Банком данных!

БАНК ДАННЫХ, совокупность баз данных, а также программные, языковые и др. средства, предназначенные для централизов. накопления данных и их использования с помощью ЭВМ.

Цитата(g @ 15.7.2005, 22:10)

Еще раз поправлю: Excel - это как раз база данных. Это не СУБД! Цитаты, из энциклопедии (даже не заглядывая в книжку Кодда): БАЗА ДАННЫХ, упорядоченная совокупность данных, предназначенных для хранения, накопления и обработки с помощью ЭВМ. Для создания и ведения Б. д. (обновления, обеспечения доступа к ним по запросам и выдачи их пользователю) используется набор языковых и программнух средств, наз. системой управления Б. д. (СУБД). Не путать с Банком данных! БАНК ДАННЫХ, совокупность баз данных, а также программные, языковые и др. средства, предназначенные для централизов. накопления данных и их использования с помощью ЭВМ.

ИМХО - фигня это всё...

СУБД - система управления базой данных... Excel - данные хранить может, управлять ими тоже, вообще-то средства Excel по управлению данными покруче будут чем у типичной СУБД начала 80х годов. Кроме того многие авторы полагают что понятия "база данных" и "система управления баз данных" вообще не имеют отношения к компьютерам, базами данных можно обозвать от библиотеки до картотеки отдела кадров или журналов ведомостей в бухгалтерии.

Узнаю совковый стиль обучения с заморачиванием головы правильным пониманием терминов, меня тоже учила целая плеяда дегенератов, которая заставляла определения выучивать, вызубривать и пол лекции какой-то профессор объяснял почему надо понимать этот термин именно таким образом как его трактует профессор А, а не так как его трактует профессор Б.

Короче, не превращайте сугубо практическую тему о выборе базы данных, в теологический спор чего и чем является, а чем нет. Оставим схоластику. Вопрос чисто пракический - есть программа, она должна хранить данные и обрабатывать их. Как бы вы там не обозвали excel и все остальные штуки перечисленные мной - все они дают какие-то возможности для манипулирования данными, вот их и сравниваем... А рассуждения как это правильно обозвать преберегите для университета...

2:Vit

Кодда тож в корзину?

Цитата(g @ 18.7.2005, 10:33)

2:Vit Кодда тож в корзину?

Я не про то. Естественно мнение многоуважаемого Кодда весит очень много. Я к нему прислушаюсь, но молится на него не буду. Привык думать критически, а не полагаться на мнение авторитетов. Господин Кодд создал теорию реляционных баз данных, а вовсе не всех баз данных, и в своей теории он уповал на смысл и суть предлагаемых технологий, а вовсе не давал идеологически правильные определения понятий. Кроме того Кодд - это теория, кстати более чем 20ти летней давности, а мы говорим о чисто практическом, прикладном аспекте... Вы же затеваете схоластический спор...

Спор оторванный от жизни? Ни в коем разе!
Я попытался показать, что при общении может возникнуть ситуация, когда один - про Фому, другой - про Ерёму...

Или лучше все-таки оперировать общепринятыми терминами/определениями?

Цитата(g @ 18.7.2005, 11:19)

Или лучше все-таки оперировать общепринятыми терминами/определениями?

Я не против если вы напишете статью аналогичного плана, если она будет хорошего качества то я обязательно её помещу здесь

g-m, вы не прав
Добавлено @ 09:15
Не к чему совершенно было затеваться

Аксесс нормальный но крайне тормозной

Да, Cache супер! Рулез!
Я не большой специалист в области БД, но если элементарный Select в SQL менеджере Сacha выполняется 9 секунд, который тот же самый InterBase делает за 500мсекунд, то я выберу вторую CУБД.

размер БД 900000 записей.
запрос: SELECT * FROM xTABLE
WHERE (FIELD1<3456767 AND FIELD2>3456767)
Поля FIELD1, FIELD2 индексированы
Железо: ОЗУ 1Gb, CPU Intel 3Ггц, SATA 200Гб

Одно скажу - реклама и документация его супер. Delphiсты правда отдыхают.
Добавлено @ 16:08
Мужики помогите выбрать СУБД! Запрос который меня волнует приведен в пред примере.
InterBase не устраивает - он тоже медленный. Надо в секунду делать не менее 30 таких запросов. Как быть? Я уже готов писать свою базу

Может кто подскажет где почитать про методы индексации и поиска применительно к СУБД, где сказано как размещают индексы в базах, как по ним правильно искать.

Имхо, Оракл способен удовлетворить любым нагрузочным требованиям, предъявляемым к совремменым СУБД.
Добавлено @ 21:24
А если и его мощности будет недостаточно - тогда надо серьезно задуматься над переработкой архитектуры.

Это нужно читать в мануалах к конкретной СУБД, оптимизация запросов у всех разная. Стоит еще покурить EXPLAIN запросов.

Знаете, на такой вопрос невозможно ответить.... Какова степень уникальности значений в полях FIELD1 и FIELD2? Если оба поля содержат десятки тысяч одинаковых значений то никакие индексы не помогут... запрос будет работать быстро. Если значения в большой степени уникальные - тогда надо по одному из полей (или по обоим но с разнонаправленной сортировкой) создать кластерный индекс. Теперь * означает что при каждом запросе будут ещё кверится системные таблицы на то чтоб вытащить список полей, его надо бы прописать... Уровень блокировок какой выставлен? Изоляция транзакций? План выполнения смотрели? может там вообще индексы не используются? Индексы давно дефрагментировали? и т.д. и т.п. На вскидку при хорошей оптимизации на обычном серваке такие запросы MS SQL Server должен далать за 0.1-0.2 секунды, если конечно возвращается умеренное количество строк и полей не тысячи...

Попробовал Ваш запрос на таблице с 900000 записей на MS SQL Server - результат меньше секунды, у меня дома MS SQL Server стоит на особом компьютере (PII-500, 256Mb RAM) чтоб ТЩАТЕЛЬНО писать запросы... А если по одному из полей кластерный индекс, то скорость выполнения запроса около 0.01 сек

Вот тест с 3000000 записями на FB 1.5.2 http://forum.vingrad.ru/index.php?showtopi...st&p=652143

Посмотрите также в сторону SQLite ( 
http://www.sqlite.org/ 
http://ru.wikipedia.org/wiki/SQLite
http://www.freesource.info/wiki/SQLite
http://en.wikipedia.org/wiki/SQLite
) 

добавочка (может кому пригодится):

Axiom is an object database built on SQLite. In addition to object-relational mapping (ORM, Объектно-Реляционный Отображатор) it provides heterogenous object references and schema upgrades.
DivMod Axiom от известной команды DivMod: http://google.com/search?q=divmod%20axiom

Это сообщение отредактировал(а) dvska - 4.8.2006, 17:03

dvska, задача уже не актуальна, ей больше года.

Однако, база интересная. 

всем привет!   

помогите советом:

теорию по БД знаю, раньше имел дело только с Access и простыми запросами. Теперь хочу освоить что-то посерьезнее, то есть что-нибудь из востребованных на рынке труда СУБД. Не могу опередлиться: их так много *а я один*

в основном конечно хочется немного попрактиковаться на локальных базах данных, изучить SQL получше -->> для уверенного знания материала. 

PS: и если не затруднит, если будете советовать СУБД, укажите еще и версию. спасибо  

я вижу такие варианты:
1. Устроиться на работу в серьёзную программерскую контору, разрабатывающую бизнес-софт. Спрос есть на спецов в разных СУБД: DB2, Oracle, MSSQL, Sybase...
2. Поучаствовать в каком-либо open-source проекте. Тут скорей всего будут MySQL, PostgreSQL. На них кстати тоже есть спрос.

Для изучения -- имхо не важно которую из вышеперечисленных выбрать (ну может кроме MySQL, как пока недостаточно "фичастой")

"локальная база данных" -- это понятие относительное и малосущественное  

dvska, доброго вечера 

>1. Устроиться на работу в серьёзную программерскую контору...
пока не берут к сожалению. только мечтаю пока   


>"локальная база данных" -- это понятие относительное и малосущественное  
локальная в том плане что 1 пользователь.
база данных книг, предметов и тд...
я понимаю, что реальные базы куда сложнее, но пока тренируюсь на небольших.

а что вы скажете о MS Visual FoxPro 9.0? 

Я предлагаю PostgreSQL

http://ru.wikipedia.org/wiki/PostgreSQL 

 

однозначно не стОит 

Писал на 7,0 - остались в основном плохие воспоминания. 

Лучше сразу поставить себе серьёзный многопользовательский сервер СУБД (Sybase,DB2,Teradata,Firebird/Interbase, MSSQL,Oracle,PostgreSQL, а не Access, FoxPro, SQLite) и на нём "играться", постепенно используя всё больше и больше его возможностей.. ИМХО  

Это сообщение отредактировал(а) dvska - 31.7.2006, 16:32

 
Согласен! Да это и дешевле - в перспективе! 

Начинать с DB2, Oracle, MS SQL Server, Sybase - не советую, помимо трудностей с самим самой базой, будут трудности с ее администрированием.
Лучше для начала взять что попроще: Firebird/Interbase или PostgreSQL. С них перейти на другие СУБД будет не так уж и сложно. 

отговорили от foxpro, а я по нему уже немного читать начал. ну да ладно 


почитал сейчас здесь по оракл и скл: они на windows xp значит не встанут? придется систему на nt переводить, да?   

Почему это? У меня отлично крутится.