начинают, но не слишком активно... нужна же еще поддержка производителями прикладного софта. когда еще...

> нужна же еще поддержка производителями прикладного софта. когда еще. Неужели ты хочешь сказать что у M$ есть поддержка. У меня на фирме не раз с нею сталкивались, и ответ был они "Будет исправлено в следующей версии...". А перед этим они тебя покидают еще по разным ссылка, поприсылают разного спама. Если кому надо могу навести пример вопроса на который можно получить такой ответ, сперва конечноже полазив по множеству ссылок и получив немного спама...

надо

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

Ой-ёёё куда замахнулись, это про какие такие "СУБД с открытым исходным кодом" идет речь? Я думаю здесь ситуацию нужно ставить не на уровен с ситуацией на рынке серверов а хотябы на настольных ПС.
И не надо говорить что, десктоп-линукс увеличился. Я даже уверен, что, 90% посетителей этого форума, еще не расстались с виндой, установленной паралельно.

Ну, Oracle положим еще то говнище.
Вот DB2 - да, ее врядли догонял красноглазые поделки.

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

SAPDB имеет разрешение Министерства Финансов на использование в организациях. Насчет конкуренции с Oracle ничено не скажу, не знаю.

> Ну, Oracle положим еще то говнище. > Вот DB2 - да, ее врядли догонял красноглазые поделки.

Чем же ты можешьагрументировать что Oracle говнище ? За время что я сним работаю хочу сказать что довольно устойчивая и приспособленная для разработчика СУБД, c сравнюю с MSSQL так как с этими 2 СУБД работаю... За DB2 нечего сказать не могу, но ведь для DB2 x86 не подойдет, соответственно сразу растет и цена...

done (*) (10.03.2004 13:24:23): Ну коль надо...

I want to catch the next MSSQL error in my SQL code with following continue calculations Server: Msg 17, Level 16, State 1, Line 1 SQL Server does not exist or access denied.

If REMOTE_SERVER_1 is inaccessible (as in (a) below) the executing of SQL will not continue with (b) - I need the code in (b) to run despite whether the previous exec was successful or not - Any ideas?

begin transaction (a) exec REMOTE_SERVER_1...linkprocedure '1' , '1' , 1 , 0 , 0 (b) print @@error commit transaction

where REMOTE_SERVER_1 is link to server created by EXEC sp_addlinkedserver @server = 'REMOTE_SERVER_1', @srvproduct = '', @provider = 'SQLOLEDB', @datasrc = 'MYCOMP1', @catalog = 'mirror2' EXEC sp_addlinkedsrvlogin @rmtsrvname = 'REMOTE_SERVER_1', .....

Exec sp_serveroption 'REMOTE_SERVER_1', 'data access', 'true' Exec sp_serveroption 'REMOTE_SERVER_1', 'rpc', 'true' Exec sp_serveroption 'REMOTE_SERVER_1', 'rpc out', 'true' Exec sp_serveroption 'REMOTE_SERVER_1', 'collation compatible', 'true'

Any help will be greatly appreciated

Если database server - PostgreSQL очень даже альтернатива ораклу ...

> Я даже уверен, что, 90% посетителей этого форума, еще не расстались с виндой, установленной паралельно.

Причем СУБД к ОС ? "СУБД с открытым исходным кодом" есть как под Linux так и под Windows.

Согласен насчет PgSQL.
MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

М.

> но ведь для DB2 x86 не подойдет, соответственно сразу растет и цена...

На Opteron'ах DB2 давно уже есть.

>Укажите мне хоть один гнутый продук способный конкурировать с Oracle

Вопрос в критериях конкуренции. PostgreSQL близок к Oracle для многих реальных задач. Но если фирма богатая, цена за лицензию для них не главное, и менять уже установленный Oracle они конечно не будут. А для небогатых фирм глупо платить за Oracle, если все, что нужно, делает PostgreSQL. Кстати, Firebird тоже не плох, только зря они его переписали на приплюснутом, он теперь (v. 1.5) не очень-то и переносим, компилируется только двумя компиляторами.

так вот что билли все время прятал за очками - красные глаза :)))

