для написания бизнес-плана создания системы упр.предприятием необходимы ссылки на аналитические обзоры (желательно на русском языке) сравнения различных СУБД. Короче нужны аргументы какую СУБД выбрать и ПОЧЕМУ. Предприятие не очень большое (200 чел, из них около 100 используют работу с БД). На сегодня пять разрозненных СУБД под MS SQL Server и InterBase/Firebird. Есть желание предложить все обеденить - нужно выбрать СУБД.
Споров что лучше я уже начитался, хотелось бы конкретные цифры.
где найти серьезный анализ СУБД
Бизнес-планы так не пишут. Точнее может быть и пишут, но это неправильно.
Ты должен оценить ресурсы, которые понадобятся для перехода на ту или иную БД. Допустим, для перехода на MS SQL нужно 40 человеко/месяцев и у тебя есть 5 программистов, справящихся с этой задачей, и 20 человеко/месяцев для перехода на Interbase, но у тебя только 2 программиста под эту задачу. Вот и думаешь, что тебе выгоднее: получить результат через 8 месяцев, но за 24К или за 10 месяцев, но за 12К.
А сравнений MS SQL c Interbase кроме как в рекламных статьях (скорее всего по заказу Борланда написанные) ты не найдёшь, потому как это что-то вроде сравнения междугородного рейсового автобуса с маршруткой - изделия для задач разных классов...
Ты должен оценить ресурсы, которые понадобятся для перехода на ту или иную БД. Допустим, для перехода на MS SQL нужно 40 человеко/месяцев и у тебя есть 5 программистов, справящихся с этой задачей, и 20 человеко/месяцев для перехода на Interbase, но у тебя только 2 программиста под эту задачу. Вот и думаешь, что тебе выгоднее: получить результат через 8 месяцев, но за 24К или за 10 месяцев, но за 12К.
А сравнений MS SQL c Interbase кроме как в рекламных статьях (скорее всего по заказу Борланда написанные) ты не найдёшь, потому как это что-то вроде сравнения междугородного рейсового автобуса с маршруткой - изделия для задач разных классов...
Даже самый дурацкий замысел можно воплотить мастерски
так ведь чтоб оценить ресурсы, надо где-то прочитать что и почем, что У НАС имеет большую долю рынка, каких программистов легче (дешевле) нанять для этой работы. Судя по топикам все работают в супер компаниях и давно не знают что такое заказать разработку СУБД для организации малого и среднего размера (т.е. группе из 1-3 разработчиков) и не нужно говорить, что такой коллектив не способен сварганить ничего стоящего. Год назад я занялся поиском разработчиков для одной небольшой СУБД. Побеседовал с 12 разработчиками. Стоимость запрашивали от 500 до 900 у.е. И только одна ГОТОВАЯ разработка стоила $2000 (по объему ехешника :-).
Так вот остановился я на одном программисте который за 4 месяца написал отличную СУБД (за последующие пол года мы внесли кучу доработок- аппетит ведь приходит во время...) и все работает тип-топ, изменения вносятся почти на ходу. Вообщем на сегодня он разрабатывает для нас уже третью СУБД (Interbase/Firebird). Одно только плохо - для других (более "тяжелых") СУБД требуется что-то серьезнее - MS SQL? Oracle?. Опять же моих знаний недостаточно чтоб УТВЕРЖДАТЬ что надо. Вот я и хотел бы почитать аргументированные обзоры.
Так вот остановился я на одном программисте который за 4 месяца написал отличную СУБД (за последующие пол года мы внесли кучу доработок- аппетит ведь приходит во время...) и все работает тип-топ, изменения вносятся почти на ходу. Вообщем на сегодня он разрабатывает для нас уже третью СУБД (Interbase/Firebird). Одно только плохо - для других (более "тяжелых") СУБД требуется что-то серьезнее - MS SQL? Oracle?. Опять же моих знаний недостаточно чтоб УТВЕРЖДАТЬ что надо. Вот я и хотел бы почитать аргументированные обзоры.
Большинство специалистов работают в софтверных лавках, там платят больше 
По дешевизне и распрастранённости у нас рулит MS SQL. Sybase & DB2 - большая редкость.
С точки зрения производительности на указанных объёмах различия между MS SQL и Oracle - минимальны, особенно если речь идёт об NT.
Самые компетентные тесты можно помотреть тут:
http://www.tpc.org
А вот для того, чтобы оценить имеет ли смысл переходить с Interbase на MS SQL или Oracle указанной информации маловато будет.
Надо оценить объём БД, мощность и частоту запросов. По-умному - пиковые нагрузки.
По-простому: если из 100 человек, скажем 10 полный рабочий день вбивают накладные и проч. документы в базу в течение года, то при получении годового отчёта один бухгалтер может надолго напрячь сервер и остальные будут отдыхать
По дешевизне и распрастранённости у нас рулит MS SQL. Sybase & DB2 - большая редкость.
С точки зрения производительности на указанных объёмах различия между MS SQL и Oracle - минимальны, особенно если речь идёт об NT.
Самые компетентные тесты можно помотреть тут:
http://www.tpc.org
А вот для того, чтобы оценить имеет ли смысл переходить с Interbase на MS SQL или Oracle указанной информации маловато будет.
Надо оценить объём БД, мощность и частоту запросов. По-умному - пиковые нагрузки.
По-простому: если из 100 человек, скажем 10 полный рабочий день вбивают накладные и проч. документы в базу в течение года, то при получении годового отчёта один бухгалтер может надолго напрячь сервер и остальные будут отдыхать
Даже самый дурацкий замысел можно воплотить мастерски
<А вот для того, чтобы оценить имеет ли смысл переходить с Interbase на MS SQL или Oracle указанной информации маловато будет>
Для ясности разговора - только одна СУБД боле-менее "тяжелая" - объем около Гига (MS SQL), более миллиона записей (набрали за семь лет). Операторов ввода- три. Просматривающих данные - около 50 (может вырасти до 100). Остальные на порядок, два скромнее. Громоздких отчетов не формируем - на сегодня самая длинная операция длится пару секунд. Все базы (а были dBase, Paradox) переводятся на MS SQL ("АРХИВЫ") и FireBird (абонотделы). На филиалах - MS Access (программный модуль единый для MS SQL и MS Access) и FireBird. Хотелось бы знать (доказать) что делаем правильно (или не правильно) и почему.
На сегодня все базы самостоятельны (т.е. сами по себе - так исторически сложилось) иногда с дублирующимися данными. Вот и появилось желание объеденить все это в единую РСУБД. В принципе перспектива получить на это ОДОБРЯМ есть, нужно только все красиво аргументировать.
Для ясности разговора - только одна СУБД боле-менее "тяжелая" - объем около Гига (MS SQL), более миллиона записей (набрали за семь лет). Операторов ввода- три. Просматривающих данные - около 50 (может вырасти до 100). Остальные на порядок, два скромнее. Громоздких отчетов не формируем - на сегодня самая длинная операция длится пару секунд. Все базы (а были dBase, Paradox) переводятся на MS SQL ("АРХИВЫ") и FireBird (абонотделы). На филиалах - MS Access (программный модуль единый для MS SQL и MS Access) и FireBird. Хотелось бы знать (доказать) что делаем правильно (или не правильно) и почему.
На сегодня все базы самостоятельны (т.е. сами по себе - так исторически сложилось) иногда с дублирующимися данными. Вот и появилось желание объеденить все это в единую РСУБД. В принципе перспектива получить на это ОДОБРЯМ есть, нужно только все красиво аргументировать.
Да нельзя сравнивать MS SQL и interbase. Последний почти и не сервер БД по сравнению с первым. Если есть перспектива роста, есть необходимость свести все базы к одному стандарту, вести удаленное администрирование, делать обмен данными (репликацию) и могое другое, то interbase слабоват. Альтернатива MS SQL: Sybase ASE, Oracle (при наличии администратора хорошо им владеющего).Для ясности разговора - только одна СУБД боле-менее "тяжелая" - объем около Гига (MS SQL), более миллиона записей (набрали за семь лет). Операторов ввода- три. Просматривающих данные - около 50 (может вырасти до 100).
Кроме того, при установке MS SQL, в дистрибутиве есть все необходимое программное обеспечение, а вот для interbase-а народ, как правило, ставит кучу дополнительных утилиток и т.п.
Да я в общем и не сравниваю. Просто описал какие СУБД используем. Почему они сейчас используются - это уже другой разговор. А для создания единой информационной системы остановился на MS SQL Server 2000 (для наших баз думаю вполне достаточно). Может Oracle и более серъезная СУБД, но стоит ли переходить, если MS SQL уже закуплен и мало мальски изучен. Про Sybase молчу, так думаю найти спецов сложнее (и дороже), чем под две вышеперечисленные.Airhand писал(а): Да нельзя сравнивать MS SQL и interbase.
НО это снова мой (Ваш) "треп" (личное мнение :-). Где аргументы опирающиеся на исследования рынка ? На "вражеский" сайт (http://www.tpc.org) заходил, у них свои приоритеты. А мне нужны исследования по просторам СНГ.
Виктор, я уже писал выше, что не найдёшь ты сравнений не проплаченных одной из сторон. В частности и потому, что лицензия на использование продуктов MS запрещает публикование результатов тестирования без согласования с ней. Это выяснилось несколько лет назад, когда проверили на производительность MS SQL 7.0 и MS SQL 2000 на Windows NT 4.0. Второй проиграл первому, потому как MS проводит очень сильную заточку под ОС. Результаты тестирования просуществовали на сайте не больше месяца - MS заставила их убрать, намекая на серъёзные разборки по нарушению лицензионного соглашения.
Даже самый дурацкий замысел можно воплотить мастерски
Так это ничего, что "проплачено". Я ведь по любому останусь на MS SQL. А вот красиво подать анализ можно опираясь и на "проплаченные" исследования
Дак тут дело даже не в сравнении. Сравнивать можно Oracle 7, Sybase ASE (11.5-12.5) и MS SQL 2000. Но раз под Oracle спецов в конторе нет, то остается Sybase и MS. У них у каждого своя специфика (работа на низком уровне с базой, индексами и т.д., число одновременных подключений, утилиты и синтаксис T-SQL). Под Sybase относительно легко найти спецов на Украине - Приват на нем работает :-). MS SQL - проще и по деньгам выгоднее для небольшой компании (у вас явно не будет объемов от милиона транзакций в день). Дак что если исключить все не совсем подходящее, то остается MS SQL. Кроме того, если вы будете нанимать контору для разработки ПО, то логичнее им написать ТЗ, а они пусть сами предлагают схемы с анализом +/-.Виктор писал(а): НО это снова мой (Ваш) "треп" (личное мнение :-). Где аргументы опирающиеся на исследования рынка ? На "вражеский" сайт (http://www.tpc.org) заходил, у них свои приоритеты. А мне нужны исследования по просторам СНГ.