Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
Вы например, доверите человеку, который с ней никада не работал делать проект? Ведь кроме администрирования еще и результат бывает нулевым.

Конечно нет. Но речь ведь не о том. Ваше высказывание - есть только оракл и ничего кроме оракла Есть на самом деле еще много разных субд и в зависимости от задач они используются. И заметьте - более оптимально, потому что делается выбор, а не уперто настаивается на одном. Зачем гемморой с ораклом, если задачу прекрасно тянет FB.
19 июн 06, 12:45    [2786353]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
MX -- ALEX
Guest
--
Уважаемые ASAшники, вы все больше и больше начинаете напоминать мне CACHEистов, те уже давно стали как свидетели Иеговы.


не надо
мы - кашисты - загораем и плещемся у мори
до октября - никаких дискуссий

только готовые примеры готовых решений
не хочешь - не бери
=====================
19 июн 06, 12:46    [2786362]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ASCRUS
Мне лично странно, когда на большом пребольшом IBM серваке, настроенном супер пупер сертифицированными админами Оракла массовая загрузка каких то жалких 10 гб может растянуться на часы. Наверное или мы что то не правильно делаем, или админы что то не правильно настраивают или IBM как то не так работает.

Совершенно верно, или вы что-то неправильно делаете (если это делали вы), или админы что-то не так сделали. У меня на слегка навороченном писюке (4 винта+Гиг RAM) 19Гб дамп заливался чуть больше часа.
19 июн 06, 12:46    [2786363]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
ASCRUS

Наверное долго искали ? ;) Думаю ссылочки на баги и проблемы Оракла

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

Да ладно - можно подумать в Оракле приветствуется клиентов тут же перетаскивать на последние вышедшие паки без их тщательной проверки и тестирования. Только вот ... даже если я и напорюсь на баг, то не буду ждать сто лет, пока мне его кто то соизволит исправить и даже бесплатно заявлю баг производителю и бесплатно скачаю апдейт, где никто не будет смотреть, есть ли у меня тех поддержка, нет ли у меня тех поддержки. Ну а насчет "муйни" нулевого администрирования ... недавно у нас хохма с Ораклом была ... в одной конторе грохнулась база Оракла. В принципе не критично - с кем не бывает. Однако обслуживающая Оракл контора призадумалась и решила на других своих клиентах проверить, а поднимется ли сам сервак, если ему внештатное перезагрузку провести. Проверка прошла просто - приехал человек и нажал Reset (малость работающие клиенты удивились, но куда уж AI с нулевым администрированием, который подождал бы дисконнекта всех сессий до IQ админа, раз уж меня несомненно застыдили, каюсь). Какого же было удивление "проверяющего", когда Оракл не поднялся, ругаясь на различные листенеры. Какого же было наше удивление, когда гонец тут же судоржно куда то позвонил и слинял со словами - это уже не мое дело и полдня контора благополучно ждала супер пупер спеца, который соизволил приехать и запустить тот самый Oracle. Фигня ...угу, полная фигня. Раздолбайство ... полностью согласен. Не специалисты ... ууу, не могу согласится, народ и контора просто обвешаны сертификатами Оракла и являются их дилерами. Их вина ... да ничего подобного, просто сервер этот достаточно сложный, а настоящих то спецов маловато будет, пальцы гнуть много кто горазд, а вот людей, действительно знающих на уровне администрирования Оракл ... можно и посчитать. Вот они как говорится радости администрирования, я уж молчу про тех, кто разрабатывает БД, слезы радости выступают на моих глазах, когда в любой ХП первыми строчками я вижу что ... правильно, обьявления курсоров и массивов. Не спорю ... может мне и не везло, но чтобы видеть это в разных конторах и так часто ... как то слишком много даже с точки зрения "не повезло".
19 июн 06, 13:06    [2786553]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Apex
ASCRUS
Мне лично странно, когда на большом пребольшом IBM серваке, настроенном супер пупер сертифицированными админами Оракла массовая загрузка каких то жалких 10 гб может растянуться на часы. Наверное или мы что то не правильно делаем, или админы что то не правильно настраивают или IBM как то не так работает.