и для хостинга которой годится лишь твоя тезка-ось

Кстати, только что выложили PostgreSQL 7.4.2 с чем нас всех и поздравляю. Новость на LOR я запостил уже давно, но модераторы спят как обычно.

Качать с ftp://ftp.postgresql.org/pub/binary/v7.4.2/

МОДЕРАТОРЫ МЛЯ - НЕ СПАТЬ!!!

Щас нужный пост прибьют по моему любимому пункту "4.4 - Обсуждение действий модераторов." Лучше добавьте "4.4.1 - Обсуждение бездействий модераторов."

:))))))))))

2OpenStorm

Спасибо!

мда... как будто не понятно, что для большинства задач такие монстры как оракл и дб2 совершенно излишни (либо ценой, либо возможностями, либо сложностью администрирования). не представляю как сейчас соотношение м-у бд складывается, но подозреваю что 50% инсталяций имеет мускул. именно за счет неприхотливости и скорости на хорошо продуманной базе и цены. а постгресс посасывает :)) кстати, VACUUM уже нет необходимости запускать регулярно? :))

MS тоже не спит

Не надо обольщаться, не все так просто. MS потихоньку пропихивает всем почти бесплатный MSDE (дают просто так с MSDN, Office для девелоперов и VS). Это движок MSSQL со встроенными ограничениями. Поговаривают, что MSDE будет заменой уродине Аксессу.

Так вот, если MySQL для личного и хоумпажного пользования далеко переплевывает MSAccess, то бесплатный MSSQL ему будет сложновато переплюнуть. Потому как M$ его все равно каждому юзеру сунет, да еще и скриптов даст несовместимых. И кто тогда захочет изучать что-то другое?

И будет у нас две версии языка SQL - та, которая будет стандартная, и та, каторая будет работать у каждого юзера (mssql).

Ну вы прямо апокалипсис какой-то нарисовали нам!

Надеюсь, до такого не дойдёт: как вы себе представляете MSSQL на массовом хостинге (где рулят FreeBSD & Linux)? Или где те пользователи, которые "для личного и хоумпажного пользования" сами себя хостят?

> MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

А нахуя Пупкину БД?! MySQL не попсовая она быстрая.

Люди! Я не пойму. Вас что плющит? Вы говорите так, как будто каждая вторая фирма/организация которой нужна база данных - это монстры с 1000000 клиентами. Вы не забывайте, что основная масса пользоателей - это маленькие хостеры и провайдеры на клентов 100. А им к черту сдался ваш Оракл и дб2. Они лучше будут использовать MySQL и др. почти на халяву.

> MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

Транзакции есть, репликация есть, подзапросы есть. (Я про 4.1)

Что, вам так нужны триггеры и хранимые процедуры, чтобы делать что-то сложнее домашних страниц?

ветку 5.0 никто не пробовал?

HellAngel - посасывает в каком смысле? Ну дык мускуль тоже посасывает у постгреса кое-где.
Vond - угу, есть и такие места где нужны все эти прелести. В конторе сначала был биллинг на MySQL (т.к. предыдущий админ дальше него не знал). При этом кое-какие временные записи "терялись" из-за отсутствия транзакций. + была проблемка когда питание дергали - некоторые таблицы приходилось repair'ить, чтобы биллинг работал дальше. После переезда на постгрес, обе проблемы отпали.

Переезжать на альфы от mysql не очень тянет... Постгрес уже давно вылизывают, и работает он отлично, там где надо.

> Транзакции есть, репликация есть, подзапросы есть. (Я про 4.1)

> Что, вам так нужны триггеры и хранимые процедуры, чтобы делать что-то сложнее домашних страниц?

Честно. Хотя бы O_CLOEXEC на клиентской стороне для сокета. Да и код у них такой, что закачаешься. Грязный хак на грязном хаке. Хотя, для персонально-домашней страницы покатит. Тут ведь важно помнить основной закон органической химии: если к 2 кг говна добавить 2 кг повидла, то получится 4 кг говна. Так что, даешь для убогих поделок убогую СУБД с перпендикулярным ко всем интерфейсом. Postgres куда как приятней этой поделки во всех отношениях.

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

