mad_nazgul
Если хотите дорого и тяжело, то Java + Oracle


Думаю можно продолжить :-)
Можно уточнить: Не обязательно Java и поэтому не обязательно тяжело: от Oracle тежелого вроде ниче не придвидится. Наоборот, на всем ЖЦ скорей всего проще: полно фич у Оракла, чтобы разруливать по ходу траблы, которые не удалось предвидеть по тем или иным причинам. Не обязательно дорого: есть даже бесплатные редакции.

mad_nazgulJava - тяжело... ибо клиент на нем...

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

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

mad_nazgulВот это и называется "баян с кучей кнопок", когда количество "фич" превышает все разумные пределы. :-)
Так тем кто назвал фичи мешают? Тут ждешь каждую новую версию в надежде на новые фичи, а им пределы превышены? Хороши. Ниче не скажешь. В 8 Оракле превышены? А мне теперь после 11 кажется, что на нем по нынешним временам принижены все разумные пределы. На нем снес по ошибке данные, а тем более таблу и привет, если нет Бэкапа. Апекса нет – это чтобы по быстрому налабать клиента. И т.д. т.п. А Вы говорите, что превышены пределы.
Када-то станки превышали пределы, лишая рабочих работы. Там всякие михайловцы или типа того боролись с ними. Ну теперь другие времена. Да и станки те кажутся допотопными.

mad_nazgulА кто говорит что плохи?
Просто их много. ;-)

А разве их много бывает?

mad_nazgulЧем больше фич, тем сложнее "инструмент". ;-)

Чем больше фич, тем проще с этим "инструменитом" "инструментировать". Например, снес по ошибке в командировке данные, а у вас есть фича простым запром вернуть обратно.



mad_nazgulА зачем бороться?
Сами "умрут". ;-)

Тем более.

mad_nazgulЕсли для нормальной работы нужны "фичи", то либо инструмент подобран не правильно, либо задача решается не правильно.
"Нормальной работы"? Правильно подобран? Ну так я и говорю что чем больше фич, тем правильнее. Ить фичи могут быть нужны чтобы снизить риски "не нормальной работы" разработчика на всех этапах ЖЦ системы. Любой проект, к, сожелению, имеет разного рода риски. Например, по ходу потребовал заказчик чтобы БД сама оповещала клиента о каких-то критических изменниях данных. Есть фича оповещать клиентов подписавшихся на рассылку событий даже када нет сессии. А нормальная правильная работа клиенту через кажную секунду спрашивать проверять не произошли ли такие изменения?

Если не обращать внимания на проггеров готовых дописывать заплатки вместо фич СУБД, то, скорей всего, "фичи" нужны для "нормального" ЖЦ ИС.

mad_nazgulБывает. :-)

Ну это возможно какое-то сильное предположение, нуждающееся в дополнитекльных подтверждениях.


mad_nazgul
Э-э-э вообще-то нормальный инструмент не дает "напортачить".
Если дает, то предполагается, что пользователь может сам "решить проблему".

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

mad_nazgulИ вообще "универсал, это тот кто делает все одинаково плохо" :-)
Поэтому я очень "настороженно" отношусь к добавлению фич.
Если фича нужна, то это скорее всего проблема в проектировании, либо в инструменте.


Понятие унивенрсал нуждается в некоторм уточнении. Однако, мы же видим, что если есть фича секционирования у СУБД, это не делает ее хуже тех СУБД у которых таковой нет, скорей всего. Т.е. добавление данной фичи, некоторые тут вроде даже приписывали своим СУБД, хотя их в последствии там не оказалось. Это делает, возможно, Вашу теорему о вредности фич по факту самого своего существования преждевременной. Более того, возможно, Вам следовало бы относиться с "настороженностью" к отсутсвию таковых.

У Оракла, по крайней мере, проблем в инструменте по сравнению с другими СУБД вроде особо не обнаруживается.
А проблемы в проектировании могут оказаться у любого. Такие риски исключать было бы чрезмерно самонадеяно. А ЖЦ в общем случае может иметь модели не предполагающие на этапе выбора СУБД предвить все.



mad_nazgul
Опять же проблема при проектировании.
Зачем в СУБД пихать мессенджер?!