Совершенно верно, или вы что-то неправильно делаете (если это делали вы), или админы что-то не так сделали. У меня на слегка навороченном писюке (4 винта+Гиг RAM) 19Гб дамп заливался чуть больше часа.

Ну так ... как раз вопрос зависимости от администрирования. Странно, что у меня не на навороченном PC 5 гиговая база на нулевую заливается со скриптов с операторами массовой загрузки с CSV чуть менее 10 минут, где я просто тупо запускаю свеже инсталированный сервер, в строке запуска указываю ему сколько кэша он может взять из RAM, на этом моя проф деятельность администратрирования производительности счастливо заканчивается без потери этой самой производительности, причем метод этот "запуска" будет прекрасно работать что на Windows, что на Linux, что даже на Mac или Novell. Странная разница, не правда ли ?
19 июн 06, 13:12    [2786598]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
ASCRUS
Да ладно - можно подумать в Оракле приветствуется клиентов тут же перетаскивать на последние вышедшие паки без их тщательной проверки и тестирования. Только вот ... даже если я и напорюсь на баг, то не буду ждать сто лет, пока мне его кто то соизволит исправить и даже бесплатно заявлю баг производителю и бесплатно скачаю апдейт, где никто не будет смотреть, есть ли у меня тех поддержка, нет ли у меня тех поддержки.

я какая разница что ты там будешь ? главное клиент с нулевым администрированием будет ждать и не сто лет, а ровно столько сколько нужно до ликвидации канторы. что регулярно и происходит.
а на счет остального похоже на истерику, злобные ораклоиды снова обидели ...
19 июн 06, 13:18    [2786664]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
ASCRUS

Ну так ... как раз вопрос зависимости от администрирования. Странно, что у меня не на навороченном PC 5 гиговая база на нулевую заливается со скриптов с операторами массовой загрузки с CSV чуть менее 10 минут, где я просто тупо запускаю свеже инсталированный сервер, в строке запуска указываю ему сколько кэша он может взять из RAM, на этом моя проф деятельность администратрирования производительности счастливо заканчивается без потери этой самой производительности, причем метод этот "запуска" будет прекрасно работать что на Windows, что на Linux, что даже на Mac или Novell. Странная разница, не правда ли ?


истерика продолжается, ну в оракле вместо командной строки нада тыкнуть мышой ...

ЗЫ. как я понимаю, что такое оракловый дамп и чем он от csv файлика отличается благородный дон не знает ?

К сообщению приложен файл. Размер - 0Kb
19 июн 06, 13:27    [2786737]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Да лана Yo!, ну причем тут ораклисты то. Сложно назвать истерикой факты из будничной жизни, а вот безапяляционные высказывания про мифы того, чего не видел, потому что в Оракле этого нету ... это как раз можно квалифицировать как некую ограниченность кругозора. Пока я как бы у Вас окромя знаний Oracle, MySQL и PHP не обнаружил полезного опыта, который бы мог Вам помочь здраво оценивать другие сервера по сравнению с тем же Ораклом. Безаппеляционные высказывания не в счет, это любой желающий при желании может проделать.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
19 июн 06, 13:31    [2786767]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
ASCRUS

Ну так ... как раз вопрос зависимости от администрирования. Странно, что у меня не на навороченном PC 5 гиговая база на нулевую заливается со скриптов с операторами массовой загрузки с CSV чуть менее 10 минут, где я просто тупо запускаю свеже инсталированный сервер, в строке запуска указываю ему сколько кэша он может взять из RAM, на этом моя проф деятельность администратрирования производительности счастливо заканчивается без потери этой самой производительности, причем метод этот "запуска" будет прекрасно работать что на Windows, что на Linux, что даже на Mac или Novell. Странная разница, не правда ли ?


истерика продолжается, ну в оракле вместо командной строки нада тыкнуть мышой ...

ЗЫ. как я понимаю, что такое оракловый дамп и чем он от csv файлика отличается благородный дон не знает ?

Ну и как - тыканье мышкой сильно увеличивает скорость поднятия дампа ? Часами уже не ждем, не правда ли ?
19 июн 06, 13:32    [2786780]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm

Конечно нет. Но речь ведь не о том. Ваше высказывание - есть только оракл и ничего кроме оракла

Нет не об этом речь. Внимательней, плиз, читайте весь текст.

iscrafm