:) По моему мнению, если база/таблицы валятся, то это проблема БД, а не писавшего.

М.

по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

>>И будет у нас две версии языка SQL - та, которая будет стандартная, и та, каторая будет работать у каждого юзера (mssql).

Нету никакого стандартного SQL-ла. Фикция все это. А если и есть то только до определенного уровня. С помощью SELECT * FROM mytable много не напишеш.
Читайте ТКайта "Оракл для профессионалов". Это у него нормально обоснованно.
И потом. Процедурное расширение SQL вовсе не обязано быть переносимым. Вот и полнятся форумы "как мне перенести такуюто фичу из МССКУЛа в Оракл?"

> по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

мда... про WAL и транзакции вам еще читать и читать...

транзакции не всегда являются необходимым свойством бд (1. множество вещей можно сделать атомарными операциями. 2. некоторую /не все случаи конечно/ степень проверки по ссылочной целостности можно возложить на логику приложения). а вот физическая целостность данных - не дело базы.
или (по аналогии) вы считаете надежность ФС более важной, чем надежность диска? по мне так это разные уровни

> Поговаривают, что MSDE будет заменой уродине Аксессу.

Угумс, приплыли. тут видишь какая штука - аксесс использует msde. Потому что msde/mssql - движок, а аксесс - фронтенд. Разные вещи как бы. Совсем разные.

> И будет у нас две версии языка SQL - та, которая будет стандартная,
> и та, каторая будет работать у каждого юзера (mssql).

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

>Если database server - PostgreSQL очень даже альтернатива ораклу ...

Нууу PostgreSQL база не плохая во всяком случае если сравнивать с MySQL то просто отличная, но до Оракля не дотягивает ни производительностью ни масштабируемостью ни удобством. Ну и для меня как для разработчика ещё один минус нет нормального порта под Вин так что и дома и на работе только Оракл

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

отказ питания не единственная причина падения и не всегда УПС поможет база должна защищать от таких сбоев и точка. Если БД не умеет транзакции то это не БД а поделие уж простите. А кто этого не понимает марш читать теорию.

> по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

Я дёргал питание на тестовом серваке с ораклом. EXT3 выжила. А оракул и подавно.

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

>1. множество вещей можно сделать атомарными операциями

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

>некоторую /не все случаи конечно/ степень проверки по ссылочной целостности можно возложить на логику приложения

можно конечно. только это не есть хорошая идея. Только один пример при смене морды приложения работующего с БД скажем с текстовой на GUI или Web вам придётся снова и снова повторять логику приложения, отлаживать итд итд это гимор да и опасно для данных. Так что если ваше приложение сложнее тел. справочника то крайне не рекомендовано делать проверку ссылочной целостности в приложении. Ну не говоря уже о том что существуют способы внести изменения в БД и в обход вашего прекрасного приложения.

>а вот физическая целостность данных - не дело базы

механизм транзакций и внешних ключей в основном направлен на обеспечение логической не противоречивости данных.

вооющем вы ещё слишком молоды и слишком мало знаете/понимаете в БД уж простите но это так. Первый же серьёзный проект, ксли он у вас конечно будет надеюсь откроет вам глаза

у тебя есть статистические данные например по 100 внезапным сбоям по питанию и проблемам, которые при этом возникают у ФС, мускула, оракла и др? нет? тогда нечего выдавать единичный результат за правило. ФС вообще живучи стали. за последние 3 года пользования ext3 у меня набралось в сумме несколько десятков сбоев эл. сети (это в нескольких местах, в том числе неблагоприятных) и несколько десятков моих ресетов. итог: один (или два, точно не помню за давностью того случая) раз ext3 немного рассыпалась. fsck починил без каких-то катастрофических потерь данных. но на работающих базах такой статистики у меня нет (и слава богу)))

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

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

а по поводу интерфейса - вы предпочитаете двухуровневую модель видимо, раз для каждого интерфейса приходится менять логику? а я трех. прямо сейчас (тот проект, который пишу) логика приложения генерирует xml. а уж с помощью чего я его в html буду преобразовывать ее не касается. проверял специально в начале разработки: и мозилла и sablotron нормально все пережевывали с помощью одного и того же xslt