А что его с наружи пристраивать? Событие то в БД произошло. А допустим моного событий. А допустим много разных клиентов должны получать сообщения разной природы. Ну есть проблема, если нет фичи. Бомбят клиенты БД запросами. А событие мож раз в год произойдет, а то и никада.

mad_nazgul
Зачем?!
Зачем иметь в СУБД мессенджер, когда можно использовать любой внешний?!
Может СУБД еще должна уметь проигрывать AVI файлы?
Тоже фича. Возможно даже кому-то нужная.

Это какой внешний? Как он узнает, что в ней что-то произошло? Запрос пошлет? Кажную секунду? Написаный проггерами или мессажер ОСи приспособить? Так оси разные могут быть. И прог много может быть.
Если СУБД файл-серверная, то типа и проигрывает. А клиентсевреная может тока запросы возвращать, которые юзеру клиент представляет. В том числе и фильмы. А так да у Оракла есть поддержка и мультимедиа.

mad_nazgulТ.е. Вы считаете, что сложная система более надежна?

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




mad_nazgulВозьмем например C и Delphi.
Например С дает полный контроль над системой.
Хотя "фич" там не очень много.
В Delphi же очень много фич, хотя контроль над системой она дает почти такой же как и C.


Полный дает ассемблер.
Если сравнивать все же с СУБД, то тада проггеру полноный контроль дает не СУБД без фич, а вообще отказ от СУБД.



mad_nazgulТем не менее в общей массе программы на C более надежные, чем на Delphi.

Это в основном драйверы что ли?



Риски провалить проект (не уложиться в срок) или сделать его менее качественным или геморным ЖЦ системы на С для ИС, возможно, повыше, чем на Дельфи.

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

Заплатки налабанные проггерами для компенсации отсутсвующих фич СУБД выглядят как иллюзия "правильного пути". Хотя это конечно свой путь.

mad_nazgul
Не факт.
Введение секционирования - это перекладывания проблемы с создателя БД, на пользователя.

Вы о чем? Что перекладывается на пользователя? Он вообще не в курсах.
Вообще-то это решение физической проблемы производительности без влияния на логику. Т.е. это снятие с разработчика логического уровня физических проблем.

Запросы для секционированной таблицы те же, что и для обычной, но в ходе выполнения пропускаются не нужные секции.
Например, секции за разные года в разных файлах, а табла то одна. И если в запросе данные за 2010 год, то файлы за остальные сто лет считываться не будут. Пишуший запросы в общем случае вообще может не знать о том, что табла секционирована. Вы это называете перекладыванием проблемы? А я думал что это устранение проблемы легким движением руки.

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


mad_nazgulТ.е. по факту мы не знаем как решить проблему, но предлагаем суррогат, который Вы можете использовать на свой страх и риск.

Вы то может и не знаете проблему. А у нас фича есть. Она все на раз разрулит без всяких страхов и рисков.

mad_nazgul

Т.е. принцип "большого швейцарского ножа".
Это не наш путь :-)
По мне, инструмент должен делать одну функцию, но хорошо! ;-)

Спасибо, конечно. Но вроде, автомагистраль луче всяких проселочных дорог (своих путей).

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

mad_nazgul
Упс... а я не знал, что триггеры отменили.
А вызвать стороннее приложение из Oracle не возможно?! <:o)



И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и программировать объекты Ворда, Йекселя (т.е. их запустить и заполнить данными из БД). Не говоря о выполнении запросов на своем диалекте SQL из других СУБД.
Вот тока, я думал, что для оповещения клиентких прог такая затычка с запуском сторонних прог выглядит чрезмерно не привлекательно. Это сторонне приложение на сервере буит обмениваться с клиентами во всей сети сообщениями? А када поступит новое сообщение запустится еще одна стороння прога? И так все 10000 раз? Впрочем, лабы по написанию прог взаимодействующих в сети луче оставить студентам.
Я раньше думал, что запуск стронних приложений для таких целей находится за гранью рассмотрения. Все же бомбление БД запросами через какждую сек выглядит, пожалуй, попривлекательнее: энтропия программного обеспечения поменьше буит. Впрочем, есть же любители фильмов ужасов. mad_nazgulТ.е. Вы считаете, что сложная система более надежна?

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