Есть на самом деле еще много разных субд и в зависимости от задач они используются.

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

iscrafm

И заметьте - более оптимально, потому что делается выбор, а не уперто настаивается на одном.

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

iscrafm

Зачем гемморой с ораклом, если задачу прекрасно тянет FB.

Я никогда не видел гемороя от Оракла (я его потому и выбираю, что надеюсь, что во многих непредвиденных ситуациях он позволит решить задачу с наименьшими усилиями). Но допускаю, что у меня был бы геморой с FB - ведь я с ним никогда не работал.
Вы в плену каких-то стереотипов про гемморои с Ораклом. Они есть у тех кто тока начинает. Но у начинающих есть на любой СУБД - это всегда сложное программное обеспечение. Зато может оказаться что у продолжающих гемороя с Ораклом не будет - фич полно на разные случаи.
19 июн 06, 13:36    [2786809]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
ASCRUS

Ну и как - тыканье мышкой сильно увеличивает скорость поднятия дампа ? Часами уже не ждем, не правда ли ?

для того чтоб залить csv файлик вообще неважно, что там за настройки сервера. опять же если мерятся по заливке csv файлика ASA не ушел далеко от фокспро, в то время как оракл имеет sqlddr, который способен заливать пракатически напрямую в файл данных фактически минуя движек субд.
19 июн 06, 13:46    [2786877]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
vadiminfo
Александр Гoлдун

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

Намекаете на что-нибудь подобное репликации по мылу?

И это тоже, но далеко не только оффлайн-репликация.
vadiminfo

Ну это все равно что-то сомнительное в плане обычных требований к рeпликациям.

Сомнительное - это потому что вам не приходилось с этим сталкиваться?
vadiminfo

Можно и руками налабать.

Можно, кто ж спорит! Но, согласитесь, это явно не тянет на оптимизацию решения.
vadiminfo

Зато в плане реальных репликаций он свое дело знает.

Чем ваши репликации более реальны других?
vadiminfo

Я уверен, что он все равно лучший выбор.

Я свой выбор могу обосновать с калькулятором в руках для решаемых мною задач. Вы же декларируете мне уверенность в том, что для меня Oracle - лучший выбор. Почему?
Yo.!!

опять же если мерятся по заливке csv файлика ASA не ушел далеко от фокспро,

Уважаемый, будучи дилетантом в серверах, отличных от оракла, не стоит делать таких заявлений.
Yo.!!

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

Эта супер-пупер "эксклюзивно-оракловая" технология в ASA есть с незапамятных времен, просто оформлено не в виде sqlddr, а в виде специального режима Bulk load. Как альтернатива есть отдельный оператор для быстрой загрузки данных без перевода сервера в другой режим.
19 июн 06, 14:15    [2787127]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
Александр Гoлдун

Эта супер-пупер "эксклюзивно-оракловая" технология в ASA есть с незапамятных времен, просто оформлено не в виде sqlddr, а в виде специального режима Bulk load. Как альтернатива есть отдельный оператор для быстрой загрузки данных без перевода сервера в другой режим.

а можно точный url на документацию и описание чудного режима, а то што-то тут
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/index.html
не вижу.
19 июн 06, 14:33    [2787263]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

И это тоже, но далеко не только оффлайн-репликация.

Там было про почту, т.е. левые тулсы. А оффлайн - это есть у Оракла Снапшот репликация. Не известно, чтобы с ней были напряги. Качает суточные изменения у нас не тока по спутниковой но и по телефонной связи несколько сек - или мин. Насчет далеко не только это все пока предположения. Вы на столько хорошо знаете оба сервера?

Александр Гoлдун

Сомнительное - это потому что вам не приходилось с этим сталкиваться?

Про почту? Левая тулса участвует. Там у меня только СУБД. Удаленные или распределенные транзакции. А здесь что? Типа Имопрт - экспорт? Действительно ли это требует меньшего админства? Ить надо еще в почтвых сервервах в админстве что-то знать на всякий случай.

Александр Гoлдун

Можно, кто ж спорит! Но, согласитесь, это явно не тянет на оптимизацию решения.

В силу названных причин, оптимальность - открытый вопрос в принципе у такого решения. Внуитри решений с почтой, наверное, это немного хуже, чем готовая фича. Тока сама почта смущает.