в догонку: я знаю что такое внешний ключ, триггер, транзакция и для чего они нужны. так что не надо мне говорить rtfm :))

>Вопрос в критериях конкуренции. PostgreSQL близок к Oracle для многих реальных задач. Но если фирма богатая, цена за лицензию для них не главное, и менять уже установленный Oracle они конечно не будут. Cipollina (*) (10.03.2004 14:53:10)

Ан нет: меняют и именно на Postgres; такие новости тут не однократно уже пробегали.

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

безусловно не противоречит, и механизмы ФС очень важны, хотя если вспомнить Оракловские рав девайсы то видно что можно жить и без ФС.

>да и сейчас есть небольшой проект чуть сложнее телефонного справочника

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

>а по поводу интерфейса - вы предпочитаете двухуровневую модель видимо, раз для каждого интерфейса приходится менять логику? а я трех. прямо сейчас (тот проект, который пишу) логика приложения генерирует xml. а уж с помощью чего я его в html буду преобразовывать ее не касается

знаете для меня трёхуровневая модель всегда была немного большем чем генерация xml и перегонка его в html:) Еслиб интерфейсы ограничивались только браузером это былабы сказка:) на самом деле ведь приходится ещё писать и толстых клиентов, для некоторых задач это лучший вариант. да и много чего ещё. У меня сейчас в проекте порядка 100 таблиц связанных а вьюхи ещё, и это только начало:) Так вот если вы хотите чтоб я повесился скажите мне что моя БД перестала поддерживать транзакции, ссылочную целостность и триггера уверяю я тут же пойду мылить верёвку;) А если серьёзно я скорее обойдусь без сервера приложений чем без полноценной БД.

> Угумс, приплыли. тут видишь какая штука - аксесс использует msde. Потому что msde/mssql - движок, а аксесс - фронтенд. Разные вещи как бы. Совсем разные.

Аксесс использует Jet, AFAIK, а не MSDE.

Когда говорят "Аксесс" в контексте СУБД, то подразумевают именно Jet.

> у тебя есть статистические данные например по 100 внезапным сбоям по питанию

Нет у меня такой статистики. Т.е. вообще. И говорим мы не о файловых системах. Попробуй, не вырубая питания, скриптом угрохать все процессы оракла во время длительной транзакции. А потом попробуй тоже издевательство с мускулем. (с постгресом дела не имел). Почувствуй разницу. Оракл живет не только на ФС. Он сам себе может быть ФС.

Народ, тут есть те, кто работал с сишным клиентом постгреса? Я интереса ради перетянул телефонный справочник из виндовса, положил его в постгрес, но при выборке а-ля select bla bla from my_view оно какого-то хрена тянет все записи. Там есть какой-то аналог курсора?

>Ан нет: меняют и именно на Postgres; такие новости тут не однократно уже пробегали

Значит, они не так богаты (как пытались казаться) и Oracle применяли от безысходности - до Postgres реальной свободной альтернативы ораклу не было. Но часть фирм еще очень долго будут использовать Orcale и DB2 (так же как некоторые продолжают использовать мейнфреймы и не переходят на писюки). Просто стоимость лицензии (или железа) для них не существенна, а стоимость перехода - существенна.

>Нууу PostgreSQL база не плохая во всяком случае если сравнивать с MySQL то просто отличная, но до Оракля не дотягивает ни производительностью ни масштабируемостью ни удобством.

Для многих (не всех) задач производительности PostgreSQL вполне достаточно (а для многих достаточно и MySQL, хотя это довольно специфичная ниша). А удобство - больше вопрос привычки. Мне например нравится возможность использовать в БД функции на Python, и совершенно не нужна Java, а кому-то - наоборот. А кто-то использует сервер приложений и вообще не нуждается в процедурном программировании внутри БД - если последовательно идти этим путем, то от БД вообще мало требуется, и MySQL д.б. в самый раз.

Примеры таких задач. Для них простых текстовых или индексных файлов не хватит?

http://www.sanchez-gtm.com/