mad_nazgulВозьмем например C и Delphi.
Например С дает полный контроль над системой.
Хотя "фич" там не очень много.
В Delphi же очень много фич, хотя контроль над системой она дает почти такой же как и C.


Полный дает ассемблер.
Если сравнивать все же с СУБД, то тада проггеру полноный контроль дает не СУБД без фич, а вообще отказ от СУБД.



mad_nazgulТем не менее в общей массе программы на C более надежные, чем на Delphi.

Это в основном драйверы что ли?


Есче раз: в общем случае превзойти возможности СУБД класса Оракла в вопросах надежности не так просто. Причем основное делают фичи, потому разработчик не очень напрягается.

Зато риски провалить проект или сделать его менее качественным или геморным ЖЦ системы на С для ИС значительно выше, чем на Дельфи.

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

Заплатки налабанные проггерами для компенсации отсутсвующих фич СУБД выглядят как иллюзия "правильного пути". Хотя это конечно свой путь.

mad_nazgul
Не факт.
Введение секционирования - это перекладывания проблемы с создателя БД, на пользователя.

Вы о чем? Что перекладывается на пользователя? Он вообще не в курсах?
Вообще-то это решение физической проблемы производительности без влияния на логику. Т.ек. это снятие с разработчика логического уровня физических проблем.

Запросы для секционированной таблицы те же, что и без, но в ходе выполнения пропускаются не нужные секции.
Например секции за разные года в разных файлах, а табла то одна. И если в запросе данные за 2010 год, то файлы за остальные сто лет считываться не будут. Пишуший запросы в общем случае вообще может не знать о том, что табла секционирована. Вы это называете перекладыванием проблемы? А я думал что это устранение проблемы легким движением руки.

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


mad_nazgulТ.е. по факту мы не знаем как решить проблему, но предлагаем суррогат, который Вы можете использовать на свой страх и риск.

Вы то может и не знаете проблему. А у нас фича есть. Она все на раз разрулит без всяких страхов и рисков.

mad_nazgul

Т.е. принцип "большого швейцарского ножа".
Это не наш путь :-)
По мне, инструмент должен делать одну функцию, но хорошо! ;-)

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

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

mad_nazgul
Упс... а я не знал, что триггеры отменили.
А вызвать стороннее приложение из Oracle не возможно?! <:o)



И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и программировать объекты Ворда, Йекселя (т.е. их запустить и заполнить данными из БД). Не говоря о выполнении запросов на своем диалекте SQL из других СУБД.
Вот тока, я думал, что для оповещения клиентких прог такая затычка с запуском сторонних прог выглядит чрезмерно не привлекательно. Это сторонне приложение на сервере буит обмениваться с клиентами во всей сети сообщениями? А када поступит новое сообщение запустится еще одна стороння прога? И так все 10000 раз? Я думал, что запуск стронних приложений за гранью рассмотрения.
Я теперь совсем рад, что в Оракле есть такая фича: вдруг нашлись бы такие проггеры и в нашей фирме, которые налабали бы такого типа агента ( агентов). Может кто-то заинтересован налабать такое, чтобы других отпугивало.

Ошибочно два раза скопировалось.

Sergey Orlov Какая разница, запустить еще один процесс вызвав функцию из dll или запустить сторонную программу передав ей параметры...В последнем случае немного накладных расходов только побольше....
Вообще-то эта стороння программа или там ф-я dll еще должна искать в сети подписавшихся на события в БД клиентов. Эти клиенты должны ждать, наверное, сообщений от этой проги (обратный вызов).
Т.е. триггера и другие разработанные для этого объекты БД вместе с этой сторонней программой или ф-ей (ф-ями) из dll или еще откуда бы не было из вне, должны реализовывать механизм подписки клиентами на события в БД в сетях разого рода в общем случае. Ну для куросвых или дипломных работ создание подобного рода типа агентов может и имеет образовательный интерес. Но в продакшине это все же выглядит, скорей всего, как чрезмерная примочка к СУБД. Еще немного и своя система сообщений в ОСи получится.