Александр Гoлдун

Чем ваши репликации более реальны других?

Там про других не было. Было что соответствует, тому что в литературе про это есть, т.е. обычно принятым требованиям к репликации.


Александр Гoлдун

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

Вы не поняли смысл той фразы. Там суть в том, что так думает любой адепт в том числе и Вы. То у Вас АСА.
Вы что с калькулятором все СУБД обсчитали? И все ли калькулятор покажет?

Александр Гoлдун

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

Вы не поняли смысл той фразы. Там суть в том, что так думает любой адепт в том числе и Вы. Только у Вас АСА, у меня - Оракл.
Вы что с калькулятором все СУБД обсчитали? И все ли покажет кулькулятор? Может иная СУБД более оптимально логические весчи решает? Кто знает?
А как заполнять блоки и т.д. Ну могу тоже считать. Но что толку если, например, на бругом сервере по другому? В любом случае обсичитывать все сервера или проверять обсчитанное другими не реально. А придут спецы от той СУБД и найдут ошибки в плохих вычислениях про свою СУБД?
19 июн 06, 14:42    [2787334]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Yo.!!
Александр Гoлдун

Эта супер-пупер "эксклюзивно-оракловая" технология в ASA есть с незапамятных времен, просто оформлено не в виде sqlddr, а в виде специального режима Bulk load. Как альтернатива есть отдельный оператор для быстрой загрузки данных без перевода сервера в другой режим.

а можно точный url на документацию и описание чудного режима, а то што-то тут
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/index.html
не вижу.

По приведенной ссылке есть алфавитный указатель. Можно легко выйти на bulk load: bulk operation mode. Но я предпочитаю использовать LOAD TABLE statement, чтоб не переводить сервер в другой режим.
19 июн 06, 14:47    [2787369]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ASCRUS
Странно, что у меня не на навороченном PC 5 гиговая база на нулевую заливается со скриптов с операторами массовой загрузки с CSV чуть менее 10 минут, где я просто тупо запускаю свеже инсталированный сервер, в строке запуска указываю ему сколько кэша он может взять из RAM, на этом моя проф деятельность администратрирования производительности счастливо заканчивается без потери этой самой производительности, причем метод этот "запуска" будет прекрасно работать что на Windows, что на Linux, что даже на Mac или Novell. Странная разница, не правда ли ?

Неправда. Я привел пример из совего личного опыта, чтобы просто подчеркнуть, что 10Гб+хороший сервер+несколко часов - это аномалия никак не связанная с возможностями или оганичениями Oracle, потому что я получаю большее за меньшее время на меньших мощностях. Я ведь не сказал, как еще задачи выполнялись на моем "навороченом писюке" и сколько народу туда колбасило данных. Так что сами понимаете, сравниваем яйца с помидорами.
А на счет
ASCRUS

в строке запуска указываю ему сколько кэша он может взять из RAM, на этом моя проф деятельность администратрирования производительности счастливо заканчивается без потери этой самой производительности, причем метод этот "запуска" будет прекрасно работать что на Windows, что на Linux, что даже на Mac или Novell.

imp userid=user/password@db FILE=/import/dump.dmp fromuser=user1 touser=user2 buffer=1000000 log=imp.log
Это тоже будет работать на любой из поддерживаемых ораклом платформ.
19 июн 06, 14:56    [2787435]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
:)) Yo.! начал читать доку по ASA??? в каком-то лесу ишак сдох ))
19 июн 06, 14:57    [2787444]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
И вообще:
Cat2
Я давно уже пришел к выводу, что обсуждения типа кто круче - бесперспекивны и почти мнгновенно переходят во флейм. Сейчас 2006 год, а не 1996. Конструктивно могут обсуждаться только вопросы о том, где в каком сервере какой-то механизм реализован лучше. Абсолютного чемпиона по все параметрам нет и уже наверняка никогда не будет.

Это надо в виде банера оформить и повесить на этом форуме.
-------------------------------------------------------
Автор благодарит алфавит за любезно предоставленные ему буквы.
19 июн 06, 15:01    [2787482]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
Александр Гoлдун