mad_nazgulГрубо говоря "инструмент" должен быть прост в использовании и не сложен в изучении.
Я бы провел аналогии мерседес - VB, шахмобиль - C <:o)


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

Согласен.
Но СУБД как раз и предназначена скрыть сложность.
Вводя разумные ограничения.





Фичи и скрывают сложность. Написал простой запрос и вернул по ошибке снесенные данные. Сложности типа хде эти данные и все такое скрыты.

СУБД и предназначена для управления БД. И Фича и есть возможность достижения цели без особых усилий. Т.е. скрыть сложность на Вашем языке.


mad_nazgulЗачем заплатки?
Есть готовые апробированные решения.
См "Unxi way"


Ну многие могут посмотреть и описание архитектуры самой СУБД. Но какда сами напишут ея, то это все равно во многих случаях галимые заплатки.
Так или иначе, скорей всего, смотрение "Unxi way" уже выглядит чем-то чрезмерным при проектировании ИС.

mad_nazgul

В том, что DBA должен думать когда и какую фичу применить, чтобы подкрутить производительность.


Вообще-то за него давно подумали применив фичу. Но хорошо, а кто у Вас думает что прикрутить вместо фичи, чтобы повысить производительность?


mad_nazgul

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



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


mad_nazgulОпять "динамическое" и т.д.
Вообще пользователь должен иметь просто набор данных (в таблицах) и способы манипулирования ими.
А вот как, когда и где их размещать/хранить и т.д. должен заботиться инструмент.


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


mad_nazgul

Зачем нужна фича и способ ее управления?
Если Вы знаете проблему, то решите ее.
А так - есть проблема, но мы не знаем как ее решить.
Вот Вам фичи вы можете подкрутить так, а можете эдак.
Как нужно так и крутите.



Фича нужна, чтобы по легкому решить проблему. Ну решу с помощью фичи если таковая имеется.
А вот если нет фичи, то в некоторых случаях не известно как приемлемым способом: без чрезмерного гимора решать.
Вот я и кручу фичи.

mad_nazgul
Опять приходим к тому, что "цниверсал - это делает все одинаково плохо" :-)


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


mad_nazgul

Согласен.
Вот только я считаю, что дороги должны делать профессионалы.
А не как в СССР каждый завод сам себе дороги делал.


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

mad_nazgul

О чем я и говорю.
СУБД должно работать только с данными.
Остальные вещи должны делать другие программы.

Вот именно. С данными, и обеспечивать доступ к данным клиентам. Вот она это и делает. И фичи именно для этого.
Никакие сторонние программы не должны ее подменять в этом.


mad_nazgul
Я же говорю - "Большой швейцарский нож".
Письма рассылает, может еще пусть и кино показывать умеет?
Фича же, вдруг пригодиться.

Файл серверная СУБД типа Аксцесс сделает это. А клиентсерверная может тока предоставить фичи по урпавления не структрированныими данными. Поддерживать мультимендиа. Там следить чтобы они были правильного формата.

Вы по сути все хорошо рассказываете о пользе фич, но их при этом отрицаете. Вот что сбивает с толку.

Dimitry SibiryakovА вот отсюда поподробнее, пожалуйста: как продолжит работать система если взорвать Listener?

Ну я думау, что на резервном сервере, который в 200 метрах был на этот случай найдется не взорваный в силу удаленности Listener. А главное БД с актуальными данными (т.е. совпадающие с основным).

Dimitry Sibiryakov
А как клиенты узнают о существовании этого резервного Listener-а? Телепатически?


А им и знать не надо. На то есть ДБА. Он может заранее в Листенере прописать в ТНСе. Там типа можено прописать, чтробы клиент пытался приконнектиться к какой получится: если не получилось к первой, пробует ко второй и т.д.. В РАК тоже он коннектится часто таким же способом, то к тому инстансу то к другому. А какая для сети разница инстансы одной БД или разных на разных серваках. Если используется резервный, то ДБА должен типа обявить его резервный основным. Если мультимастер репликация, то юзер мог и до часа Х коннектиться то к тому то к другому - для него вообще не заметно потери бойца.

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

Ну уж извените. Какая мультимастер репликация. В синхронной не потеряется. В асинхронной мож и потеряется в пределах нескольких секунд.