По приведенной ссылке есть алфавитный указатель. Можно легко выйти на bulk load: bulk operation mode. Но я предпочитаю использовать LOAD TABLE statement, чтоб не переводить сервер в другой режим.


When you use this option, the database server allows only one connection by one application. It keeps a rollback log, but it does not keep a transaction log. The multi-user locking mechanism is turned off.

мне нужно разжевывать чем это отличается от "эксклюзивно-оракловая" sqlddr и насколько ASA еще до нее далеко ?
19 июн 06, 15:12    [2787555]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Да уж Yo!, читать действительно нужно учится:
LOAD TABLE
Внимательно читаем, вникаем, понимаем смысл, смотрим примеры если не понятно.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
19 июн 06, 15:19    [2787609]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Yo.!! пишет:

>> When you use this option, the database server allows only one connection
>> by one application. It keeps a rollback log, but it does not keep a
>> transaction log. The multi-user locking mechanism is turned off.
>
> мне нужно разжевывать чем это отличается от "эксклюзивно-оракловая"
> sqlddr и насколько ASA еще до нее далеко ?

А вторую ссылку прочитать? Или, как и предполагалось, интерес к
документации заключается только в поиске того, на чем бы показать
превосходство? LOAD TBALE появися позже режима bulk load и позволяет
делать ту же быструю загрузку без смены режима и отключения
пользователей. Разумеется, у него функций возможно поменьше, чем у
sqlddr, но за то просто, со вкусом, прекрасно решает задачи и не требует
от оператора планки с медалями "За мужественное администрирование ...",
"Почетному DBA" и т.д.

Кстати, в ответ удовлетворишь любопытство, чем же sqlddr лучше?

Posted via ActualForum NNTP Server 1.3

19 июн 06, 15:31    [2787716]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
ASCRUS
Да уж Yo!, читать действительно нужно учится:
LOAD TABLE
Внимательно читаем, вникаем, понимаем смысл, смотрим примеры если не понятно.
[/url]

я понимаю, что человеку путающему IQ и AI будет тяжело воспринять сразу так много английского текста, но я все же попробую, может не сразу, может позже понимание прийдет:
есть небольшая разница между
ASA
Use this statement to import bulk data into a database table from an external ASCII-format file. Inserts are not recorded in the log file, raising the risk that data will be lost in the event of a crash and making this statement unusable with SQL Remote or with MobiLink remote databases.

и
Oracle
Instead of filling a bind array buffer and passing it to the Oracle database with a SQL INSERT statement, a direct path load uses the direct path API to pass the data to be loaded to the load engine in the server. The load engine builds a column array structure from the data passed to it.

The direct path load engine uses the column array structure to format Oracle data blocks and build index keys. The newly formatted database blocks are written directly to the database (multiple blocks per I/O request using asynchronous writes if the host platform supports asynchronous I/O).

Internally, multiple buffers are used for the formatted blocks. While one buffer is being filled, one or more buffers are being written if asynchronous I/O is available on the host platform. Overlapping computation with I/O increases load performance.


К сообщению приложен файл. Размер - 0Kb
19 июн 06, 15:31    [2787717]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
автор
Кстати, в ответ удовлетворишь любопытство, чем же sqlddr лучше?


тем что sqlddr это тулза, а не syntax sugar как в ASA
19 июн 06, 15:37    [2787763]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!, всегда есть небольшая разница между абзацем описания назначения команды и детальным описанием ниже ее способов работы, не кажется это логичным ? И как же по Вашему авторитетному мнению оператор LOAD TABLE работает, позвольте полюбопытствовать, я прямо заинтригован и действительно сам бы не прочь послушать про потроха, кои Вы видимо уже в ASA давно изучили ?

Yo!
тем что sqlddr это тулза, а не syntax sugar как в ASA

Опа на, а если есть только тулза, а есть тулза и возможность прямо с хранимок поднимать данные в БД, интересно что дает больше вариантов и возможностей ?

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
19 июн 06, 15:46    [2787819]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Александр Гoлдун

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

ну и оценку какой точности вы получите ? У проектов достаточной сложности получить точную оценку даже при работе на родной СУБД не так-то просто, а вы запросто с калькулятором просчитаете реализацию проекта на малознакомом сервере ? Имхо неправда.
19 июн 06, 15:50    [2787853]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить